持续集成、持续交付和持续部署

最近在了解项目自动化构建的时候接触到了这三个概念，它们都来自敏捷开发的思想。敏捷的关键在于对变更的快速响应，降低变更所引起的代价，并及时地向客户提交可运行的软件增量。这种方式可以快速交付成功的系统。

背景

传统的软件开发，从需求获取到产品上线，会经历一定的周期，可能数月，可能数年。一旦产品发生了变更，又需要一定时间才能将更新发布上线。这个周期如果很长，将会给竞争者带来机会并占领市场，用户也需要等待很久才能看到自己想要的产品。所以，至关重要的一点就是缩短周期时间，这个时间包括设计、开发、测试、部署等阶段。于是就有了持续集成，持续交付，持续部署这三个概念，它们旨在缩短这个周期时间，强调在任何时刻软件都处于可发布的状态。这样我们可以及时地将软件发布出来，交由客户使用，并且及时得到客户的反馈，产生新的更好的版本。

这三个过程都强调持续性，也就是说，每完成一个部分，就向下一个环节交付，及时发现问题，及时调整。因为不可能在事先就知道完整、正确的需求是什么样的，同时客户的需求也在不断变化，所以，应该尽量缩短从获取需求、开发、测试到部署等一系列活动的周期，尽快给用户展现可用的产品，并及时得到反馈，逐步求精。

概念

持续集成Continuous Intergration：频繁地、及时地将代码集成到主干。好处是快速发现错误，防止分支大幅偏离主干。核心措施是，代码在集成到主干之前，必须通过自动化测试，根据测试结果，所有测试用例都成功之后才能确定新代码和原有代码可以成功集成在一起。

持续交付Continuous Delivery：将软件的新版本，交付给质量团队或者用户，以供评审。它是持续集成的下一步，强调的是，不管怎样更新，软件都是随时可以交付的。

持续部署Continuous Deployment：当交付的代码通过评审之后，自动部署到生产环境中。它是持续交付的下一步，能够自动化完成测试、构建、部署等步骤。

流程

1. 开发者向代码仓库提交代码，这叫一次commit。
2. 当代码仓库检测到这次commit之后，会进行第一轮测试。通常代码仓库会对commit操作配置钩子（hook），由钩子来执行相应的测试程序。
3. 通过了第一轮测试，这次commit就可以成功地合并到主干了。这时候就完成了集成阶段，可以进入到交付阶段了。
4. 在代码交付阶段，会先进行构建，将源代码转换为可以运行的程序。这一步也可以在第一轮测试之前进行。
5. 构建完成之后，会进行第二轮测试。所有的测试工作都会进行，包括单元测试、集成测试等等。以自动化测试为主，辅以人工测试。这个过程必须保证所有更新点都被测试到，否则将不能保证部署阶段的质量。
6. 通过了第二轮测试之后，当前代码就可以部署到生产服务器了。此时会生成当前代码的一个可部署版本，将这个文件打包存档，发布到生产服务器上。
7. 如果当前版本发生了问题，可以回滚到上一个版本的构建结果。

参考

1. The Product Manager’s Guide to Continuous Delivery and DevOps

2. Continuous Delivery vs Continuous Deployment

3. Continuous Intergration Essentials