持续集成

很多软件项目都有一个非常奇怪而又常见的特征，即在开发过程中，应用程序在相当长的一段时间内无法运行。事实上，由大规模团队开发的软件中，绝大部分在开发过程中基本上处于不可用状态。许多这些项目总是在开发结束后留出很长一段时间作为集成阶段。有些项目直到集成阶段才发现软件并不能满足需求，这样的集成活动可能会持续很长时间，而最糟糕的则莫过于没人知道到底要花多长时间。

对于这些大规模团队合作的软件开发项目中，有什么方法可以提高效率呢？为什么有些项目即使新提交的代码破坏了已有功能，只需要几分钟就可修好。在于这些项目用到了持续集成。持续集成要求每当有人提交代码时，就对整个应用进行构建，并执行全面的自动化测试集合，如果构建或者测试失败，开发团队就要停下手中的工作，立即修复它。持续集成的目标是让正在开发的软件一直处于可工作状态。

持续集成最早出现在Kent Beck写的《解析极限编程》一书中，和其他极限编程实践一样，持续集成背后的思想是：既然经常对代码库进行集成对我们有好处，为什么不随时做集成呢？持续集成是一种根本的颠覆。油了持续集成，软件在每次修改后都会被证明是可以工作的。即便它被破坏了，我们也很快就能知道，并立即修复。高效使用持续集成的那些团队能够比那些没有使用它的团队更快地交付软件，且缺陷更少。

要做好持续集成，首先要做好三件事：

1、版本控制

与项目相关的所有内容都必须提交到一个版本控制库中，包括产品代码、测试代码、数据库脚本、构建与部署脚本，以及所有用于创建、安装、运行和测试该应用程序的东西。

2、自动化构建

我们要能在命令行中启动构建过程。要能在持续集成环境中以自动化的方式来执行整个构建过程，以便出现问题时能够审计；应将构建脚本与代码库同等对待，应该对它进行测试，并不断重构，以使它保持整洁且容易理解；使理解、维护和调试构建过程更容易，并有利于和运维人员更好地协作。

3、团队共识

持续集成不是一种工具，而是一种实践。它需要开发团队能够给予一定的投入并遵守一些规则，需要每个人都能以小步增量的方式频繁地将修改后的代码提交到主干上，并一致认同“修复破坏应用程序的任意修改是最高优先级的任务”。如果大家不能接受这样的准则，则根本无法通过持续集成提高质量。

做好这三点后，我们就可以配置一个持续集成系统，然后按照持续集成的实践来工作，下面是一个简单的过程，当我们准备提交最新修改的代码时，遵循如下步骤：

（1）查看一下是否有构建正在运行，如果有的话，等它运行完。如果它失败了，和团队的其他人一起将其修复，然后再准备提交自己的代码；

（2）当构建完成且测试全部通过，从版本控制库更新代码到自己的开发环境，并合并代码；

（3）在自己的开发环境下执行构建脚本，运行测试，以确保当前机器上的所有代码都正常工作；

（4）如果本地构建成功，将代码提交到版本控制库；

（5）等待包含这次提交的构建结果；

（6）如果这次构建失败了，就停下手中的事，在自己的开发机上立即修复这个问题，然后转到步骤（3）；

（7）如果这次构建成功，开始下一项工作。

团队中的每个人在每次提交代码时都需要遵循这些简单的步骤，并且要遵循如下基本原则：

1、频繁提交

对于持续集成来说，最重要的就是频繁提交代码到版本控制库，每天至少应该提交几次代码，这样每次的修改都比较小，所以很少会使构建失败。当我们做错了事或者走错了路线，可以轻松回滚到某个已知的正确版本。

2、创建全面的自动化测试套件

如果没有已系列全面的自动化测试，那么构建成功只意味着应用程序能够编译并组装在一起。虽然对于某些团队来说，这已经是非常大的一个进步了，但是，加入能够有一定程度的自动化测试，会让你更有信心说：我们的应用程序时可以工作的。有三类测试会在持续集成中使用，分别是单元测试、组件测试和验收测试。

