当今的软件开发行业，单靠一两个牛人来完成一个个小型软件的做法早已成为历史，规模各异的团队协同开发慢慢的变成了标配。为保持代码在多人开发的情况下的一致性、及早发现代码的问题，持续集成Continuous Integration（缩写CI）得到了广泛的认可与应用。

  部分研发人员只是片面的理解与执行CI，但对其原理与价值知之甚少。本文旨在分享XP极限编程与CI持续集成的定位与核心价值，让每位研发人员都能够理解其价值，更好的运用。

  极限编程的作者是软件开发大牛Kent Beck，作为”十大Java人物”之一，除了XP之外，同时也对设计模式、敏捷、重构、测试驱动开发、JUnit等诸多主题有着非常大的贡献。他的一系列著作也都是各别领域里面的经典之作，可以让我们深入钻研、并尝试实践来研读与运用。

  极限编程（ExtremeProgramming，简称XP）是Agile敏捷开发的典型代表，同时也是十几种敏捷开发落地方法论中名气与应用最广的其中一种（类似的还有Scrum、Kanban等）。XP本质上是轻量级的、迭代式的软件开发过程。其核心思想是强调人与人之间的协作因素和以敏捷性应对变化。

  XP包含12个最佳实践。早些年在Google等互联网领头羊企业内部率先应用推广，然后不断辐射，从互联网扩展到别的行业，从国外扩展到国内。

  上述12个实践之中，超过半数得到了较广泛的认可与应用。而另外一部分因为不同企业的文化差异，没能得到充分使用或者受限使用。比如：结对编程，两个程序员在一个计算机上共同工作的分工方法。一个人输入代码，而另一个人审查他输入的每一行代码，利用两人同时存在相同盲点概率小的思路进行开发，然而，事实上仅在少量特定项目或模块，或者“老带新”等特定场景比较有机会实践这样的方法。又比如：每周40小时工作制，激烈的竞争下要去实现，更加是一种可望不可即的传说。

  但CI持续集成这一实践却得到了广泛的认可。那些没有实施CI的公司，要么是不了解，要么是因资源等原因暂时不具备实施的条件而已。接下来我们详细说说CI持续集成。

  Martin Fowler（软件开发大师，与Kent Beck合著了《Planning Extreme Programming》）对持续集成是这样定义的：持续集成是一种软件开发实践，即团队开发成员经常集成他们的工作，通常每个成员每天至少集成一次，也就从另一方面代表着每天可能会发生多次集成。每次集成都通过自动化的构建（包括编译，发布，自动化测试）来验证，从而尽快地发现集成错误。

  1. 所有的研发人员需要在本地机器上做本地构建，然后再提交的版本控制库中，从而确保他们的变更不会导致持续集成失败；

  大多数人认为至少包含以下几个方面：减小风险，减少手动过程，生成构建结果，提升安全感。

  事实上CI本身也有成本，主要在于对代码的维护成本和集成的时间成本。随着项目进行，软硬件环境会越来越复杂，代码也会不断膨胀。此时，需要团队而修改或增加原有的测试代码，以适应这些变化，同时，每次集成所需时间也会变长，CI成本相应增加。

  难怪有人说：“这种集成是如此的频繁，多少次的代码Commit就有多少次持续集成。前提是集成的成本很低，或是说完全自动化的”，否则CI本身的成本就很高。

  是一种软件工程手法，让软件产品的产出过程在一个短周期内完成，以保证软件可以稳定、持续的保持在随便什么时间都能释出的状况。它的目标在于让软件的建置、测试与释出变得更快以及更频繁。这种方式能减少软件开发的成本与时间，减少风险。

  CI持续集成是CD持续交付的前提和基础。这两者的区分主要有两点，首先，CI持续集成的范围较小，主要涵盖开发人员编码、自测、与测试人员配合进行的组件级测试。而CD持续交付要进一步进行SIT集成测试等多环境测试，并由用户代表在测试环境进行验证。

  除功能之外，还有必要进行安全性等一系列非功能性测试，以便“证明该系统或模块进行了全面验收，达到了随便什么时间都能上生产的状态”。其次，CI的测试视角仍是开发视角，检测代码或部署包是否有问题，而CD的视角已经转换为业务视角，以用户的身份验证软件系统是不是满足需求。

  阅读到这里，相信我们大家对XP极限编程与CI持续集成的定位与核心价值有了更加清晰准确的认识。理解正确了，才可以更好的进行实践。欢迎各位一起进行实践和探讨。

上一篇：软件开发那家公司强有名的软件研发企业有哪些 下一篇：预见2022这些开源技术将吸引你的眼球