什么是ci/cd

在谈论生产软件时，连续集成（CI）和连续交付（CD）是非常普遍的术语。 但是，它们的真正含义是什么？ 在本文中，我将解释这些术语和相关术语（例如连续测试和连续部署）背后的含义和意义。

快速总结

工厂中的装配线以快速，自动化，可复制的方式从原材料生产消费品。 类似地，软件交付管道以快速，自动化和可复制的方式从源代码中产生发布。 完成此操作的总体设计称为“连续交付”。 开始组装线的过程称为“连续集成”。 确保质量的过程称为“连续测试”，使最终产品可供用户使用的过程称为“连续部署”。 使一切顺利运行并简单地为每个人运行的整体效率专家被称为“ DevOps”实践者。

“连续”是什么意思？

连续用于描述遵循我在此描述的实践的许多不同过程。 这并不意味着“一直在运行”。 它确实意味着“始终准备运行”。 在创建软件的上下文中，它还包括几个核心概念/最佳实践。 这些是：

• 频繁发布：持续实践的目标是能够频繁地交付高质量的软件。 这里的频率是可变的，可以由团队或公司定义。 对于某些产品，每季度，每月，每周或每天一次可能足够频繁。 对于其他人，一天可能需要多次并且可行。 连续性也可以具有“偶尔的，按需”的方面。 最终目标是相同的：以可重复，可靠的过程向最终用户提供高质量的软件更新。 通常，只需很少甚至没有交互，甚至不需要用户的了解即可完成此操作（请考虑设备更新）。

• 自动化流程：启用此频率的关键部分是拥有自动化流程来处理软件生产的几乎所有方面。 这包括构建，测试，分析，版本控制，在某些情况下还包括部署。

• 可重复的：如果我们使用的自动化过程在给定相同的输入的情况下始终具有相同的行为，那么处理应该是可重复的。 也就是说，如果我们返回并输入与输入相同的代码版本，则应该获得相同的可交付成果集。 这也假定我们具有相同版本的外部依赖关系（即，我们没有创建的其他可交付成果不是我们的代码使用的）。 理想情况下，这还意味着可以对管道中的流程进行版本控制和重新创建（请参阅稍后的DevOps讨论）。

• 快速处理： “快速”是一个相对术语，但是无论软件更新/发布的频率如何，都希望连续的过程以有效的方式处理从源代码到交付内容的更改。 自动化可以解决很多问题，但是自动化过程可能仍然很慢。 例如，对于一天要花费多次时间进行新候选发布的产品更新，跨一天大部分时间进行的产品各个方面的集成测试可能太慢。

什么是“连续交付管道”？

连续交付管道如何工作？

软件交付管道的实际实现可以有很大的不同。 在管道中可以使用大量各种各样的应用程序来进行源跟踪，构建，测试，收集指标，管理版本等各个方面。但是总体工作流程通常是相同的。 单个业务流程/工作流应用程序管理整个管道，并且每个流程都作为单独的作业运行或由该应用程序进行阶段管理。 通常，以业务流程应用程序可以理解并可以作为工作流进行管理的语法和结构来定义各个“作业”。

创建作业是为了执行一项或多项功能（构建，测试，部署等）。 每个作业可以使用不同的技术或多种技术。 关键是作业是自动化，高效和可重复的。 如果作业成功，则工作流管理器应用程序将触发管道中的下一个作业。 如果工作失败，工作流管理器会警告开发人员，测试人员和其他人员，以便他们尽快解决问题。 由于具有自动化功能，因此与运行一组手动流程相比，可以更快地发现错误。 这种对错误的快速识别称为“快速失败”，对于到达管道的端点也同样重要。

“快速失败”是什么意思？

管道的一项工作是快速处理变更。 另一个是监视创建发行版的不同任务/作业。 由于未编译或未通过测试的代码会阻碍管道运行，因此，必须将这种情况Swift通知给用户，这一点很重要。 快速失败是指管道处理尽快发现问题并Swift通知用户的想法，以便可以解决问题并重新提交代码以再次通过管道运行。 通常，管道流程可以查看历史记录以确定谁进行了更改并通知人员及其团队。

