【CI/CD】CI/CD概念了解和学习

一、前言

大家好，我是洋子。CI/CD这个词大家或多或少都听过，甚至在进行软件测试面试时经常会进行考察

那CI/CD到底是什么呢，有的同学认为CI/CD 就是 Jenkins集成，这其实是一种片面的理解，我们可以使用 Jenkins 来实现CI/CD，也可以借助其他工具来实现，如GitLab CI/CD，在互联网大厂基本也有自研的CI/CD工具

 

二、CI/CD概念

CI/CD 是一组简称，注意CD对应了两个名词

• 持续集成（Continuous Integration，CI）、
• 持续交付（Continuous Delivery，CD）
• 持续部署（Continuous Deployment，CD）

CI/CD是实现敏捷开发和Devops理念的一种方法，具体而言，CI/CD 可让持续自动化和持续监控贯穿于应用的整个生命周期（从集成和测试，到交付和部署）。

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

 

 

2.1、持续集成（Continuous integration，CI）

大师 Martin Fowler 对持续集成是这样定义的：持续集成是一种软件开发实践，即团队开发成员经常集成他们的工作，通常每个成员每天至少集成一次，也就意味着每天可能会发生多次集成。每次集成都通过自动化的构建（包括编译，发布，自动化测试)来验证，从而尽快地发现集成错误。许多团队发现这个过程可以大大减少集成的问题，让团队能够更快的开发内聚的软件

通俗的来讲，持续集成就是在开发写完代码后，提交代码准入后自动触发的一系列流程，主要包括：

• 代码编译
• 代码打包
• 单元测试
• 代码静态扫描分析
• UI、接口自动化测试

持续集成（CI）可以帮助开发人员更加频繁地（有时甚至每天）将代码更改合并到共享分支 或 "主干"（master分支）中，另外通过持续集成当中的单元测试、代码扫描、自动化测试我们可以尽早发现新提交的代码引入的问题，从而更加快速修复这些错误

 

2.2、持续交付（Continuous Delivery，CD）

完成以上CI的流程后，持续交付可自动将已验证的代码发布到存储代码库。为了实现高效的持续交付流程，务必要确保 CI 已内置于开发管道。

持续交付的目标是拥有一个可随时部署到生产环境的代码库

在持续交付中，每个阶段（从代码更改的合并，到生产就绪型构建版本的交付）都涉及测试自动化和代码发布自动化。

在流程结束时，运维团队可以快速、轻松地将应用部署到生产环境中。

注意，持续交付在自动化测试和集成结束后，具备部署的能力，但不会自动部署，而是手动部署。

如果有自动部署，则是持续部署的概念了

 

2.3、持续部署（Continuous Deployment，CD）

对于一个成熟的 CI/CD 管道来说，最后的阶段是持续部署。作为持续交付——自动将生产就绪型构建版本发布到代码存储库——的延伸，持续部署可以自动将应用发布到生产环境

由于在生产之前的管道阶段没有手动门控，因此持续部署在很大程度上都得依赖精心设计的自动化测试

实际上，持续部署意味着开发人员对应用的更改在编写后的几分钟内就能生效（假设它通过了自动化测试）。这更加便于持续接收和整合用户反馈。总而言之，所有这些 CI/CD 的关联步骤都有助于降低应用的部署风险，因此更便于以小件的方式（而非一次性）发布对应用的更改。不过，由于还需要编写自动化测试以适应 CI/CD 管道中的各种测试和发布阶段

三、CI/CD小结

• 持续集成: 高频率的将代码合入主干，在合入之前触发单测和集成测试等去验证代码的改动，确保改动不会对应用造成破坏
• 持续交付：将代码合入到代码仓库。其目标是拥有一个可随时部署到生产环境的代码库
• 持续部署：在流程结束时，运维团队可以快速、轻松地将应用部署到生产环境中

四、CI/CD 工具

CI/CD 集成于 CI/CD 工具及代码托管服务。CI/CD 有时也可理解为进行 CI/CD 的构建服务器，而提供 CI/CD 的服务，如以下产品，将会提供构建服务与 GitHub/GitLab 集成在一起

Jenkins
GitLab CI/CD
Travis CI