问题描述

自动即时回滚是企业级部署机制的重要特性.目前，使用 Magento 的内置安装工具无法实现这一点.

Automated instant rollback is an important feature of enterprise-grade deployment mechanisms. Currently, it's not possible to achieve this using Magento's built-in installation tools.

鉴于 Magento 的 core_resource 机制允许顺序执行安装或升级模块的安装脚本(通过执行 SQL 和 PHP)，恕我直言，它应该支持相同的过程似乎是合乎逻辑的相反.

Given that Magento's core_resource mechanism allows for the sequential execution of setup scripts for installation or upgrade of modules (via execution of SQL and also PHP), it seems logical IMHO that it should support the same process in reverse.

现在，一些不支持它的明显原因:

Now, some obvious reasons not to support it:

1. 回滚脚本要独立(并且可能是幂等的?)将具有挑战性.我认为这不是避免该功能的正当理由，充其量只是一个借口.

1. It would be challenging for the rollback scripts to be independent (and possibly idempotent?). I don't see this to be a valid reason to avoid the feature, it's an excuse at best.

其他模块可能依赖于已安装的模块.模块的 xml 声明 节点可用于标记这些链接.

Other modules might have dependencies on the installed module. The module's xml declaration <depends/> node could be used to flag these linkages.

开发人员可能想要暂时禁用模块而不进行完全卸载.这可能需要 xml 声明 节点中的新状态.

A developer might want to temporarily disable a module without doing a full uninstall. This could require a new status in the xml declaration <active/> node.

对您的想法感兴趣.
京东

Interested in your thoughts.
JD

推荐答案

我看过一些关于此类的帖子，并且我自己也调查了 SQL 部署的相同场景.我不得不同意企业级 Magento 应该内置这种类型的功能.好消息是，至少在一些形式或时尚方面，我不确定它有多完整.以下是异常回滚示例:

I have seen some postings in regards to such and have investigated the same scenarios for SQL deployment myself. I would have to agree that being Enterprise grade Magento should have this type of functionality built-in. The good news it IS, at least in SOME form or fashion, how complete it is I'm not really sure. Here's a sample of a rollback upon exception:

try {
    $write = Mage::getSingleton('core/resource')->getConnection('core_write');
    $write->beginTransaction();

// do stuff here

    $write->commit();
} catch (Exception $e) {
    mage::log(__METHOD__ . ':' . __LINE__ . ': Rollback happened.');
    $write->rollback();
}

现在，如果您查看 app/code/core/Mage/Core/Model/Resource/Setup.php，您会发现很多有趣的方法.特别是:_getModifySqlFiles、_rollbackResourceDb 和 _modifyResourceDb.

Now if you take a look at app/code/core/Mage/Core/Model/Resource/Setup.php you'll find quite a bit of interesting methods. In particular: _getModifySqlFiles, _rollbackResourceDb and _modifyResourceDb.

_modifyResourceDb 对我来说是最有趣的，因为这里的 $actionType 也可以回滚和卸载 - 另请注意，您也可以将 PHP 文件用于安装文件.

_modifyResourceDb is the most interesting to me, since the $actionType here can be rollback and uninstall as well - also note you can use PHP files for your setup files as well.

// Read resource files
$arrAvailableFiles = array();
$sqlDir = dir($sqlFilesDir);
while (false !== ($sqlFile = $sqlDir->read())) {
    $matches = array();
    if (preg_match('#^'.$resModel.'-'.$actionType.'-(.*).(sql|php)$#i', $sqlFile, $matches)) {
        $arrAvailableFiles[$matches[1]] = $sqlFile;
    }
}

这段代码执行后:

$arrModifyFiles = $this->_getModifySqlFiles($actionType, $fromVersion, $toVersion, $arrAvailableFiles);

但在这里我假设核心 Magento 开发人员迷失在 EAV 资源模型的内部，只是让它部分完成.

But heres where I'm assuming core Magento devs got lost in the bowels of the EAV resource model and just left it partially complete.

protected function _getModifySqlFiles($actionType, $fromVersion, $toVersion, $arrFiles)
{
    $arrRes = array();

    switch ($actionType) {
        case 'install':
        case 'data-install':
...
        case 'rollback':
            break;

        case 'uninstall':
            break;
    }
    return $arrRes;
}

我还没有机会真正测试上述内容，但仅从我对 magento 和自动加载的 ORM 的初步调查以及另一位开发人员对他的调查结果的投入来看.

I've not had a chance to really test out the above, but from just my initial investigations of the ORM that is magento and the Autoloading as well as another developer's input on his findings as well.

最终，如果我们可以在版本控制系统中保持所有更改至少模块明智，那将是理想的.显然，不应该以这种方式管理需要导入的庞大数据集，但是对于这些小的增量更改，我想推送到暂存、生产测试，如果失败，则将其拉回一个版本，一切都恢复正常.

Ultimately it would be ideal if we can keep all of our changes at least module wise within a version controlled system. Obviously huge data sets that need to be imported shouldn't be managed this way but for these small incremental changes I want to push to staging, production test and if it fails pull it back one version and everything is back to normal.

显然没有一种理想的解决方案可以用于部署具有不同要求和需求的如此多的客户，但执行此操作的通用方法将有助于代码/SQL 部署.具有讽刺意味的是，Enterprise 有 CMS 登台，以及代码模块化开发的能力，但 DB 却没有得到那么多的爱.

Obviously theres no one ideal solution for deployment with so many clients having different requirements and needs but a general way of doing this would help with code/SQL deployment. It's kind of ironic that Enterprise has CMS staging, and the ability for modular development of code, but the DB has not gotten as much love.

有一个相关的问题是指出我们目前如何使用一些自制"的专门脚本来做到这一点:

There is a related question that is noting how currently we are doing it with some specialized scripts "home-brewed" that essentially do:

执行 MySQLDump 或备份，然后替换 SQL 文件中的 BASE_URL.

Doing a MySQLDump or backup, then doing a replace on the BASE_URLs in the SQL file.

Magento 部署最佳实践

另一个需要查看的工具是 Phing.

Another tool to look at would be Phing.

如果有人有时间调查似乎实施的回滚"和卸载"过程并报告他们的发现对我也有帮助.

If anyone has time to investigate the "rollback" and "uninstall" processes that seem to be implemented and report their findings would be helpful to me as well.

这篇关于Magento 不支持模块的卸载/降级有什么原因吗的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持跟版网！