CI/CD的流程与概念

流程

自动化部署 CI/CD 是一种通过在应用开发阶段引入自动化来频繁向客户交付应用的方法。CI/CD 的核心概念是持续集成、持续交付和持续部署。作为一个面向开发和运营团队的解决方案，CI/CD 主要针对在集成新代码时所引发的问题（亦称：“集成地狱”）。

本 Chat 将从流程以及原理入手到实战演练，技术栈/关键词：

• Gitlab-CI

• Docker

• Maven

• Google Jib

• Nexus
  适宜人群

• 微服务架构工程师

• Java 开发人员
  

概念

CI/CD是常见的不停机发布方式。CI (Continuous Integration)持续集成，CD (Continuous Delivery)持续交付，CD (Continuous Deployment)持续部署，这三个概念构成一条连续的代码集成发布链。分别对应逻辑中的build-test-deploy。

CI：持续集成（CONTINUOUS INTEGRATION）

基本概念
CI的全称是Continuous Integration，表示持续集成。

在CI环境中，开发人员将会频繁地向主干提交代码。这些新提交的代码在最终合并到主干前，需要经过编译和自动化测试流进行验证。

持续集成过程中很重视自动化测试验证结果，以保障所有的提交在合并主线之后的质量问题，对可能出现的一些问题进行预警。

需要具备的条件

• 团队需要为每个新功能、代码改进、或者问题修复创建自动化测试用例。

• 你需要一个持续集成服务器，它可以监控代码提交情况，对每个新的提交进行自动化测试。

• 研发团队需要尽可能快的提交代码，至少每天一次提交。
  带来的效益

• 通过自动化测试可以提早拿到回归测试的结果，避免将一些问题提交到交付生产中。

• 发布编译将会更加容易，因为合并之初已经将所有问题都规避了。

• 减少工作问题切换，研发可以很快获得构建失败的消息，在开始下一个任务之前就可以很快解决。

• 测试成本大幅降低，你的CI服务器可以在几秒钟之内运行上百条测试。

• 你的QA团队花费在测试上面的时间会大幅缩短，将会更加侧重于质量文化的提升上面。

CD：持续部署（CONTINUOUS DEPLOYMENT）

基本概念
CD的全称是Continuous Deployment，表示持续部署。

在CD环境中，通过自动化的构建、测试和部署循环来快速交付高质量的产品。某种程度上代表了一个开发团队工程化的程度，任何修改通过了所有已有的工作流就会直接和客户见面，只有当一个修改在工作流中构建失败才能阻止它部署到产品线。

持续部署是一个很优秀的方式，可以加速与客户的反馈循环，但是会给团队带来压力，因为不再有“发布日”了。开发人员可以专注于构建软件，他们看到他们的修改在他们完成工作后几分钟就上线了。

基本上，当开发人员在主分支中合并一个提交时，这个分支将被构建、测试，如果一切顺利，则部署到生产环境中。

需要具备的条件

• 研发团队测试理念比较完善。测试单元的健壮性直接决定你的交付质量。

• 你的文档和部署频率要保持一致。

• 特征标志成为发布重大变化过程的固有部分，以确保您可以与其他部门（支持，市场营销，公关…）协调。
  带来的效益

• 发布频率更快，因为你不需要停下来等待发布。每一处提交都会自动触发发布流。

• 在小批量发布的时候，风险降低了，发现问题也可以很轻松的修复。

• 客户每天都可以看到我们的持续改进和提升，而不是每个月或者每季度，或者每年。

CD：持续交付（CONTINUOUS DELIVERY）

基本概念
持续交付的英文全称是：Continuous delivery，缩写也是CD，它是一种软件工程手法。

它可以让软件产品的产出过程在一个短周期内完成，以保证软件可以稳定、持续的保持在随时可以释出的状况。它的目标在于让软件的建置、测试与释出变得更快以及更频繁。这种方式可以减少软件开发的成本与时间，减少风险。

有时候，持续交付也与持续部署混淆。持续部署意味着所有的变更都会被自动部署到生产环境中。持续交付意味着所有的变更都可以被部署到生产环境中，但是出于业务考虑，可以选择不部署。如果要实施持续部署，必须先实施持续交付。

需要具备的条件

• 你需要有强大的持续集成组件和足够多的测试项可以满足你代码的需求。

• 部署需要自动化。触发是手动的，但是部署一旦开始，就不能人为干预。

• 你的团队可能需要接受特性开关，没有完成的功能模块不会影响到线上产品。
  带来的效益

• 繁琐的部署工作没有了。你的团队不在需要花费几天的时间去准备一个发布。

• 你可以更快的进行交付，这样就加快了与客户之间的反馈环。

• 轻松应对小变更，加速迭代。