持续集成之“依赖管理”

持续集成系列小说一、持续集成之戏说Check-inDance....................................................................................1二、持续集成之“测试三角形与分段构建策略原则”...........................................................6三、持续集成之“分支策略”.................................................................................................12四、持续集成之“分支策略”(续)...........................................................................................15五、持续集成之“依赖管理”.................................................................................................20六、持续集成之“自动化部署”.............................................................................................24一、持续集成之戏说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说：“我们每个人都拉一个独立分支，当每个人的功能开发完成以后，再合并到一起不就行了吗？”Joe不同意这样的做法。“游戏的需求还不明晰，要经常合在一起看一下效果。所以还是在同一个分支上开发吧。下面，我们讨论一下如何让这种失败少一些吧。”于是，他们花了点儿时间，发现有两个主要原因导致失败。1.本地代码有问题，原本就编译不了或会导致测试失败，但还是提交了；2.开始做新功能时，没有特别注意分支上的持续集成状态，直接将主分支上的代码直接就与本地代码合并了；Joe提出，开发流程应该变成如图3所示：1.每个人在开发新代码之前，只能从持续集成已成功的那个最新版本检出代码；2.开发新功能或修改bug；3.提交前将主分支上的代码再次取到本地合并；4.运行本地测试，确保测试可以通过；5.提交代码到主分支，由持续集成服务器再次运行测试。6.如果测试通过，转到步骤(1)；7.如果测试没有通过，转到步骤(2)，直到修复持续集成上的构建。可是，Alice提出反对意见。她认为：“既然本地已经运行了测试，为什么还要在持续集成服务器上再次运行呢？”Joe解释到：“主要是因为我们每个人的本地环境都不完全相同，很可能出现‘它在我的机器没有问题呀’的这个现象，所以还是要在独立的持续集成服务器上再运行一次。”因此，大家就这么决定了。四、两次本地构建的目的四周后的一天，Joe花了很长时间完成了某个新功能后，打算提交了。于是他把分支当前的代码与其本地代码进行了一次合并。然后运行了本地测试，但测试失败了。他用了很长时间来定位该问题是在他自己修改的功能里，还是在被合入的代码中。这让他对提交流程进行了反思。“要是在合入他人代码之前，能够先运行一次本地测试，验证一下我的代码没问题就好了，反正本地测试所花的时间也不长。”于是，他把这个想法告诉了其他人，最后大部分人都同意这么做。于是，其提交流程就变成了这样：?1.每个人在开发新代码之前，只能从持续集成完全成功的那个最新版本检出代码；2.开发新功能或修改bug；3.运行本地测试，如果有失败就立即修复，直至测试成本；4.提交前将主分支上的代码再次取到本地合并；5.运行本地测试，确保测试可以通过；6.提交代码到主分支，由持续集成服务器再次运行测试。7.如果测试通过，转到步骤(1)；8.如果测试没有通过，转到步骤(2)。这个过程就被称为“Check-inDance”。Alice还说道：“我们在从主分支上检出代码时，一定是那个通过持续集成验证的最新版本。这样可以避免检出的代码就是有问题的，而影响自己本地的代码。”整个过程如图4所示。五、持续集成令牌过了几天，有人把大家叫到了一起，这次是Alice。她说：“我今天遇到一个问题。我提交代码之后，正等着持续集成服务器返回结果呢，Bob就提交代码了。幸好我提交的代码通过了测试，否则的话，我就要在Bob的代码之上修复啦。所以，我建议我们需要设立一个提交令牌，只有拿到这个提交令牌的人才能提交。也就是说，当一个人做完本地测试之后，去拿这个令牌。拿到之后，再进行代码合并、本地测试和提交。提交以后当持续集成服务器返回成功通过的结果时，才能交还令牌。这样就不会出现我和Bob这种情况了。”可Bob并不同意这样的做法，“这次没有出什么问题，为什么还要这么做呢？”此时，Joe把话接了过来，说道：“Alice的这个建议很好，我已经遇上过一次这样的事情了，那次测试失败以后，我花了很长时间才发现问题并不在我的提交中，而是在Mary的提交中。我把它修复后，又做了一次提交。”由于大多数人都同意这么做，因此团队决定试一试。因为目前测试运行时间很短，所以提交和集成工作没有遇到什么瓶颈。提交流程如图5所示。似乎事情到这里就结束了。然而，这个游戏被某投资公司看中，决定做更大的投入，招更多的开发人员，让它成为一个开放游戏平台。那么，接下来Joe与他的朋友们还会遇到哪些问题呢？二、持续集成之“测试三角形与分段构建策略原则”随着软件产品新特性的不断增加，软件自动化测试用例的数量也会成倍增长。对于一些历史“悠久”的遗留系统来说，甚至会积累数以万计的自动化测试用例。如果对这样的系统进行持续集成，还要求每个开发人员都要进行本地验证的话，困难的确不小。让我们还是看看Joe的团队是如何解决类似问题的吧。在《戏说CheckinDance》一文中，咱们说到：Joe?的团队实施了带有令牌的持续集成提交流程纪律。由于每个人都做本地构建进行验证后再提交，所以持续集成平台上的构建结果比较稳定，每天持续集成服务器上的构建最多只有一两次失败(常见的原因是忘记提交某个文件而导致失败，和因本地环境配置与平台环境配置不一致而导致失败)，但一般都能在30分钟内修复。随着项目的进行，新功能不断地增加，自动化测试用例也越积越多。由于不做任何修改，本地构建脚本就会运行所有自动化测试用例，所以本地构建的运行时间也越来越长。团队里有人开始抱怨，“每次提交代码前，运行本地构建都超过15分钟，这样太浪费时间。我们可否把那些不太重要的测试拿出去，不再运行了？”一、自动化测试黄金三角形作为团队的技术负责人，Joe把大家叫到一起，就这个问题进行了专门的讨论。“我们不能放弃运行这些测试。”Alice说道，“在我前一个项目中，我们就是这么做的，结果，这些花精力写的测试都作废了。”“那是为什么呢？”?Bob问道。Alice回答道：“因为并不经常运行这些测试，随着功能的修改，有些测试的逻辑就不再是正确的了。而当再次运行发现这类问题时，通常的结果就是把这个测试删掉，因为修复这个测试的工作量太大了。”“那持续运行所有测试的话，等待的时间太长了，也是一种浪费呀。?”Bob说道。此时，作为团队技术负责人的Joe说话了。“让我们先分析一下，到底有哪些什么原因让我们的测试在这么短的时间里就变成需要这么长时间了呢？”“功能增加的多了，测试自然就多了呗。”“功能增加了，自动化测试数据的准备工作也多了，需要的时间当然就长了。”“现在我们的测试中有很多地方需要测试在原地等待结果返回，所以等待时间也挺长的。”“大家还有没有其它原因？”Joe追问道。大家沉默了一会儿，Bob说道：“好象主要就这些原因吧”。“那好吧。功能多而导致测试多这是好事儿，说明我们大家都非常重视我们的自动化测试。对于‘测试准备时间变长’这个问题可以理解，因为我们的产品越来越复杂了。对于‘结果返