超越持续集成——持续部署

特征进入产品阶段越快，它就能越早提供价值。系统响应客户反馈的速度越快，它就能越早让客户满意。 Timothy Fitz 和 Joe Ludwig 最近发布了一些文章，描述了持续部署的实践经验，将交付周期从以星期计缩短到以分钟计。

Timothy 的第一篇文章描述了持续部署如何影响修复 bug 的成本。错误被发现的时间越迟，修复的难度越高，代价也最昂贵。如果工程师在敲下代码的时候就发现了问题，那修复的成本几 乎为零。如果编译器捕获了 bug，它对开放时间造成的影响就是以分钟计的。如果 bug 进入了产品，而且在一段时间内没有被发现，找到 bug、修复 bug 的 代价就会让人觉得难以承受。千年虫问题就是一个典型的例子。Timothy 赞同快速失败（fail fast），这样 bug 所造成的影响和代价都会降低到最小。

读者的评论基本上对持续集成的实用性全持强烈的质疑态度。Erik A. Brandstadmoen 直言不讳：“在实际应用中，我觉得 [你的] 做法还不够”。来自 ycombinator 的一位评论者说道：“唔……不。也许这种做法对单人适用，可以取代持续继承。不过要是在一个复杂的系统上，许多人同时提交，你的站点肯定玩完。”

imothy 又写了一篇文章回应质疑声，他介绍了 IMVU 是怎么持续部署系统的。 IMVU 的做法是，先用持续集成来做快速构建，测试新的变化。这里有一个关键点——要有大量的、覆盖范围广的、非常可靠的自动化测试。他们用了许多测试机，用来保证可以在 10 分钟以内运行整个测试套件。所有测试都已通过以后，部署便开始了。

代码用 rsync 备份到集群的几百个机器里面。用一个 push 脚本来得到平均负载、cpu 占用率、php 错误及崩溃等等的样本作为基线。然后在小部分机器 上建立 symlink，让代码在这些机器上运行起来。一分钟以后，push 脚本就会在集群中重新收集样本，如果数据出现大幅度衰退，那么就把代码回退到上 一个版本；如果没有的话，就把代码在整个集群上运行起来，继续监控，五分钟之后重新收集数据。然后代码就可以正式运行了。

IMVU 现在有 60 名员工，3 千万注册用户，每月收入上百万英镑，做出的成绩可相当不俗。不过从 Michael Bolton 和 James Bach 的调查中看，这个系统也不完美。 Elisabeth Hendrickson 则指出，完美并不是这个系统的目标。

Joe Ludwig 是 Pirates of the Burning Sea 的前任架构师，他写了两篇文章，指出怎样才能在重量级的客户端代码的环境中执行持续部署。他先是描述了“Pirates”长达7 个半小时的部署过程，然后略述了怎样把它缩短到1 个小时。在第二篇文章中，他详细描述了要把一小时部署变成现实所要做出的重大技术改动。

你有没有持续部署的经验？要把你的系统变的可以持续部署，需要做出那些变动？请留下你的观点，与读者共享。

查看英文原文： Beyond Continuous Integration: Continuous Deployment