首先对Magento模块的升级策略做一下简介：

Magento module的文件系统：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16

-ModuleName
    -Block
    -controllers
    -etc
        -config.xml
    -Model
    -sql
        -package_module_setup
            -mysql4-install-0.1.0.php
            -mysql4-upgrade-0.1.0-0.1.1.php
            -mysql4-upgrade-0.1.1-0.1.2.php
            -mysql4-upgrade-0.1.2-0.1.3.php
            -mysql4-upgrade-0.1.3-0.1.4.php
            -mysql4-upgrade-0.1.4-0.1.5.php
            -mysql4-upgrade-0.1.5-0.1.6.php
            ...

全新安装项目：对于每一个Module, Magento会首先执行ModuleName/sql/package_module_setup/mysql4-install-0.1.0.php, 然后依次执行mysql4-upgrade-0.1.0-0.1.1.php, mysql4-upgrade-0.1.1-0.1.2.php, mysql4-upgrade-0.1.2-0.1.3.php, 。。。, 直到升级到config.xml中配置的version。

开发中的升级：首先修改config.xml中的version, 例如原version是0.2.8, 则即将升级的ersion就应该是0.2.9, 然后新增一个升级脚本mysql4-upgrade-0.2.8-0.2.9.php。清空缓存刷新页面升级就会自动进行。

这个策略在开发中的确很方便, 在php脚本里就可以完成升级, 避免了开发人员直接到数据中修改数据等操作, 提高的项目的可移植性。

但是也有一些缺点：

1. 多个项目成员对系统做了不同的修改, 却新增了一个相同的升级脚本
2. 背景：测试服务器上某个模块的version高于生产服务器。需求：需要升级此模块, 这样就会导致在测试服务器上的升级脚本和服务器上的升级脚本文件名不同, 因为升级脚本的文件名是由模块的原版本决定的。 例如：测试服务器上模块的版本是0.3.2, 生产服务器上模块的版本是0.2.8, 现在需要对测试&生产服务器的此模块升级, 这样, 在两个服务器上所需要的升级脚本文件名就不一样：测试服务器是mysql4-upgrade-0.3.2-0.3.3.php, 生产服务器是mysql4-upgrade-0.2.8-0.2.9.php, 而且将来测试服务器上的升级脚本mysql4-upgrade-0.2.8-0.2.9.php在通过测试后也需要merge到生产服务器, 本次升级脚本不能使用mysql4-upgrade-0.2.8-0.2.9.php这个文件名。

问题1会在git pull/push时产生冲突, 然后需要人为干预, 通常大家协调一下就可以解决。

问题2比较复杂。假设代码版本控制器为Git, 同一个项目, 测试服务器是dev分支, 生产服务器是master分支, dev分支上新增的代码经过在测试服务器测试后才可以merge到master分支上, 也就是部署到了生产服务器上。所以测试服务器上的模块普遍比生产服务器上新（版本更高）。假如所有的升级都可以按顺序经过测试也不会出现这个问题, 但是往往升级并不会按顺序通过测试, 升级被部署到生产服务器上的顺序往往会颠倒, 甚至有些升级可能永远无法通过测试。

那如何解决问题2呢？ 首先我们知道, 升级模块是指升级模块所涉及的数据, 也就是修改数据库中的数据, 无论是手动修改数据还是通过php脚本修改数据, 其结果都是一样的。

选择使用php脚本升级模块是为了项目的可移植性。模块版本是线性的, 升级脚本应该按照版本由小到大依次执行。当全新安装系统时, 系统会依次执行升级脚本。如果通过手动修改数据, 那么在每次全新安装系统时都需要在合适的时间点手动修改数据, 这是不可能完成的。

特殊情况就应该使用特殊手段：分别为dev分支和master分支做内容相同的更新, 然后各自push。master分支的模块版本必须小于下一个常规升级的版本, 例如常规升级是从0.2.8升级到0.2.9, 那么这次的模块版本就应该是0.2.8.1, 相应的升级脚本文件名应该是mysql4-upgrade-0.2.8-0.2.8.1.php；

当0.2.8~0.2.9的更新测试完毕后, 在master分支中新增mysql4-upgrade-0.2.8.1-0.2.9.php文件, 此文件内容和dev分支的mysql4-upgrade-0.2.8-0.2.9.php文件完全一致, 并将dev的0.2.8~0.2.9更新merge到master分支。merge后虽然master分支中有mysql4-upgrade-0.2.8-0.2.9.php升级脚本, 但此时生产服务器模块的版本已经是0.2.8.1了, 所以不会再执行此升级脚本。

问题2解决完毕, 但是在merge dev分支的0.2.8~0.2.9更新到master分支后, 千万不要忘记新增mysql4-upgrade-0.2.8.1-0.2.9.php文件, 要不然生产服务器会丢失mysql4-upgrade-0.2.8.1-0.2.9.php升级脚本中所包含的内容(dev分支的mysql4-upgrade-0.2.8.1-0.2.9.php 和master分支的mysql4-upgrade-0.2.8.1-0.2.9.php内容完全一致)。