场景:
今天到业主现场办公,刚好了解项目L的工作,他们准备今天晚上部署ServicePack/Hotfix,看了他们的部署准备工作,再次验证了实践中不断改进的好道理,再次从chencc身上学到了打ServicePack/Hotfix的最佳实践!
为了更好地理解以下的内容,首先你得有以下的认可前提:给系统进行ServicePack/Hotfix只能使用增量的方式进行补丁。如果您对这个前提有不同想法,可以先阅读博文《系统部署交流会上,项目经理们共享的一些心得体会》,里面还有一些博文可以了解到ServicePack/Hotfix的思路。
最佳实践:
好,现在言归正传,说说chencc给IT系统进行ServicePack/Hotfix的最佳习惯,为了更好地解释,我们用1.1表示现在生产系统的版本,用1.2表示今天晚上要部署的版本,用1.3表示团队还在开发的下一个版本。他的基本思路是这样:
- 从生产系统上拿下1.1完整的目录版本,取到部署机器上;项目L是基于java的项目,他直接从web container上deployment目录拿下整个应用程序完整的目录和文件。(附:如果你是使用war发布,也可以找到web container将它解压缩后的目录;如果你是使用.NET开发,也是可以方便找到服务器上的应用目录和文件)
- 在部署机器上,将应用程序目录下,包括子目录下,将所有文件都删除,只保留应用程序的完整目录结构!
- 根据本次部署列表(包括文件列表和SQL语句的变更),如果本次部署应用程序有新的目录,则找到对应的目录下,手工创建;
- 从安装的部署文件列表,将本次更新的文件,一个一个按照目录结构,手工从配置库中取出,放置到对应的目录下;
- 将部署机器上的整个目录覆盖测试系统的应用程序目录,根据需要更新后台SQL或后台进程,部署完毕后在测试系统上进行测试!
- 如果测试完毕,只要将以上的步骤在生产系统上再做一次,就可以完成部署。
分析:
他的方法改进主要在两个部分:
- 当一次Hotfix/ServicePack需要补丁很多文件的时候(听chencc讲他们曾经有接近上百个文件需要补丁的情况),这种方法非常有效,可以减少从开发系统增量部署到测试系统,从测试系统增量部署到生产系统的两次操作,优化成一次。
- 这样做避免多次处理时,可能发生的手误操作!只要坚持在测试系统先测试,如果出现错误,则在测试系统上就能马上得到检验。
呵呵,不知道读者你清楚他的思路吗?