持续集成 Continuous Integration 简称：CI，是起源于XP的核心实践。当开发人员协作并大量编写代码时，将代码签入版本控制存储库（可能一天内多次）并与现有代码库集成是很重要的。代码的频繁合并有助于防止或快速解决任何代码冲突问题。一旦代码检入（Check-in），它需要编译（Compile）（例如，成字节码）构建（来产生可执行文件），部署（手动或自动），然后测试（冒烟测试、自动化测试、回归测试）来证明这些变化相互兼容，没有被打破。
XP提出，整个项目过程中，应该频繁地，尽可能地整合已经开发完的User Story（每次整合一个新的用户故事）。每次整合，都要运行相应的单元测试和验收测试，保证符合客户和开发的要求。整合后，就发布一个新的应用系统。这样，整个项目开发过程中，几乎每隔一两天，都会发布一个新系统，有时甚至会一天发布好几个版本。通过这个过程，客户能非常清楚地掌握已经完成的功能和开发进度，并基于这些情况开发人员进行有效地、及时地交流，以确保项目顺利完成。著名的微软公司就有每日集成（Daily Build）的成功实践。

SVN的全称是Subversion，即版本控制系统

CI的目标：

• 快速获得执行反馈。
• 快速发现并解决问题，节省时间和精力。
• 降低了一次性大爆炸集成的风险，这种集成发生在传统的基于瀑布的项目中，存在许多问题和问题。
• 支持持续交付有价值的软件增量到生产。
• 增加协作量，因为所有团队成员都坚持使用统一的工具和规程。

当团队成员分布在多个地点或时区时，这些任务中的大多数会变得复杂。为了管理这种情况，CI的概念被扩展到分布式持续集成(DCI)。这主要是基于共同的原则、规程和工具，这些都是团队成员集体同意的，并且无论他们在做什么和什么时候都要严格遵守的。例如，团队成员可以同意，只有可以编译的代码可以检入到集成分支中，或者只有通过了所有自动化单元测试用例的代码可以在集成构建期间被标记和提取。像Jenkins、cruiscontrol、Teamcity和Bamboo这样的商业工具可以处理这些操作，事实证明对于敏捷开发人员来说非常方便。请注意，为了有效地使用CI及其相关的工具，在获取工具、提供专用的构建服务器(和构建代理)以在一天内运行几个构建(包括并发的构建)并培训团队成员如何使用它们的背后，有一个预先的投资。所有这些都应该在项目的开始，活动开发开始之前完成，也许是在迭代0期间。只要每个团队成员都遵守原则，CI的整体概念就会紧密结合在一起，否则其有效性会迅速退化。尽管如此，持续集成的好处是如此之多，以至于大多数团队像海绵一样吸收了这些概念，因为价值和效率从第一天起就实现了。现在让我们来看看CI中的一些最佳实践。

最佳实践：

由于每个敏捷团队都可以自由地选择最适合他们的方法，因此在持续集成中有一组最佳实践，这些实践在被采用后被证明会产生积极的结果。

• 使用一致的IDE或集成开发环境——尽管市场上有很多IDE，但开发团队使用一致的IDE是很方便的。IDE应该聪明地突出编译错误，能够轻松地与源代码控制存储库集成，运行构建并根据团队的需求进行扩展。否则，在配置、行为、代码呈现以及与其他工具集和插件的集成方面可能会有细微的差异。
• 检查代码质量(技术债务)——团队应该同意一组编码约定和规则，这些约定和规则应该在代码提交之前自动检查。此外，在代码重构期间还应消除技术债务。用于检查代码质量的优秀开源平台的一个例子是SQALE。
• 执行对等代码审查——开发人员应该有能力使用像Fisheye和Crucible这样的工具进行智能的对等代码审查(除了结对编程)。
• 使用版本控制策略——团队可以使用SVN（Subversion）、GIT、Stash和Artifactory等工具进行配置管理和版本控制。在这样做的时候，他们应该同意遵守一些约定。其中一些可能看起来像:
• 只允许测试代码被检入。
• 将所有需要版本控制的东西都存储在一个地方，建议放在子文件夹中——代码、单元测试用例、第三方库、数据库脚本、配置和文档。
• 通过简单地将版本控制(如GIT、SVN等工具)中的代码导入开发人员的工作区或测试环境，在任何时候都应该准备好部署，而不需要额外的依赖(如第三方库)。
• 团队成员应该定期提交他们的更改，这样他们保持排他锁的时间不会超过一天。
• 开发者应该给属于某个迭代或发布的代码贴上标签，这样它们就可以作为一个整体被引用。如果某个特定构建中断，团队成员应该能够使用此标签或标记恢复到上一个工作版本。
• 团队应该在分支和合并策略上达成一致。例如，他们可以保持主干(主要分支)与生产版本同步，同时在单独的分支中处理每个迭代。当代码发布到生产时，分支可以与主干合并。
• 自动化构建和部署-使用cruiscontrol、Teamcity等工具。或者Hudson，团队应该能够构建可执行文件并通过点击按钮来部署它们。团队应该能够在仪表板上监视当前和以前的构建报告的状态，或者在出现中断时通过电子邮件警报得到通知。构建还应该触发代码质量检查和测试回归套件的运行，以确定软件的神圣性。
• 加快构建速度——构建速度应该快(例如少于10分钟)，这样就可以轻松地反复运行，而不会有任何长时间的等待。
• 对生产质量测试数据进行投资——这样测试周期就能代表生产过程中会发生什么。测试数据填充可以与部署任务集成。一些数据可以从生产中复制(并通过删除敏感信息(如客户详细信息)进行消毒)，并上传到测试环境。如果与其他系统和外部应用程序的接口不可用，则可以根据需要将其虚拟化为服务。
• 演示所构建的内容——为了演示的目的，不要准备单独的构建，因为它会破坏评审的目的。理想情况下，用于演示的运行时环境应该始终处于允许随时进行探索性测试的状态。