【知识科普】广泛应用的敏捷开发方法论，极限编程与持续集成！
【知识科普】广泛应用的敏捷开发方法论，极限编程与持续集成！
部分开发人员只是片面的理解与执行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原则
- 所有的开发人员需要在本地机器上做本地构建，然后再提交的版本控制库中，从而确保他们的变更不会导致持续集成失败。
- 开发人员每天至少向版本控制库中提交一次代码。
- 开发人员每天至少需要从版本控制库中更新一次代码到本地机器。
- 需要有专门的集成服务器来执行集成构建,每天要执行多次构建。
- 每次构建都要100%通过。
- 每次构建都可以生成可发布的产品。
- 修复失败的构建是优先级最高的事情。
- 测试是未来，未来是测试。
【源自】《Object-Oriented Analysis and Design with applications》
03 CI的价值
大多数人认为至少包含以下几个方面：减小风险，减少手动过程，生成构建结果，提升安全感。
事实上CI本身也有成本，主要在于对代码的维护成本和集成的时间成本。随着项目进行，软硬件环境会越来越复杂，代码也会不断膨胀。此时，需要团队而修改或增加原有的测试代码，以适应这些变化，同时，每次集成所需时间也会变长，CI成本相应增加。
难怪有人说：“这种集成是如此的频繁，多少次的代码Commit就有多少次持续集成。前提是集成的成本很低，或者说是完全自动化的”，否则CI本身的成本就很高。
04 持续交付的定义
与CI持续集成相关又特别容易混淆还有另外几个概念，其中就有持续交付。
持续交付（Continuous delivery，缩写为CD）：
是一种软件工程手法，让软件产品的产出过程在一个短周期内完成，以保证软件可以稳定、持续的保持在随时可以释出的状况。它的目标在于让软件的建置、测试与释出变得更快以及更频繁。这种方式可以减少软件开发的成本与时间，减少风险。
CI持续集成是CD持续交付的前提和基础。这两者的区分主要有两点，首先，CI持续集成的范围较小，主要涵盖开发人员编码、自测、与测试人员配合进行的组件级测试。而CD持续交付需要进一步进行SIT集成测试等多环境测试，并由用户代表在测试环境进行验证。
除功能之外，还需要进行安全性等一系列非功能性测试，以便“证明该系统或模块进行了全面验收，达到了随时可以上生产的状态”。其次，CI的测试视角仍是开发视角，检测代码或部署包是否有问题，而CD的视角已经转换为业务视角，以用户的身份验证软件系统是否满足需求。
小结
阅读到这里，相信大家对XP极限编程与CI持续集成的定位与核心价值有了更加清晰准确的认识。理解正确了，才能更好的进行实践。欢迎大家一起进行实践和探讨。