持续集成系列小说一、持续集成之戏说Check-inDance尽管Thoughtworks的首席科学家Martionfolwer为“持续集成”下了定义，但由于自身背景与经历的不同，每个人对其都有不同的理解。从狭义上讲，持续集成可以认为是一种基于某种或者某些变化对软件系统进行的经常性的构建活动（注：这里的构建活动不仅指编译打包工作，还包含各类自动化测试、部署及发布活动）。然而，它忽视了一点，即：任何实践中都应该包含“与人的交互”这一因素。因此，从广意上讲，持续集成应该是软件开发团队在上述活动的约束下所采用的整个开发流程及活动。它强调开发团队与持续集成系统之间的互动性。我们既见过持续集成做得非常成功的团队，也见过效果不佳的持续集成，甚至失败的案例。那么，到底如何从持续集成中得到最大的收益呢？这要从持续集成所涉及的诸多方面进行分析，并根据团队具体情况（比如团队规模、人员组成以及是否为分布式团队等）及所开发软件自身的特点（是企业应用软件，还是中间件？是嵌入式软件，还是互联网产品等）制定实践策略与实现步骤。本专栏将与大家共同探讨与持续集成、持续部署及持续交付相关的方法、工具与经验。作者本人在Thoughtworks公司曾参与的一款持续集成与发布管理产品Go的交付和对外咨询服务为专栏提供了很有素材，同时感谢肖鹏、李彦辉、胡凯、李剑等对栏目内容的支持和帮助。在软件开发中，持续集成实践能够解决的问题是尽早的集成和尽早的反馈。因此，尽管目前流行的所有版本控制工具都提供了分支/合并功能，但在少于20人的团队中实现持续集成的话，推荐使用SingleBranch开发策略。这样会减少多分支开如在合并时的开销。另外，由于理想情况下，每个分支都需要有专属的持续集成环境（包括持续集成服务器、构建环境和测试环境等），所以SingleBranch也减少了对持续集成环境的需求量（当编译时间较长或测试用例较多时，这个因素的影响尤其重要）。当团队完成最初搭建持续集成服务器，编写好一键式编译和测试脚本工作后，就需要考虑如何利用持续集成环境高效地进行团队协作开发了。一定有人会问：“多人同时在一个分支上开发的话，每个人提交时都要合并代码，不是更浪费时间吗？”这个问题也正是持续集成期望解决的问题。每当开发人员提交代码时，就是其与其他开发人员工作成果的一次集成。如果每个人都能够频繁提交代码，那么代码集成的频率就会提高，在持续集成的有力支持下，代码中潜在的问题就会更早地暴露出来（比如代码编译链接问题，自动化测试失败反映出来的代码功能问题，或需求理解不一致等问题），以便团队尽早解决之。当然，持续集成所鼓励的频繁提交并不是指那种仅将版本控制库当成备份工具，无约束的“随意”提交，还需要团队开发流程约束的。下面我们来一同探讨“持续集成环境中的团队开发流程是什么样的”。让我们先设想一个软件开发场景。一、使用版本管理工具做备份故事的主人公叫Joe，他打算写一个游戏，所以用Subversion建立了一个版本控制库用于保存代码，然后就动手写代码了。Joe的开发流程是这样的。1.从代码库中检出一份代码；2.为增加某个功能修改一些代码；3.在本地运行了一下自动化测试；4.测试通过之后，提交代码到版本控制库；5.重复前面的步骤。如图1所示。二、搭建持续集成服务器做自动构建“每次在本地手工运行自动化测试太麻烦了，”Joe想到，“这种重复的工作为什么不让机器来做呢”。于是，Joe上网查了一下，发现持续集成工具是做这个事情的，就找来一台旧机器，用CruiseControl搭建了一个持续集成服务器。他的开发流程也变为：1.从代码库中检出一份代码；2.开发新功能或修改bug；3.提交到版本控制库，思考下一个功能的实现；4.持续集成服务器运行自动化构建和测试；5.如果测试通过，转到步骤(1)；6.如果测试没有通过，转到步骤(2)。如图2所示。三、多人并行开发两周后，游戏初见原型，Joe向他的几个朋友介绍了他的游戏创建，他们都非常喜欢，因此也加入了游戏开发。麻烦很快就出现了。持续集成服务器中构建结果经常失败，所以每次检出代码后都要做问题清理工作。于是，Job与朋友们坐下来讨论如何解决这个问题。Alice说：“我们每...