连续交付管道的所有部分是否都必须自动化？

管道的几乎所有部分都应该是自动化的。 在某些地方，可能需要人工干预/互动的场所。 一个示例可能是用户接受测试（让最终用户试用该软件并确保该软件可以执行他们想要/期望的操作）。 另一种情况可能是部署到生产环境，在该环境中，小组希望获得更多的人为控制。 而且，当然，如果代码不正确且会中断，则需要人工干预。

在了解连续含义的背景下，让我们看一下连续处理的不同类型，以及每种含义在软件管道中的含义。

什么是持续集成？

持续集成（CI）是在产品的源代码更改时自动检测，提取，构建和（在大多数情况下）进行单元测试的过程。 CI是启动管道的活动（尽管某些预先验证（通常称为“飞行前检查”）有时会在CI之前加入）。

CI的目标是快速确保开发人员的新更改“良好”并适合在代码库中进一步使用。

持续集成如何工作？

基本思想是让自动化过程“监视”一个或多个源代码存储库以进行更改。 当将更改推送到存储库时，监视过程会检测到更改，拉下副本，构建副本，然后运行任何关联的单元测试。

持续集成如何检测变化？

如今，监视进程通常是像Jenkins这样的应用程序，它还可以协调管道中运行的所有（或大多数）进程，并监视其更改是其功能之一。 监视应用程序可以几种不同方式监视更改。 这些包括：

• 轮询：监视程序反复询问源管理系统，“您对我感兴趣的存储库中是否有任何新内容？” 当源管理系统发生新更改时，监视程序将“唤醒”并执行其工作以提取新代码并构建/测试它。

• 定期：监视程序配置为定期启动构建，无论是否进行更改。 理想情况下，如果没有更改，则不会构建任何新内容，因此不会增加太多额外成本。

• 推送：这是监视应用程序与源管理系统进行检查的相反过程。 在这种情况下，源管理系统被配置为在将更改提交到存储库时“向监视应用程序推送”通知。 最常见的是，这可以通过“ webhook”的形式完成-一种程序，当推送新代码并将其通过Internet发送通知给监视程序时，该程序“被钩住”运行。 为此，监视程序必须具有开放端口，该开放端口可以通过Internet接收Webhook信息。

什么是“预检查”（又名飞行前检查）？

在将代码引入源存储库并触发持续集成之前，可能需要进行其他验证。 这些遵循最佳实践，例如测试版本和代码审查。 通常在将代码引入管道之前将它们内置到开发过程中。 但是某些管道也可能将它们作为其受监视的流程或工作流的一部分。

例如，一个名为Gerrit的工具允许在开发人员推送代码之后但在将代码允许进入（ Git远程）存储库之前，进行正式的代码审查，验证和测试构建。 Gerrit位于开发人员的工作区和Git远程存储库之间。 它“捕获”开发人员的推送，并且可以进行通过/失败验证，以确保在通过验证之前可以通过验证。 这可以包括检测建议的更改并启动测试构建（CI的一种形式）。 它还允许团体在那时进行正式的代码审查。 通过这种方式，可以更有把握地确信更改在合并到代码库中时不会破坏任何内容。

什么是“单元测试”？

单元测试（也称为“提交测试”）是开发人员编写的小型，集中测试，以确保新代码可以独立工作。 这里的“隔离”是指不依赖于或调用不直接访问的其他代码，也不依赖于外部数据源或其他模块。 如果要使代码运行需要这种依赖关系，则可以通过嘲笑来表示这些资源。 嘲笑指的是使用看起来像资源的代码存根，可以返回值，但不实现任何功能。

在大多数组织中，开发人员负责创建单元测试以证明其代码有效。 实际上，一个模型（称为测试驱动开发[TDD]）要求首先设计单元测试，以作为清晰识别代码应做什么的基础。 由于此类代码更改可能很快且数量众多，因此它们也必须快速执行。

