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

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

背景

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

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

概念

持续集成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