【测试】三张图解读 CI/CD

前言

大家好，我是洋子。昨天写了一篇文章《CI/CD是什么》，介绍了持续集成，持续交付，持续部署的概念

对于初次接触CI/CD的同学，可能还是难以理解。今天我就基于上篇文章当中用到的3张图片再次解读一下CI/CD

CI/CD 的概述

CI/CD 是一种在开发阶段引入自动化来频繁向客户交付应用的方法

CI/CD 的核心概念是持续集成、持续交付和持续部署。它是作为一个面向开发和运维团队的解决方案，主要针对在集成新代码时所引发的问题

CI/CD 可让持续自动化和持续监控贯穿于应用的整个生命周期（从集成和测试阶段，到交付和部署）

这些关联的事务通常被统称为 CI/CD 管道（pipeline），由开发和运维团队以敏捷方式协同支持

CI持续集成（Continuous Integration）

持续集成，从字面意思上理解，就是不断的集成

持续集成（CI）可以帮助开发者更加方便地将代码更改合并到主分支

举一反三，持续集成让合并到其他分支也会更加方便，开发流程一般会先合入其他分支，在测试完毕以后，在最后阶段才会合入主干

解读一下上面这张图

• 开发人员(代号，10101)提交代码到 Source Repository (源代码仓库，如 GitLab)
• 有代码更新到代码仓库后，会通过 WebHook 自动触发 CI Server(持续集成服务器，如 Jenkins)的相关功能，执行编译-测试-输出结果的流程，这里的测试一般只包含单元测试，不是我们常说的点点点功能测试，也不是接口测试
• CI Server 会将执行结果返回给开发人员

持续集成小结

• 持续集成仅仅是让所有开发提交的代码成功集成到代码库中并正常协同工作
• 但并没有经过测试工程师的功能测试，所以集成的代码并不能马上发布到生产环境

CD 持续交付（Continuous Delivery）

持续交付是一种软件工程方法，团队可以在短时间内生产软件，以确保可以随时可靠、手动发布软件

CI 在完成了构建、单元测试这些自动化流程后，持续交付可以自动把已验证的代码发布到企业自己的存储库

解读上面这张图，与第一张持续集成的图片对比看到多了3个流程

• 代码提交（CI已包括）
• 单元测试（CI已包括）
• 合入代码（CI已包括）
• 测试(Test)：接口或UI自动化测试、集成测试、系统测试等
• 先部署到预发环境(预生产环境，Staging)：测试人员在预发环境进行产品的主流程验证，验证通过再执行下一步
• 手动部署到生产环境(Production)：开发手动部署

持续交付小结

• 持续交付是持续集成的延伸，将集成后的代码部署到类生产环境，确保以可持续的方式快速向客户发布新的更改
• 经过持续交付，即可手动部署到生产环境
• 持续集成的重点是集成代码，但持续交付的重点是可交付的产品。可交付的产品一定要有达标的质量，确保产品在生产环境没问题，所以在CI集成代码之后，还需要进行自动化测试、集成测试

CD 持续部署（Continuous Deployment）

通过自动化部署的手段将软件功能频繁的进行交付

解读上图，与第二张持续交付的图片对比后，发现只有一点差别，就是自动化部署生产（Production）环境

所以说，持续部署与持续交付之间的差异就是前者将部署自动化，开发人员提交代码到编译、测试、部署的全流程都不需要人工干预，完全自动化执行

持续部署小结

• 明确持续交付和持续部署的区别
  持续交付：代码最终部署到生产环境的过程是手动的(Manual)
  持续部署：代码最终部署到生产环境的过程是自动化的(Auto)

结尾语

CI/CD 中的“CD”指的是持续交付或持续部署

持续交付（第一种CD）通常是指开发人员对应用的更改会自动进行错误测试并上传到存储库（如 GitHub 或容器注册表），然后由运维团队将其部署到实时生产环境中

持续部署（另一种“CD”）指的是自动将开发人员的更改从存储库发布到生产环境，以供客户使用

归根结底，我们没必要纠结于这些语义，您只需记得 CI/CD 其实就是一个流程（通常形象地表述为管道），用于实现应用开发中的高度持续自动化和持续监控

许多企业最开始先添加 CI，然后逐步实现交付和部署的自动化

在写这篇文章前，我基本上翻了几十篇关于CI/CD的文章，目前的心得体会，CI/CD追求的是快速和自动化。但我在百度的工作经历当中，CI阶段基本上已经完全自动化，但是在最后的上线部署阶段，还是需要人工参与

如下图，在分级上线发布时，我们除了人工验证外，还添加的上线时的自动化测试，保障质量，想要完全实现生产环境部署自动化，个人认为还是有一段比较长的路要走

如果你觉得这篇文章还不错的话，麻烦点一个【赞】和【在看】，让更多的小伙伴能发现它