由于它们与持续集成工作流程有关，因此开发人员会在其本地工作环境中创建或更新源，并使用单元测试来确保新开发的功能或方法能够正常工作。 通常，这些测试采用断言的形式，即函数或方法的一组给定输入会产生一组给定的输出。 他们通常进行测试以确保正确标记和处理错误情况。 各种单元测试框架，例如用于Java开发的JUnit ，都可以提供帮助。

什么是连续测试？

连续测试是指随着代码通过CD管道而运行范围扩大的自动化测试的实践。 单元测试通常作为CI阶段的一部分与构建过程集成在一起，并专注于测试代码，使其与与其交互的其他代码隔离。

除此之外，还可以/应该进行各种形式的测试。 这些可以包括：

• 集成测试可验证组件和服务组是否可以协同工作。

• 功能测试可以按预期验证产品中执行功能的结果。

• 验收测试根据可接受的标准测量系统的某些特征。 示例包括性能，可伸缩性，压力和容量。

所有这些可能都不存在于自动化管道中，并且某些不同类型之间的线可能会模糊。 但是，在交付管道中进行连续测试的目标始终是相同的：通过连续的测试级别来证明该代码具有可以在正在进行的发行中使用的质量。 第二个目标是基于快速的持续原则，Swift发现问题并警告开发团队。 这通常称为快速失败 。

除了测试之外，还可以针对管道中的代码进行其他哪些类型的验证？

除了测试的通过/失败之外，还存在一些应用程序，这些应用程序还可以告诉我们测试用例执行（覆盖）的源代码行的数量。 这是可以跨源代码计算的指标的示例。 此度量标准称为代码覆盖率 ，可以通过工具（例如JaCoCo for Java源代码）进行度量。

存在许多其他类型的度量标准，例如对代码行进行计数，测量复杂度以及将编码结构与已知模式进行比较。 SonarQube之类的工具可以检查源代码并计算这些指标。 除此之外，用户可以为他们愿意接受这些度量的“通过”范围设置一个阈值。 然后，可以设置管道中的处理以对照阈值检查计算的值，如果这些值不在可接受的范围内，则可以停止处理。 SonarQube之类的应用程序是高度可配置的，可以进行调整以仅检查团队感兴趣的内容。

什么是连续交付？

连续交付（CD）通常是指整个过程链（管道），它们自动获取源代码更改，并通过构建，测试，打包和相关操作运行它们，以生成可部署的发行版，而基本上无需任何人工干预。

CD制作软件版本的目标是自动化，效率，可靠性，可再现性和质量验证（通过连续测试）。

CD包含CI（自动检测源代码更改，执行更改的构建过程以及运行单元测试以进行验证），连续测试（对代码运行各种测试以获得对代码质量的连续置信度）， （可选）连续部署（使管道中的版本自动提供给用户）。

如何在管道中识别/跟踪多个版本？

版本控制是使用CD和管道的关键概念。 连续意味着具有频繁集成新代码并使更新版本可用的能力。 但这并不意味着每个人都总是希望“最新，最伟大”。 对于想要开发或测试已知的稳定版本的内部团队而言，尤其如此。 因此，重要的是管道创建的管道版本对象可以轻松存储和访问这些版本对象。

从源代码在管道处理中创建的对象通常可以称为工件 。 构建工件时，应将其应用到版本。 为工件分配版本号的推荐策略称为语义版本控制。 （这也适用于从外部来源引入的相关工件的版本。）

语义版本号包含三个部分：主要，次要和补丁。 （例如，1.4.3反映了主要版本1，次要版本4和修补程序版本3。）该想法是这些部分之一的更改表示工件中的更新级别。 主版本仅针对不兼容的API更改才增加。 当以向后兼容的方式添加功能时，次版本会增加。 进行向后兼容的错误修复后，补丁版本也会增加。 这些是推荐的准则，但是团队可以自由地采用这种方法，只要他们在整个组织中以一致且易于理解的方式这样做即可。 例如，每次为发行版完成构建时，都会将数字增加到补丁字段中。

如何“提升”人工制品？

