1.6.2　什么是CI/CD

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

1.高频发布

此处重点反映的是发布频率，由团队自主定义和控制，有些低频的产品或功能按月、按季发布即可，对于一些高频场景，需要系统支持按天、按小时甚至随时发布，也就是按需发布。我所在公司目前发布的频率是500次/天（含测试环境），不同团队或场景的频率方差很大。

2.自动化流程

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

3.可重复

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

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

图1-13　旧版持续部署流程图

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

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