3、保持较短的构建和测试过程

如果代码构建和单元测试的执行需要花很长时间，会遇到一些问题：大家在提交代码之前不愿意在本地环境进行全量构建和运行测试，导致构建失败的几率越来越大；持续集成过程需要花太长时间，导致再次运行构建时，该构建包含多次提交，很难确定到底是哪次提交破坏了构建；大家的提交频率会变少，因为每运行一次构建和测试，都要坐着等好久。理想情况下，提交前的预编译和测试过程，以及持续集成系统上的编译和测试应该都能在几分钟内结束。

4、管理开发工作区

对于保证开发人员的开发效率和明晰思路来说，开发环境的管理是特别重要的，在本地开发环境上运行应用程序时，赢确保所使用的自动化过程与持续集成环境中的一致，与测试环境中的也一致，且生产环境也是一样的。

做到这些之后，我们是不是就做好了持续集成呢？持续集成是一种实践，不是一个工具，它的有效性依赖于团队纪律。要让持续集成系统能够发挥作用，尤其是面对一个大型复杂的持续集成系统时，整个开发团队就必须有高度的纪律性，需要遵守以下原则：

1、构建失败后不要提交新代码

持续集成的第一忌就是明知构建已经失败了，还向版本控制库中提交新代码。如果构建失败，开发人员应该尽快找出失败的原因，并修复它。一旦这个规则被破坏，就需要花更长的时间去修复，然后大家就会习惯于看到构建失败，很快我们就会发现，构建会一直处于失败状态而无人在意。

2、提交前在本地运行所有的提交测试，或者让持续集成服务器完成此事

为什么要这样做呢？如果在你根据版本控制进行更新之前，其他人已经向版本控制库中提交了新代码，那么你的变更与那些新代码合并后，可能会导致测试失败。如果你自己先在本地更新代码并运行提交测试的话，可以提前发现问题；还有在提交时经常犯的错误是，有部分代码忘记提交。这样当我们本地构建成功，而服务器上构建失败的话，就能够及时发现问题。

3、等提交测试通过后再继续工作

持续集成系统是整个团队的共享资源。对于整个团队来说，构建失败会成为一个小问题，很容易修复，我们的目标是尽快发现错误，并消灭它们，所以开发人员应该在提交代码后监视构建过程，直到该提交通过了编译和提交测试之后，才开始做新任务。

4、回家之前，构建必须处于成功状态

我们需要有规律地尽早提交代码，给自己足够的时间处理可能出现的问题，不要把构建失败的问题丢给别人处理。

5、时刻准备着回滚到前一个版本

持续集成的目标，是让我们的代码保持在可发布状态，也就是说保持在运行结果通过的状态。但是，只要是人，就会犯错，当我们的提交破坏了构建，且不能及时修改怎么办？我们需要回滚到前一个版本。怎么决定是否回滚呢？可以定一个回滚时间，比如说10分钟不能修复的失败，就进行回滚。

持续集成可以大幅度提高软件开发团队的生产率，也是多团队协作的最好的实践。持续集成创建了一个快速的反馈环，让我们能够尽早地发现问题，发现问题越早，修复成本越低。

持续集成需要良好的团队纪律提供支持。有了持续集成之后，就有了一个“该纪律是否被严格遵守”的信息指示器：构建应该保持在常绿状态。如果发现构建是绿的，而大家却并没有足够地遵守纪律，比如没有达到单元测试覆盖率，我们能够非常容易地将各种检查加入到持续集成系统中，强制团队养成良好的行为习惯。在持续集成系统的基础上，我们可以构建更多的基础设施：

可视化显示器，用于显示构建系统所收集到的信息，以提供高质量的反馈；

结果报告系统，以及针对测试团队的安装包；

为项目经理提供关于应用程序质量的数据；

使用部署流水线，可以将其延展到生产环境，为测试人员和运维团队提供一键式部署系统。

6、在回滚之前