持续集成/持续交付概念

一、概念

传统集成（Traditional integration）

传统集成好比新零售v1.4开发，但是涉及模块众多，例如运营中心经销商管理、产品管理等，从而需要不同的RD负责不同的模块，完成开发后进行集成，并提交代码到仓库，测试完成后部署上线。

随着时间推移，业务的需求日益增多，无论新功能开发还是Bug修复，都需要对系统进行更新迭代。全部开发完成后再集成。

持续集成（Continuous integration）

对传统集成，持续集成是重复的集成，适用于大项目，即团队开发成员经常集成他们的工作，通常每个成员每天至少集成一次，也就意味着每天可能会发生多次集成。每次集成都通过自动化的构建（包括编译，发布，自动化测试）来验证，从而尽早地发现集成错误（修复优先级最高），当前步骤测试不参与。

持续集成目标并不能消除Bug，而是让它们非常容易发现和快速改正，自动化测试case必须全部通过，从而保证高质量的快速迭代。

优点：

快速发现错误。RD每完成一点代码更新，就会从分支合并到Master，可以快速发现及定位错误。

防止分支大幅偏离主干。Master上有其他RD在不断进行代码更新，若分支上没有及时合并，会导致以后集成的难度变大，甚至难以集成，导致集成后bug增多。

持续集成流程

持续交付（Continuous delivery）

持续交付的本质是把每个构建成功的工程进行更新，并交付给用户使用，可理解为业务层面。在持续交付的过程中，我们对交付完成的定义不是测试完成，而是交付给客户。持续交付代表的是功能的上线，交付给用户使用。

优点：

快速获取反馈。RD交付给用户可快速使用相关功能，并很快反馈结果。

适应市场变化和商业策略的变化。开发团队保证每次提交的修改都是可上线的修改，那么决定何时上线，上线哪部分功能则完全由业务方决定。

持续交付流程

持续部署（Continuous deployment）

区别于持续交付，持续部署是在持续交付的基础上，把部署到Prod环境过程通过自动化测试的软件（例 Jenkins）自动构建、部署。尽早部署到生产环境，从而确保部分功能的使用。持续部署的目标是，代码在任何时刻都是可部署的，可以进入生产阶段。（注：在持续集成中问题需要最高优先级修复）

持续部署流程

二、整体流程图

传统方式：

新方式：

三、持续测试（Continuous Tests）

测试是贯穿整个内部研发流程始终的，从持续集成到持续部署，都有测试的存在。

持续集成后，开启单元测试，遍历自动化测试脚本，自动化测试是持续集成的基础，越靠前的测试越应该自动化，且全部Pass状态；

持续交付后，交付给QA后，QA对case的撰写，Review，测试完成后发布到Prod环境。

引用：

https://www.mindtheproduct.com/what-the-hell-are-ci-cd-and-devops-a-cheatsheet-for-the-rest-of-us;

https://www.jianshu.com/p/67f345ebec9b;

《持续集成实践》;