团队可以为工件分配提升“级别”，以指示其适合测试，生产等。有多种方法。 可以启用Jenkins或Artifactory之类的应用程序进行促销。 或简单的方案可以是在版本字符串的末尾添加标签。 例如， -snapshot可以指示用于构建工件的代码的最新版本（快照）。 各种促销策略或工具可以用来“促进”神器其他级别如-milestone或-production作为神器的稳定性的指示，并准备发布。

如何存储和访问工件的多个版本？

可以通过管理“工件存储库”的应用程序存储从源构建的版本控制的工件。 工件存储库就像构建的工件的源管理一样。 该应用程序（例如Artifactory或Nexus ）可以接受版本化的工件，对其进行存储和跟踪，并提供对其进行检索的方法。

管道用户可以指定他们要使用的版本，并在这些版本中引入管道。

什么是持续部署？

连续部署（CD）是指能够自动获取CD管道中发布的代码并将其提供给最终用户的想法。 根据用户“安装”代码的方式，这可能意味着自动在云中部署某些内容，使更新可用（例如针对手机上的应用程序），更新网站或仅更新可用版本列表。

这里重要的一点是，仅仅因为可以进行连续部署并不意味着总会部署管道中的每组交付品。 这确实意味着，通过管道，每套可交付成果都被证明是“可部署的”。 这在很大程度上是通过连续测试的连续级别实现的（请参见本文中有关连续测试的部分）。

能否部署来自管道运行的发行版可能会受到人为决定和在完全部署发行版之前“试用”发行版的各种方法的控制。

有什么方法可以在完全部署到所有用户之前测试部署？

由于必须回滚/撤消对所有用户的部署可能是一个代价高昂的情况（无论从技术上还是从用户的角度而言），因此已经开发了多种技术来允许“试用”新功能的部署，并在出现问题时轻松地“撤消”它们。被发现。 这些包括：

蓝色/绿色测试/部署

在这种部署软件的方法中，维护了两个相同的托管环境-一个蓝色的和一个绿色的 。 （颜色并不重要，仅用作标识。）在任何给定的点上，其中一个是生产部署，另一个是候选部署。

在这些实例的前面是路由器或其他系统，它们充当客户访问产品或应用程序的“门户”。 通过将路由器指向所需的蓝色或绿色实例，可以将客户流量定向到所需的部署。 通过这种方式，换出指向哪个部署实例（蓝色或绿色）的操作对用户来说是快速，轻松和透明的。

当一个新版本准备好进行测试时，可以将其部署到非生产环境中。 经过测试和批准后，可以更改路由器以将传入的生产流量指向该路由器（这样它将成为新的生产站点）。 现在，可供下一个候选人使用的是生产环境的托管环境。

同样，如果发现最新部署存在问题，并且先前的生产实例仍在其他环境中部署，则简单的更改就可以将客户流量引回到先前的生产实例，从而有效地将实例与“脱机”问题相提并论。回滚到以前的版本。 然后可以将有问题的新部署固定在其他区域。

金丝雀测试/部署

在某些情况下，通过蓝/绿环境换出整个部署可能不可行或不希望。 另一种方法称为金丝雀测试/部署。 在此模型中，一部分客户流量被重新路由到新产品。 例如，可以将产品中搜索服务的新版本与该服务的当前生产版本一起部署。 然后，可以将10％的搜索查询路由到新版本以在生产环境中对其进行测试。

如果新服务可以毫无问题地处理有限的流量，则随着时间的流逝，更多的流量可能会路由到该服务。 如果没有问题，那么随着时间的流逝，可以增加路由到新服务的流量，直到有100％的流量流向新服务。 这有效地“淘汰”了该服务的先前版本，并使新版本对所有客户生效。

功能切换

对于可能需要轻松撤消的新功能（如果发现问题），开发人员可以添加功能切换 。 这是软件中的if-then软件，然后在代码中切换，仅在设置了数据值后才激活代码。 此数据值可以是可全局访问的位置，部署的应用程序将检查该数据位置以查看是否应执行新代码。 如果设置了数据值，则执行代码；否则，执行代码。 如果没有，那不是。

如果在部署到生产环境后发现问题，这将为开发人员提供远程“杀死开关”以关闭新功能。

黑暗发射

