这两天在TeamCity（一个Continuous integration 系统）上配置自己负责的一个Project，mark一下对**持续集成（Continuous integration）**的理解。

在传统软件开发过程中，集成通常发生在每个 developer 都完成了各自的代码开发工作之后。在项目尾声阶段，通常集成还要痛苦的花费数周或者数月的时间来完成。如今，更强调敏捷开发、快速迭代的概念。持续集成满足了这一需求，是指将集成提前至开发的过程中的一种实践方式，让构建、测试和集成代码更经常反复地发生。

我们经常会听到持续集成，持续交付，持续部署，三者究竟是什么，有何联系和区别呢?

假如把开发工作流程分为以下几个阶段：

编码 -> 构建 -> 集成 -> 测试 -> 交付 -> 部署

正如你在上图中看到，**「持续集成(Continuous Integration)」、「持续交付(Continuous Delivery)」和「持续部署(Continuous Deployment)」**有着不同的软件自动化交付周期。

持续集成（Continuous Integration）

持续集成（Continuous Integration）是指软件个人 developer 的代码频繁地集成到主干代码中。“持续集成”本质是一个代码开发实践，源自于极限编程(XP)，是 XP 最初的 12 种实践之一。

集成：其实就是指将新开发完成的代码合并到主干分支中。

持续集成的好处

快速发现代码错误

在集成前，进行相应的自动化单元测试，若存在任何的单元测试失败，在Bug fixed 前，拒绝集成。

这样做的好处是可以快速的暴露代码错误，且保证主干代码的健康。具体来说，可以跟踪因何处新加的代码或者修改的代码引起了错误。但存在一个前提，需要存在较为完善的单元测试用例。

提升迭代速度

所有的单元测试，都在CI agent（CI系统中自动执行单元测试的机器）上自动触发，不占用开发者自身的操作系统资源。且每当完成一个Feture开发，就集成到主干代码中，这使得产品可以快速迭代，同时保证高质量。

注意："持续集成并不能消除Bug，而是让它们非常容易发现和改正。"

提高代码的质量

在持续集成系统中，可以检查代码规范（Code Style）、单元测试覆盖率（Unit Test Coverage)和单元测试通过率等指标。

持续集成的特点

自动构建：要求无人值守，如果人工来操作，那就没有持续集成的必要了。
发现版本库的变更：通过轮询或者定时，或者程序员使用命令，处理持续集成发现版本库的变更
反馈机制：在出现问题时，能及时的把问题反馈给正确的人（提交者、测试者、管理者）
回滚：在出现问题后，拥有回滚到可交付的能力。
纯净的构建环境：每一次都应该把之前的环境删除干净，让每一次构建都是一个新的构建。
完善的集成功能：代码的测试，审查都应该做到完善。如果单纯的利用它做持续的编译，那就是大材小用了。

持续交付（Continuous Delivery）

持续交付（Continuous delivery）建立在持续集成的基础之上，指的是可频繁的小粒度的短周期的将软件的新版本交付给使用者或质量团队，以提供评审。如果评审通过，则可手动部署到生产环境。频繁的交付周期带来了更迅速的对软件的反馈，并且在这个过程中，各个角色密切协作，相比于传统的瀑布式软件团队，更少浪费。

持续交付可以看作持续集成的下一步。它更多强调的是，不管代码怎么更新，软件是随时随地都可以交付的。

持续部署（Continuous Deployment）

**持续部署（continuous deployment）**则是在持续交付的基础之上，指的是代码通过评审以后，可自动部署到生产环境。

持续部署的目标是，代码在任何时刻都是可部署的，即可以进入生产阶段。

【Engineering】持续集成（Continuous integration）