Jez大作《持续交付》出版，中文版翻译中

Jez （ThoughtWorker）的大作《Continuous Delivery》出版了。Martin Fowler（另一个ThoughtWorker）亲自作序，并纳入Martin签名系列。这本书的中文版正在由乔梁等人（包括我）翻译，中文出版估计要到明年了。

不过10月份的敏捷中国大会我会就这个话题做一个演讲。我讲的话题是：敏捷组织的持续交付之路。

见过很多公司搞持续集成搞不起来，不能说他没下决心，服务器架了，CC装了，轰轰烈烈地运行了一周。以后就放到那里供起来，专供领导参观使用。为啥？一不小心持续集成就失败了，还不好定位。

实际上，老马对这个问题早就有论述，放到那里没人看。大家都在做自己心里的那个持续集成。

在持续集成领域，我们经常会用到的一个术语就是“构建（Build）”。很多人认为“构建=编译+链接（Build=Compile+Link）”，Martin在第一版中指出一次成功构建包括：

• 所有最新代码从配置管理工具中取出（check out或者update）。
• 所有的代码从干净的状态开始编译。
  
• 将编译结果链接并部署，以备执行。
• 执行部署的应用并运行测试套。
• 如果上述所有操作没有任何错误，没有人工干预，并通过了所有测试，我们认为这才是一次成功的构建。
  

实际上，目前很多团队对成功持续集成构建的定义基本上是符合上述定义的。这个定义的特点在于它是相对独立的，它是一个从干净状态的源代码最终获得可运行的通过验证的软件的过程。
Martin在第二版中则在成功构建的基础上给出了成功集成的定义。成功集成关注的不是一次“编译+链接+部署+验证”的过程，而是从开发流程的角度介绍一次完整的在持续集成约束下的代码提交过程笔者对其格式略作处理，与原文稍有出入。  ：

• 将已集成的源代码复制一份到本地计算机。
• 修改产品代码和添加修改自动化测试。
• 在自己的计算机上启动一个自动化构建。
• 构建成功后，把别人的修改更新到我的工作拷贝中。
• 再重新做构建。
• 把修改提交到源码仓库。
• 在集成计算机上并基于主线的代码再做一次构建。
• 只有这次构建成功了，才说明改动被成功的集成了。
  

下图展示了Martin对成功集成的定义：

当然在第一版的“代码提交”这一节，Martin也提到了本地构建的概念，只是不如第二版这么明确。

我在大会上更详细地介绍一个案例。除了上面说的流程之外还包括：配置管理、环境管理、测试重组、组织结构调整等。讲义开完了会放到博客上来。

欢迎参加敏捷中国大会的同学来听我的主题。