持续集成之一 概念篇

从前对软件的集成与发布没有关注，近期研究了下持续集成，觉得这一块儿很重要，甚至可以说是支持软件开发得以工程化、工业化最重要的一个部分。

软件的核心是编写代码，但软件开发的目的还是要把软件发布出来给用户使用。前面的所有环节，包括需求、分析、设计、开发、测试，还有其他项目管理辅助措施如QA、配置管理等，都指向同一个目标——软件发布。所以如果不在上面的环节都一致地为最后目标做准备，那么结局就不会太美好。比如我们公司，有一两百人的开发队伍，近十年的开发经验，但这些年来一直没有很好地解决系统更新的问题。最近一两年几乎到了每次更新必出错、回退的地步。甚至造成了开发与运维部门的对立。一个部门希望尽快把新开发的特性发布出来给用户使用，另一个部门希望尽量避免更新，保持系统的稳定性。这样形成了一个恶性循环：更新周期长，手续繁，导致版本管理困难，版本混乱又导致更新失败次数多，更新失败导致更严格的手续，更长的更新周期。特别是运维部门内心中对更新的抵制，他不管你业务是否重要，发现一点问题就要求回退。

这其中当然有多方面的原因。有体制的原因，有技术的原因，也有个人观念、作风的问题，甚至有具体操作人的责任心等等。但如果在集成和发布环节采取更规范的做法，甚至在整个项目过程中使用持续集成，情况可能会大幅改善。

所谓持续集成，简单地说，就是在整个项目开发阶段，不停地（一天数次）对项目作Build（构建），把每个人开发的代码集中在一起做编译连接、单元测试、代码审查和自动部署。这个概念来自于XP编程的每日构建和冒烟测试。我们知道，XP编程崇尚敏捷方法，要不停的迭代、测试，所谓的一次前进一小步。为了这个目的，96年就有人提出了每日构建的概念。而持续集成则更推进一步，要求一天多次构建。从2000年Martin Flower提出持续集成的概念，现在已经产生了很多种工具支持这一实践。

持续集成的内涵主要有：整个项目组共享一个代码库，每个人都可以很容易得到所有的程序；及时提交代码，每个开发人员每天至少向代码库提交一次代码，当然提交前最好在本地作私有构建；提交代码自动触发构建，构建包含编译、连接、运行单元测试、作代码检查、编译结果打包部署等过程；生成构建报告，并把构建结果及时反馈相关人员；

持续集成能带来哪些收益呢？首先，可以在项目开发阶段随时得到可部署、可测试的版本。这对领导和客户来讲可是个非常大的好处，你可以向他演示你现在有了怎样的功能，使项目的可见性大为提高，也为项目及时调整、纠偏提供了可能性；其次，对开发过程中向项目中引入的各种缺陷，可以更快地发现和修复。由于每天都在做集成和构建，你不必等到到所有功能都实现，最后集成阶段在集中发现问题，解决问题。要知道，发现缺陷的时间越早，修复它的成本也就越小。避免在发布起陷入集成的深潭；再者，及时反馈可给项目团队更多的信心。人们有个通性，喜欢看到变化，特别是这变化由自己引发，并朝着自己预定的方向演进。据说这也是一些人沉迷于电子游戏的原因。如果集成服务器不断地告诉开发人员你这一步做对了，那一步有什么什么问题，那么开发者会觉得开发过程有更多的乐趣。第四，对测试人员、项目管理者来说，也很有好处。对测试人员来说，可以更早地介入，并且每次提交给他测试的版本经过了构建阶段的自动化单元测试和逐轮的验证过程，测试的范围小且质量有相当的保证。对管理人员而言，通过构建报告可以清楚地了解项目进度，而不仅仅靠项目组报项目进度报告来了解。最后，持续集成采用一系列的自动化技术，可以有效避免重复劳动以及手工劳动有可能带来的偏差、人员之间的沟通成本，使开发人员可以把精力集中到真正需要智慧的设计、编码环节，而不是被那些环境不一致、提交编译申请等问题所困扰。

下一篇，我会介绍如何实现持续集成，及有关的工具和技术。