从同事那里学习到ServicePack/Hotfix部署的一招最佳实践

场景：

今天到业主现场办公，刚好了解项目L的工作，他们准备今天晚上部署ServicePack/Hotfix，看了他们的部署准备工作，再次验证了实践中不断改进的好道理，再次从chencc身上学到了打ServicePack/Hotfix的最佳实践！

为了更好地理解以下的内容，首先你得有以下的认可前提：给系统进行ServicePack/Hotfix只能使用增量的方式进行补丁。如果您对这个前提有不同想法，可以先阅读博文《系统部署交流会上，项目经理们共享的一些心得体会》，里面还有一些博文可以了解到ServicePack/Hotfix的思路。

最佳实践：

好，现在言归正传，说说chencc给IT系统进行ServicePack/Hotfix的最佳习惯，为了更好地解释，我们用1.1表示现在生产系统的版本，用1.2表示今天晚上要部署的版本，用1.3表示团队还在开发的下一个版本。他的基本思路是这样：

1. 从生产系统上拿下1.1完整的目录版本，取到部署机器上；项目L是基于java的项目，他直接从web container上deployment目录拿下整个应用程序完整的目录和文件。（附：如果你是使用war发布，也可以找到web container将它解压缩后的目录；如果你是使用.NET开发，也是可以方便找到服务器上的应用目录和文件）
2. 在部署机器上，将应用程序目录下，包括子目录下，将所有文件都删除，只保留应用程序的完整目录结构！
3. 根据本次部署列表（包括文件列表和SQL语句的变更），如果本次部署应用程序有新的目录，则找到对应的目录下，手工创建；
4. 从安装的部署文件列表，将本次更新的文件，一个一个按照目录结构，手工从配置库中取出，放置到对应的目录下；
5. 将部署机器上的整个目录覆盖测试系统的应用程序目录，根据需要更新后台SQL或后台进程，部署完毕后在测试系统上进行测试！
6. 如果测试完毕，只要将以上的步骤在生产系统上再做一次，就可以完成部署。

分析：

他的方法改进主要在两个部分：

1. 当一次Hotfix/ServicePack需要补丁很多文件的时候（听chencc讲他们曾经有接近上百个文件需要补丁的情况），这种方法非常有效，可以减少从开发系统增量部署到测试系统，从测试系统增量部署到生产系统的两次操作，优化成一次。
2. 这样做避免多次处理时，可能发生的手误操作！只要坚持在测试系统先测试，如果出现错误，则在测试系统上就能马上得到检验。

呵呵，不知道读者你清楚他的思路吗？