走向“持续部署”(2)

　　4. 部署过程要保证数据安全

　　如果因为持续部署而导致数据丢失或错误，会得不偿失。所以，我们每次修改数据库结构或配置文件的结构后，都会写出相应的迁移脚本，并在部署过程中运行。

　　目前我们使用由Thoughtworkers开发的开源项目DBDeploy来做数据库升级。对于XML配置文件的修改，我们也自行开发了一个迁移框架。

　　5. 在稳定的前提下，尽早部署

　　有人会问：“为什么要持续部署?你又如何知道部署的版本是否稳定呢?宕机了怎么办?”的确，没有哪个开发人员希望持续集成服务器在工作时间内宕机。尽管我们无法百分之百确保每个部署版本都稳定，但在可预见的范围内稳定就可以了，否则我们就无法解决“最后一哩”问题。

　　Cruise在最初三个迭代(迭代时间为一个星期)后，就开始用Cruise来做自己的持续集成服务器了(即UAT环境)。我们让它在UAT环境上 运行了两周，没有发现什么问题，说明版本相对稳定，就将它部署到“Production”环境上了。在那以后，随着用户的增多，很多人认为由于部署失败而 导致持续集成服务器宕机的风险要高于那些新特性和修复的缺陷。因此，我们的客户要求新版本部署至 “Production”环境之前，一定要在UAT环境上运行。目前，Cruise部署到UAT环境的频率不固定(一般为两天至一周)，而部署到 Production环境的频率为一周。也就是说，Production环境上的版本要落后于UAT一周的时间。

　　6. 完善的风险缓解措施

　　随着项目的进行，难免会有部署失败的情况，所以一定要有风险缓解措施。例如：

　　(1) 部署尽可能在用户少的时候;(2) 部署时必须有技术人员在场;(2) 每次部署前备份原始数据;(3) 时刻准备回滚脚本。

　　7. 将同样的产物部署到不同的环境中

　　让你的产品可以部署到不同的环境中，如果这些环境的环境配置不同，则把有关环境配置的内容排除在你的产品之外。如果你有很多个配置变量，请让这些配置保存在同一处，而且有默认值。

　　基于这一原则，Cruise唯一的配置就是XML文件。

　　8. 不断的反思与重构

　　这一点就没有什么可说的了。它适用于所有的活动。

　　小结

　　实践表明，建立自动化部署管道的益处很多。在过去的几年中，ThoughtWorks利用这一方法帮助很多项目组和公司解决了他们的“最后一哩”问题。例如，在某项目中，通过自动化部署过程，使部署频率从几天一次提高到每天一次，而且该过程耗时少于15中分钟(其仅有一分钟的停机时间)。这对软件整个生命周期的交付阶段有着积极作用，只要按下鼠标就可以准备好所需要测试环境，从而减少了人为失误造成的不必要的损失，显著降低软件发布的风险。另外，频繁且轻松的发布让开发人员全神贯注于他们想做的事情：开发新的功能。

原文转自：http://kb.cnblogs.com/page/157115/