走向“持续部署”(2)

发表于:2014-05-26来源:博客园作者:桥梁点击数: 标签:持续集成
2. 尽可能短的测试反馈时间 尽管测试数量较大,测试的绝对运行时间较长,但结合Cruise本身提供的并行运行特性,团队成员胡凯,Derek和李彦辉自行开发的

  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/