在这种实践中，将对代码进行增量测试/部署到生产中，但是更改对用户不可见（因此为“深色”名称）。 例如，在生产版本中，Web查询的某些部分可能会重定向到查询新数据源的服务。 开发人员可以收集这些信息以进行分析，而无需将有关接口，事务或结果的任何信息透露给用户。

这里的想法是获得有关在生产负载下如何进行候选更改而不影响用户或改变其体验的真实信息。 随着时间的流逝，可以将更多的负载重定向，直到发现问题或认为新功能可供所有人使用为止。 功能标记实际上可以用来处理黑暗发射的机制。

什么是DevOps？

DevOps是关于如何使开发和运营团队更轻松地共同开发和发布软件的一套想法和建议的实践。 从历史上看，开发团队创建产品，但没有像客户那样以常规，可重复的方式安装/部署产品。 该组安装/部署任务（以及其他支持任务）留给运营团队在周期的后期进行整理。 这通常会导致很多混乱和问题，因为运营团队在周期的后期被带入了循环，并且不得不在短时间内完成他们的工作。 同样，开发团队经常处于劣势–因为他们没有充分测试产品的安装/部署功能，所以他们可能会对在此过程中出现的问题感到惊讶。

这通常导致严重的脱节，并且开发和运营团队之间缺乏合作。 DevOps理想提倡从开发周期的开始到结束都涉及开发和运营人员的工作方式，例如CD。

CD如何与DevOps相交？

CD管道是几种DevOps理想的实现。 产品的后期阶段（例如打包和部署）始终可以在管道的每次运行中完成，而不必等待产品开发周期中的特定点。 同样，开发人员和运营人员都可以清楚地看到从开发到部署，什么时候起作用，什么时候不起作用。 为了使CD流水线的一个周期成功，它不仅必须经过与开发相关的过程，而且还必须经过与操作相关的过程。

进行到下一个级别，DevOps建议甚至将实现管道的基础结构都视为代码。 就是说，它应该是自动配置的，可跟踪的，易于更改的，并在更改时产生新的管道运行。 这可以通过将管道实现为代码来完成。

什么是“代码流水线”？

正如开发人员使用产品的源代码一样，流水即代码是用于通过编程代码创建流水作业/任务的通用术语。 目标是将流水线实现表示为代码，以便可以将其与代码一起存储，进行检查，随时间推移进行跟踪，并在出现问题并且必须停止流水线时轻松地再次启动。 包括Jenkins 2在内的几种工具都可以做到这一点。

DevOps对生产软件的基础架构有何影响？

传统上，流水线中使用的单个硬件系统是一次配置一个软件（操作系统，应用程序，开发工具等）的。 在极端情况下，每个系统都是一个定制的手工设置。 这意味着，当系统出现问题或需要更新时，这通常也是自定义任务。 这种方法违背了具有轻松可复制和可跟踪环境的基本CD理想。

多年来，已经开发了一些应用程序来标准化供应（安装和配置）系统。 同样，虚拟机也被开发为模拟在其他计算机之上运行的计算机的程序。 这些VM需要管理程序才能在基础主机系统上运行它们。 而且它们需要自己的操作系统副本才能运行。

接下来是容器。 容器在概念上与虚拟机相似，但工作方式不同。 他们不需要运行单独的程序和操作系统的副本，而只是使用一些现有的OS结构来挖掘操作系统中的孤立空间。 因此，它们的行为类似于VM以提供隔离，但不需要开销。

由于VM和容器是根据存储的定义创建的，因此可以轻松销毁它们并重新创建它们，而不会影响运行它们的主机系统。 这允许可重新创建的系统在其上运行管道。 同样，对于容器，我们可以跟踪对它们所基于的定义文件的更改，就像对源代码一样。

因此，如果我们在VM或容器中遇到问题，则销毁并重新创建它而不是尝试调试并修复现有问题可能更容易，更快捷。

这也意味着对管道代码的任何更改都可以触发管道的新运行（通过CI），就像对代码所做的更改一样。 这是DevOps关于基础架构的核心理想之一。

翻译自: https://opensource.com/article/18/8/what-cicd

什么是ci/cd