自动即时回滚是企业级部署机制的一个重要特性。目前，使用 Magento 的内置安装工具无法实现这一点。
鉴于 Magento 的 core_resource 机制允许顺序执行设置脚本以安装或升级模块（通过执行 SQL 和 PHP），恕我直言，它应该支持反向相同的过程似乎是合乎逻辑的。
现在，一些明显的理由不支持它：
让回滚脚本独立（并且可能是幂等的？）将是一项挑战。我不认为这是避免使用该功能的正当理由，充其量只是一个借口。
其他模块可能依赖于已安装的模块。模块的 xml 声明 <depends/> 节点可用于标记这些链接。
开发人员可能希望暂时禁用模块而不进行完全卸载。这可能需要 xml 声明 <active/> 节点中的新状态。
对您的想法感兴趣。
京东
【问题讨论】：
标签： php sql deployment magento rollback
我已经看过一些关于此类的帖子，并且我自己也调查了 SQL 部署的相同场景。我不得不同意，作为企业级 Magento 应该内置这种类型的功能。好消息是，至少在 SOME 形式或时尚方面，我不太确定它有多完整。以下是异常回滚的示例：
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。
_modifyResourceDb 对我来说是最有趣的，因为这里的 $actionType 也可以是回滚和卸载 - 另请注意，您也可以将 PHP 文件用于安装文件。
// 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 资源模型的内部，只是让它部分完成。
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 的初步调查以及另一位开发人员对他的发现的投入。
最终，如果我们可以将所有更改至少以模块方式保留在版本控制系统中，那将是理想的选择。显然，不应该以这种方式管理需要导入的庞大数据集，但对于这些小的增量更改，我想推动暂存、生产测试，如果失败将其拉回一个版本，一切都会恢复正常。
显然，对于这么多具有不同要求和需求的客户的部署，没有一个理想的解决方案，但这样做的一般方法将有助于代码/SQL 部署。具有讽刺意味的是，Enterprise 拥有 CMS 登台，以及代码模块化开发的能力，但 DB 却没有得到那么多的喜爱。
有一个相关的问题是指出我们目前如何使用一些“自制”的专门脚本来做这件事：
执行 MySQLDump 或备份，然后对 SQL 文件中的 BASE_URL 执行替换。
Best practices for Magento Deployment
另一个要查看的工具是Phing。
如果有人有时间调查似乎正在实施的“回滚”和“卸载”过程并报告他们的发现也会对我有所帮助。
【讨论】：
我想起了我自己的question Ivan Chepurnyi 对你说：
@Jonathan 希望 Magento 2.0 对开发人员更加友好，尤其是在数据库升级方面。但当然它只是扩展 Zend_Db。使用 Doctrine 2.0 orm 可以解决这个问题，但它需要从头开始重写 Magento :)
我不知道 Doctrine，但通过阅读它的 映射 模式在 PHPDoc cmets 中描述了类（可能由 reflection 获得），然后透明地转换为查询。不需要安装脚本。这必须意味着回滚与降级相同，安装以前版本的类及其 cmets，其余的就发生了。
了解 Magento 后，他们可能不会回头破坏旧代码，而是提供使用增量 XML 文件的替代设置方法 - 尽管没有命名空间。在此处回滚版本意味着反转每个文件中描述的差异。
我也更喜欢这种方式，因为这意味着像插入默认记录这样的指令是可能的，我认为 Doctrine 无法管理。它与更改之前的版本共存。你要发feature request吗？
<depends/> 中的版本号似乎合乎逻辑。
我真的没有第三点，但我想完成这组。 :D
编辑：
我忘了回答这个问题。不，Magento 没有理由不支持降级，至少如果他们愿意付出努力的话。
【讨论】：
注意：也许这不适用于 Magento。
我通常查看数据库应用程序升级，主要包括两个方面：1. 代码 2. 数据库。
代码更新很容易回滚。我通常将其与应用程序升级/管理代码分开管理。我通常使用操作系统的文件系统为我提供“即时回滚”功能。在数据库回滚方面，事情变得更加复杂。也可以对数据库采取类似的方法。但是，这只有在测试系统上才是现实的。
如果您只关心代码回滚，我会使用应用程序本身外部的东西来管理它。我想它可以被认为是一个快照。
如果 Magento 不支持这个开箱即用，我认为添加它是不明智的。这似乎是一个相当核心的要求，如果从一开始就没有计划和编码，实施起来会相当棘手。
【讨论】：