下载掌阅APP，畅读海量书库
立即打开
发布与部署是开发过程中最常见的动作，高效的流程、丰富的工具能够使整个交付过程更加快速。CI/CD是云原生中非常重要的一个组件，只有高效的CI/CD流程才能使云原生的弹性、效率发挥出更大的价值。
大多数技术公司的软件交付模式都经历过从瀑布模型到敏捷开发的阶段，同时软件的交付周期也从年、季、月逐步缩短到双周、周。随着互联网2.0、3.0时代的到来，企业对用户体验的响应也要求更加及时，软件功能的发布也逐步缩短到周和天，甚至可以随时发布。在这样的背景下，CI/CD也就应运而生了。
CI（Continuous Integration，持续集成）与CD（Continuous Deployment，持续部署）两者整合起来反映的是持续交付（Continuous Delivery）的能力。在互联网时代的商业竞争中，企业都会追求闪电式扩张，快速发布MVP（Minimum Viable Product，最简化可实行产品）版本，快速试错。代码越早上线，用户就可以越早用到新的特性，企业也就可以越快实现商业价值。得到用户反馈，产品才能及时修正。如果需求不断积压、合并，新的特性代码库得不到及时交付，代码间交叉感染的概率会越来越大，进而影响线上的业务。CI/CD是否高效，流水线是否敏捷，直接关系到业务迭代的效率高低。
CI/CD的重点在于持续，持续并不是一直运行，而是“随时”可运行。在软件开发领域，CI/CD重点涵盖如下几个方面。
此处重点反映的是发布频率，由团队自主定义和控制，有些低频的产品或功能按月、按季发布即可，对于一些高频场景，需要系统支持按天、按小时甚至随时发布，也就是按需发布。我所在公司目前发布的频率是500次/天（含测试环境），不同团队或场景的频率方差很大。
实现高频发布的关键是流程自动化，尽量减少人工的参与和卡点的控制，能够线上解决的不要混合线下交互，尽量让研发人员可以通过自动化工具自主完成上线流程。
高频发布对于源代码的管理和制品的版本管理有很高的要求，历史版本要明晰，可以快速根据不同的版本进行回滚。
整个代码从源代码到上线的生命周期包括代码仓库检出分支、编写特性代码、提交到远程仓库、代码构建（编译、构建、打包、发布）、测试（单元测试、静态代码扫描、安全测试、功能测试）、修改漏洞、重新构建、提交到线上、金丝雀发布、蓝绿部署、全量部署、分支合并到主干、打标签等阶段，如图1-13所示。
图1-13 旧版持续部署流程图
我们把研发工程师提交代码到远程仓库，通过Jenkins或者GitLab CI自动拉取源代码、代码检测、编译打包、单元测试的过程称作CI（持续集成）的过程。一旦开发人员对应用所做的更改被合并，系统就会通过自动构建应用并运行不同级别的自动化测试来验证这些更改，确保这些更改没有对应用造成破坏。如果自动化测试发现新代码与旧代码之间存在冲突，CI过程可以更加轻松、快速地修复这些错误。
测试环境验证通过之后，开发人员需要把更改的功能发布到生产环境，供用户使用。如何高效、准确、自动化地把新功能发布到生产环境，是CD环节聚焦的内容。为了保障这个过程的可持续，一般都会进行分批发布和灰度发布。分批发布是为了避免单一服务器的手工操作，提高大批量发布任务的并行效率；灰度发布是为了更加稳妥、高质量地替换老的功能，使用户体验更加平滑。
我经历过比较低效的CI/CD流程，开发人员提交代码→主管审核并合并到主干→找测试人员进行Jenkins打包→测试验证→找配置工程师抽取部署包→发邮件给运维人员提交发布→找运维人员排队上线，往往这个流程结束时已经是凌晨。集成、合并代码、配置、提测、提交发布单、找人这些重复性的工作每次发布都要重新并频繁地进行。重复即意味着可优化，CI/CD的出现把这些重复的劳动全部交给平台自动完成，大大解放了生产力。有了CI/CD平台后，开发人员完全可以自助发布，1个小时内轻松完成一个应用的上线流程。
之前我的团队经常遇到代码合并的问题，当从测试环境进入准生产环境时，要将代码合并到主干，这个过程经常出现少合、合错的问题，往往在新一轮的测试验证中发现重复的漏洞，到了生产环境可能又有因为人工参与导致的低级错误。有了CI/CD平台后，代码合并、分支都是平台管理的，避免出现手工合并代码导致的漏洞。
提到CI/CD不得不提环境问题和代码分支模型，很多公司有测试环境、预发环境、生产环境、集成环境、二套环境等，每个人的认知和过往经验对环境的认知都是不一样的，这样就会导致团队间的语言不统一。除了环境，另一个不统一的概念是分支模型，有的团队是基于主干开发，有的团队是基于开发（Develop）分支，有的团队是基于特性分支。因为分支开发模式的千差万别，导致分支的管理和运维成本急剧上升。通过CI/CD平台，所有的环境和分支模型都被平台化，开发人员无须关注任何一个细粒度的底层操作，团队间的认知也提升到了一个统一的位置，发布效率也随之大大提升。
在发布流程之前，我还经历过通过邮件提交上线计划、手工抽取部署包的原始发布流程，这种低效的发布流程往往会导致排队上线到凌晨。为了保证上线质量，流程上往往会规范周二、周四才允许上线的窗口期。有了CI/CD平台后，开发人员可以在任意时间自主发布，我所在的团队每天平均发布500次，如果没有CI/CD平台的支持，如此高频的发布是无法想象的。
在CI/CD流水线中，往往会有些钩子的扩展，如项目管理、测试用例、代码审查、代码Bug清单、安全Bug清单等扩展功能，会极大提升代码交付的质量。同时可以提供灰度发布、分批发布、金丝雀发布、蓝绿部署等多种校验形式，便于代码更高质量的验证与交付。