持续集成与极限编程——敏捷开发的方法论

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

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

关于XP极限编程

01. 认识作者

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

02. XP极限编程

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

XP极限编程官方网站：

http://www.extremeprogramming.org/。

包含以下内容：

XP有4个核心价值：

• 沟通(Communication)
• 简单(Simplicity)
• 反馈(Feedback)
• 勇气(Courage)。

XP包含了策划、设计、编程和测试4个活动。

XP的12个最佳实践是指：

• 规划策略(The Planning Game)
• 结对编程(Pair programming)
• 测试(Testing)
• 重构(Refactoring)
• 简单设计(Simple Design)
• 代码集体所有权(Collective Code Ownership)
• 持续集成(Continuous Integration)
• 现场客户(On-site Customer)
• 小型发布(Small Release)
• 每周40小时工作制(40-hour Week)
• 编码规范(Code Standards)
• 系统隐喻(System Metaphor)。

其中，“持续集成”实践在编程和测试活动中贯穿进行。

03. XP实践情况

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

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

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

CI持续集成

01. 持续集成的定义

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

02. CI原则

1. 所有的开发人员需要在本地机器上做本地构建，然后再提交的版本控制库中，从而确保他们的变更不会导致持续集成失败。
2. 开发人员每天至少向版本控制库中提交一次代码。
3. 开发人员每天至少需要从版本控制库中更新一次代码到本地机器。
4. 需要有专门的集成服务器来执行集成构建,每天要执行多次构建。
5. 每次构建都要100%通过。
6. 每次构建都可以生成可发布的产品。
7. 修复失败的构建是优先级最高的事情。
8. 测试是未来，未来是测试。

03. CI的价值

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

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

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

04. 持续交付的定义

与CI持续集成相关又特别容易混淆还有另外几个概念，其中就有持续交付。

持续交付（Continuous delivery，缩写为CD）：

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

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

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

小结

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

著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。