为什么原来用得好好的功能，又不能用了！？几乎所有公司的项目现场实施人员经常被这类的问题苦苦困扰。那么为什么会出现这样的问题呢？原因大家可能都清楚，那就是“旧”版本覆盖了“新”版本，导致某些功能回到了解放前。我们进一步探究，为什么项目版本反而比后台研发中心提供的升级包更“新”呢？其实，其中一个主要原因就是程序紧急包。
程序紧急包，顾名思义就是紧急情况下发布的程序升级包。也就是说，它是有别于正式的程序升级包的，它是未经测试无质量保障的程序升级包。项目前台出于时间上的考虑，无法等测试完成、走正式流程发正式包，只能发紧急包。经过项目自己的测试，后台配合调试和修改，这个急用的功能调通了，就交付给用户使用了。但是，这个项目可用并不代表这个包质量是过关的，有可能在其他环境下、不同的机构参数下并不可用，有可能专业的测试人员会发现更多潜在的问题。如果这个包未通过测试，就会形成一定的时间差，但是，在这个时间差内会有其他的正式包通过测试，提交发布，这个包中可能包含有紧急包中同名文件的旧版本，项目发布时就造成“旧”版本覆盖“新”版本了。
为了更好的理解这一现象的原因，我们来看几张图：
图1：假设最初研发库与项目环境是一致的，括号内为文件版本
图2：后台研发中心接收变更申请，形成两个升级包，变更包1和变更包2，分别包括FileB的两个版本
图3：项目紧急发布变更包2中的文件，调通之后，用户反响不错
图4：变更包2由于质量问题未通过测试，但变更包1通过测试，提交正式发布了，项目发布，产生了旧版本覆盖，用户报怨。
我们如何避免旧版本覆盖问题，维持用户的满意度呢？
一方面，是项目前台要清楚地了解紧急包的风险，它不仅仅本身的质量没有保障，更容易带来后续一系列的质量问题。所以，要尽可能地少发紧急包，即使发了紧急包，也要认真做好测试，并记录发布历史，只有该紧急包正式发布之后，才能再发同一个war的其他升级包，否则就有可能产生旧版本覆盖。
另一方面，是后台研发中心尽可能地提升发包速度和升级包质量。发包速度提升能够从一定程度上降低项目对紧急包的需求，升级包质量能够缩减升级包紧急发布到正式发布之间的时间差，降低版本覆盖的可能性。这就需要建立完善的程序质量度量、冒烟测试等机制。
程序紧急包是在紧急情况下很无奈的一种选择，也只能通过前后台积极地配合，才能够最大限度地控制紧急包的数量和发布风险。
以上仅为个人经验，主要针对j2ee项目经验的总结，希望对大家有帮助。
