目录

一、“持续”是什么意思？

二、CI/CD 概述

2.1 CI：持续集成

2.2 CD：持续部署

2.3 持续交付（Continuous Delivery） 

三、持续集成(CI) / 持续部署(CD)的优势

四、我们熟知的CI/CD工具都有哪些？

4.1GitLab CI

4.2 Jenkins

4.3 Jenkins vs GitLab CI/CD 的功能对比

4.4 Jenkins vs GitLab CI/CD 优缺点  

4.4.1 Jenkins 的优点

4.4.2 Jenkins 的缺点

4.4.3 GitLab CI/CD 的优点

4.4.4 GitLab CI/CD 的缺点

4.5 Jenkins vs GitLab CI/CD 如何选？

前言：

工厂里的组装线以快速、自动化、可重复的方式从原材料生产出消费品。同样，软件交付管道以快速、自动化和可重复的方式从源代码生成发布版本。如何完成这项工作的总体设计称为“持续交付”（CD）。启动组装线的过程称为“持续集成”（CI）。确保质量的过程称为“持续测试”，将最终产品提供给用户的过程称为“持续部署”。一些专家让这一切简单、顺畅、高效地运行，这些人被称为运维开发DevOps践行者。

一、“持续”是什么意思？

“持续”用于描述遵循我在此提到的许多不同流程实践。这并不意味着“一直在运行”，而是“随时可运行”。在软件开发领域，它还包括几个核心概念/最佳实践。这些是：

频繁发布：持续实践背后的目标是能够频繁地交付高质量的软件。此处的交付频率是可变的，可由开发团队或公司定义。对于某些产品，一季度、一个月、一周或一天交付一次可能已经足够频繁了。对于另一些来说，一天可能需要多次交付也是可行的。所谓持续也有“偶尔、按需”的方面。最终目标是相同的：在可重复、可靠的过程中为最终用户提供高质量的软件更新。通常，这可以通过很少甚至无需用户的交互或掌握的知识来完成（想想设备更新）。

自动化流程：实现此频率的关键是用自动化流程来处理软件生产中的方方面面。这包括构建、测试、分析、版本控制，以及在某些情况下的部署。

可重复：如果我们使用的自动化流程在给定相同输入的情况下始终具有相同的行为，则这个过程应该是可重复的。也就是说，如果我们把某个历史版本的代码作为输入，我们应该得到对应相同的可交付产出。这也假设我们有相同版本的外部依赖项（即我们不创建该版本代码使用的其它交付物）。理想情况下，这也意味着可以对管道中的流程进行版本控制和重建（请参阅稍后的 DevOps 讨论）。

快速迭代：“快速”在这里是个相对术语，但无论软件更新/发布的频率如何，预期的持续过程都会以高效的方式将源代码转换为交付物。自动化负责大部分工作，但自动化处理的过程可能仍然很慢。例如，对于每天需要多次发布候选版更新的产品来说，一轮集成测试integrated testing下来耗时就要大半天可能就太慢了。

二、CI/CD 概述

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

CI/CD的核心概念是持续集成、持续交付和持续部署。指在开发过程中自动执行一系列从开发到部署的过程中，尽量减少人工的介入。

具体来说，CI/CD可让持续自动化和持续监控贯穿于应用的整个生命周期（从集成和测试阶段，到交付和部署）。这些关联的事务统称为“CI/CD管道”，由开发和运维团队协同支持。

CI指的是持续集成，CD指的是持续交付和持续部署。合在一起通常包含这几个过程：

2.1 CI：持续集成

持续集成是指多名开发者在开发不同功能代码的过程当中，可以频繁的将代码行合并到一起并切相互不影响工作。

持续集成的目的，是让产品可以快速迭代，同时还能保持高质量。它的核心措施是，代码集成到主干之前，必须通过自动化测试。只要有一个测试用例失败，就不能集成。

持续集成并不能消除 Bug，而是让它们非常容易的发现和改正。

注：持续集成简单来说，就是频繁的将代码集成到主干。将软件个人研发的部分向软件整体部分交付，频繁进行集成以便更快地发现其中的错误。

好处 ：

• 快速发现错误，每完成一点更新，就集成到主干，可以快速发现错误，定位错误也比较容易
• 防止分支大幅偏离主干，如果不是经常集成，主干又在不断更新，会导致以后集成的难度变大，甚至难以集成
• 更快速的发布更新，持续集成可以帮助团队更快速、更积极的发布程序和更新程序。在发布时可自动完成大量重复的工作、节省人力

2.2 CD：持续部署

CD（CD-continuous deployment，持续部署）是基于某种工具或平台实现代码自动化的构建、测试和部署到线上环境以实现交付高质量的产品,持续部署在某种程度上代表了一个开发团队的更新迭代速率。

持续部署是持续交付的下一步，指的是代码通过评审以后，自动部署到生产环境。

持续部署的目标是，代码在任何时刻都是可部署的，可以进入生产阶段。

注：持续部署的前提是能自动化完成测试、构建、部署等步骤。

2.3 持续交付（Continuous Delivery） 

持续交付是在持续部署的基础之上，将产品交付到线上环境，因此持续交付是产品价值的一种交付，是产品价值的一种盈利的实现。

持续交付指的是频繁地将软件的新版本，交付给质量团队或者用户，以供评审。如果评审通过，代码就进入生产阶段。

持续交付在持续集成的基础上，将集成后的代码部署到更贴近真实运行环境的「类生产环境」(production-like environments)中。持续交付优先于整个产品生命周期的软件部署，建立在高水平自动化持续集成之上。

注：持续交付可以看作持续集成的下一步

三、持续集成(CI) / 持续部署(CD)的优势

1）持续集成/持续交付是现代软件开发周期的基础

