什么是 CI/CD

CI（Continuous Integration，持续集成）与 CD（Continuous Deployment，持续部署）两者整合起来反映的是持续交付（Continuous Delivery）的能力。在互联网时代的商业竞争中，企业都会追求闪电式扩张，快速发布 MVP（Minimum Viable Product，最简化可实行产品）版本，快速试错。代码越早上线，用户就可以越早用到新的特性，企业也就可以越快实现商业价值。得到用户反馈，产品才能及时修正。如果需求不断积压、合并，新的特性代码库得不到及时交付，代码间交叉感染的概率会越来越大，进而影响线上的业务。CI/CD 是否高效，流水线是否敏捷，直接关系到业务迭代的效率高低。

CI/CD 的重点在于持续，持续并不是一直运行，而是“随时”可运行。在软件开发领域，CI/CD 重点涵盖如下几个方面。

1. 高频发布

此处重点反映的是发布频率，由团队自主定义和控制，有些低频的产品或功能按月、按季发布即可，对于一些高频场景，需要系统支持按天、按小时甚至随时发布，也就是按需发布。

有了 CI/CD 平台后，代码合并、分支都是平台管理的，避免出现手工合并代码导致的漏洞。

在 CI/CD 流水线中，往往会有些钩子的扩展，如项目管理、测试用例、代码审查、代码 Bug 清单、安全 Bug 清单等扩展功能，会极大提升代码交付的质量。同时可以提供灰度发布、分批发布、金丝雀发布、蓝绿部署等多种校验形式，便于代码更高质量的验证与交付。

2. 自动化流程

实现高频发布的关键是流程自动化，尽量减少人工的参与和卡点的控制，能够线上解决的不要混合线下交互，尽量让研发人员可以通过自动化工具自主完成上线流程。

CI/CD 的出现把这些重复的劳动全部交给平台自动完成，大大解放了生产力。有了 CI/CD 平台后，开发人员完全可以自助发布，1 个小时内轻松完成一个应用的上线流程。

3. 可重复

高频发布对于源代码的管理和制品的版本管理有很高的要求，历史版本要明晰，可以快速根据不同的版本进行回滚。

整个代码从源代码到上线的生命周期包括代码仓库检出分支、编写特性代码、提交到远程仓库、代码构建（编译、构建、打包、发布）、测试（单元测试、静态代码扫描、安全测试、功能测试）、修改漏洞、重新构建、提交到线上、金丝雀发布、蓝绿部署、全量部署、分支合并到主干、打标签等阶段。

把研发工程师提交代码到远程仓库，通过 Jenkins 或者 GitLab CI 自动拉取源代码、代码检测、编译打包、单元测试的过程称作 CI（持续集成）的过程。一旦开发人员对应用所做的更改被合并，系统就会通过自动构建应用并运行不同级别的自动化测试来验证这些更改，确保这些更改没有对应用造成破坏。如果自动化测试发现新代码与旧代码之间存在冲突，CI 过程可以更加轻松、快速地修复这些错误。

测试环境验证通过之后，开发人员需要把更改的功能发布到生产环境，供用户使用。如何高效、准确、自动化地把新功能发布到生产环境，是 CD 环节聚焦的内容。为了保障这个过程的可持续，一般都会进行分批发布和灰度发布。分批发布是为了避免单一服务器的手工操作，提高大批量发布任务的并行效率；灰度发布是为了更加稳妥、高质量地替换老的功能，使用户体验更加平滑。