# 持续集成 Continuous Integration
## 定义
练习持续集成的团队追求两个目标：
- 最小化每个整合阶段所需的时间和精力
- 能够提供适合随时发布的产品版本
实际上，这个双重目标需要一个集成程序，该程序至少是可重现的，并且在很大程度上是自动化的。这是通过版本控制工具，团队策略和约定以及专门用于帮助实现持续集成的工具来实现的。
## 常见陷阱
- 如上所述，持续集成的做法不应与辅助工具（如Cruise Control，Hudson等CI服务器）混淆。持续集成首先是态度问题，而不是工具问题，它依赖于多种工具：用于测试的工具，用于自动构建过程的工具以及用于版本控制的工具。
- 持续集成旨在通过增加集成频率来减轻集成的痛苦。因此，与产生中间发行版相关的“任何”工作（团队特别费力的工作）都可以纳入团队的持续集成过程。（这就是导致团队 不断进行部署的原因。）
## 起源
- 1993年：“持续集成”一词已被使用，因此早于后来被称为敏捷过程的术语，例如，一篇文章将其与“计划的”集成进行了对比，并建议后者，将“缺乏全面的测试”作为一个建议。持续集成的问题；这有助于解释为什么敏捷团队偏爱的自动化测试可以实现持续集成
- 1996年：史蒂夫·麦康奈尔（ Steve McConnell）描述了1990年代在Microsoft Windows NT 3.0上使用的“每日构建和冒烟测试”技术；重点不是自动化，而是频率，当时的每日周期被认为是“极端”
- 1998年：持续集成被列为极限编程的核心实践之一
- 2000年：马丁·福勒（Martin Fowler）的文章提供了当时可用的持续集成实践的最完整描述。
- 2001年：第一个“连续集成服务器” Cruise Control在开源许可下发布；它可以自动监视源代码存储库，触发构建和测试过程，将结果通知开发人员以及测试报告的存档；在2001年至2007年期间，出现了许多类似的工具，这可能导致过度重视工具而不是实践
- 2004年：Alberto Savoia 的一篇文章提出了“极端反馈设备”，例如熔岩灯或专用显示器，以显示最新集成的结果，这是CI中的一项重要创新
## 使用迹象
对于大多数团队而言，实践中的持续集成包括以下内容：
- 使用版本控制工具（CVS，SVN，Git等）
- 一个自动构建和产品释放过程
- 检测构建过程以触发单元和接受测试“每次将任何更改发布到版本控制时”
- 即使单个测试失败，也要警告团队“构建失败”，以便团队可以尽快达到稳定的，可释放的基准
- 可选地，使用诸如连续集成服务器之类的工具，该工具可以自动完成集成，测试和报告测试结果的过程
在团队会议室的显眼位置寻找专用显示器：这可以是普通显示器，LED显示器，甚至是熔岩灯，其唯一目的是报告最新整合的结果。
还观察团队如何响应损坏的构建，表明可能已检测到缺陷。如果团队意识到缺陷，但可以容忍缺陷或继续对处于非发布状态的产品进行操作，则无论使用何种工具，术语“持续集成”都不再适用！
## 进一步阅读
[持续集成](http://www.martinfowler.com/articles/continuousIntegration.html)，马丁·福勒（2006）
点击看敏捷名词地铁线路全图