2）在传统的软件开发方法中，每个功能更新或修复错误都会每隔一段时间进行发布，这显著增加了在部署时耦合更改的机会

3）持续集成/持续交付可以解决所有这些问题，并使整个过程更易于管理和高效。

4）在现代软件开发实践中，持续集成(CI)/持续交付(CD)是构建、测试应用程序并将其部署到生产中的基础。

5）持续交付(CD)有助于降低风险，并通过自动化来自不同项目开发人员的多个代码更改来实现生产一致性。

6）另一方面，持续交付使开发人员能够无缝地将集成代码交付到生产中，从而提供快速有效的自动化流程，以向客户轻松发布新功能和更新

7）持续集成/持续交付管道的优势：

• 管理较小的代码更改
• 故障隔离可在短期内防止错误
• 缩短平均解决时间（MTTR）
• 提高测试可靠性
• 加快释放速度
• 减少积压
• 推动客户实现
• 加强团队的透明沟通和责任感
• 降低成本
• 易于维护和更新

四、我们熟知的CI/CD工具都有哪些？

4.1GitLab CI

GitLab 是 CI/CD 领域的一个新手玩家，但它已经在 Forrester Wave 持续集成工具中占据了领先地位。在这样一个竞争对手众多而水平又很高的领域，这是一项巨大的成就。是什么让 GitLab CI 如此了不起？

• 它使用 YAML 文件来描述整个管道。
• 它还有一个功能叫 Auto DevOps，使比较简单的项目可以自动构建内置了若干测试的管道。
• 使用 Herokuish 构建包来确定语言以及如何构建应用程序。有些语言还可以管理数据库，对于构建新的应用程序并在开发过程一开始就将其部署到生产环境中，这是一个很重要的功能。
• 提供到 Kubernetes 集群的原生集成，并使用多种部署方法的一种（如基于百分比的部署和蓝绿部署）将应用程序自动部署到 Kubernetes 集群中。

除了 CI 功能之外，GitLab 还提供了许多补充功能，比如自动把 Prometheus 和你的应用程序一起部署，实现运行监控；使用 GitLab 问题（Issues）、史诗（Epics）和里程碑（Milestones）进行项目组合和项目管理；管道内置了安全检查，提供跨多个项目的聚合结果；使用 WebIDE 在 GitLab 中编辑代码的能力，它甚至可以提供预览或执行管道的一部分，以获得更快的反馈。

4.2 Jenkins

enkins 是 CI/CD 领域中一款最早的、久负盛名的工具，是事实上的标准。对于大多数非开发人员来说，Jenkins 可能会是一个不小的负担，并且长期以来也一直是其管理员的负担。然而，这些都是他们想要解决的事项。

Jenkins 配置即代码（JCasC）应该有助于解决困扰管理员多年的复杂配置问题。和其他 CI/CD 系统类似，它允许通过 YAML 文件实现 Jenkins 主节点的零接触配置。Jenkins Evergreen 的目标是通过提供基于不同用例的预定义 Jenkins 配置来简化这个过程。这些发行版应该比标准的 Jenkins 发行版更容易维护和升级。

Jenkins 2 引入了具有两种管道类型的原生管道功能。当你在做一些简单的事情时，这两种方法都不像 YAML 那么容易操作，但是它们非常适合处理更复杂的任务。

Jenkins X 是 Jenkins 的彻底转变，很可能是原生云 Jenkins 的实现（或者至少是大多数用户在使用原生云 Jenkins 时会看到的东西）。它将使用 JCasC 和 Evergreen，并在 Kubernetes 本地以最佳的方式使用它们。对于 Jenkins 来说，这是激动人心的时刻，我期待着它在这个领域的创新和持续的领导地位。

4.3 Jenkins vs GitLab CI/CD 的功能对比

Jenkins 和 GitLab CI/CD 都有它们非常擅长的领域和各自的技术追随者。然而，在讨论 Jenkins vs GitLab CI/CD 之争时，会讨论许多功能。

4.4 Jenkins vs GitLab CI/CD 优缺点  

4.4.1 Jenkins 的优点

• 大量插件库
• 自托管，例如对工作空间的完全控制
• 容易调试运行，由于对工作空间的绝对控制
• 容易搭建节点
• 容易部署代码
• 非常好的凭证管理
• 非常灵活多样的功能
• 支持不同的语言
• 非常直观

4.4.2 Jenkins 的缺点

• 插件集成复杂
• 对于比较小的项目开销比较大，因为你需要自己搭建
• 缺少对整个 pipeline 跟踪的分析

4.4.3 GitLab CI/CD 的优点

• 更好的 Docker 集成
• 运行程序扩展或收缩比较简单
• 阶段内的作业并行执行
• 有向无环图 pipeline 的机会
• 由于并发运行程序而非常易于扩展收缩
• 合并请求集成
• 容易添加作业
• 容易处理冲突问题
• 良好的安全和隐私政策

4.4.4 GitLab CI/CD 的缺点

• 需要为每个作业定义构建并上传 / 下载
• 在实际合并发生之前测试合并状态是不可能的
• 还不支持细分阶段

4.5 Jenkins vs GitLab CI/CD 如何选？

Jenkins 和 GitLab CI/CD 都有它们各自的优点和缺点，你在这两个工具之间的最终选择取决于项目需求和规格。其中每一个 CI/CD 工具都有它自己的优势和劣势，发布时都实现了完全相同的需求：自动化 CI/CD（持续集成和交付）的过程。Jenkins 用于持续集成，而 GitLab CI/CD 用于代码协作和版本控制。在选择最佳的用于 DevOps 测试的 CI/CD 工具时，除了突出的特性，你还应该查看价格列表和内部熟练度。