走向“持续部署”(2)

　　2. 尽可能短的测试反馈时间

　　尽管测试数量较大，测试的绝对运行时间较长，但结合Cruise本身提供的并行运行特性，团队成员胡凯，Derek和李彦辉自行开发的测试负载均衡工具(Test-load-balancer)将所有测试分成若干份，Cruise将其分配到Agent集群中同时运行，使单元测试或其它测试在可接受的相对时间内完成(单元测试在15分钟之内，功能测试在30分钟之内)。近期还将增加数个Agent，以便继续缩短测试需要的时间。

　　3. 部署过程自动化

　　当部署复杂软件时，都会使用人工过程，而且可能会花上几天的时间。而这种部署过程通常比较复杂，而且很难可靠地重复操作。因此，人们会写一些文档帮助这一过程，但文档常常更新不及时。有时，还需要几个关键性人物同时在场才能完成。

　　当每次由不同的人员进行部署操作时，出错的概率就增加，所以要尽可能少的人工步骤。

　　在Cruise的Pipeline中，尽管由人来触发两个环境中的部署，但部署过程本身是自动化的。在部署过程中，Cruise的安装包会自动关闭服务器，更新自身程序和升级数据库，然后再重新启动。所有的Agent也会以Server为准，自动更新到与其相同的版本，而不必人工去升级每个 Agent(每次为70个Agent的手动升级也是很大的成本，所以我们做了自动升级这个特性)。

　　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/