什么是持续整合？

在过去几年中，很难找到与软件世界相关的术语，而不是与 持续集成 （CI）和 持续交付 或 持续部署 （CD） 密切相关的实践，这些实践 通常被称为CI / CD。 世界各地的组织，从一人开发商店到跨国公司，都在为他们的软件产品实施CI和CD。

在本文中，我们将描述CI，简要提及CD，并了解如何有效地使用它们。 我们将评估空间中可用的一些流行工具和系统，使您能够快速启动并运行开发工作流程。

持续集成：自动化开发流程和最佳实践

为了说明持续集成在现代环境中的适用范围，让我们简要介绍一下典型的软件开发工作流程。 大多数现代软件项目，无论是网站，智能手机应用程序还是桌面应用程序，通常都遵循以下高级过程：

1. 开发人员编写一些代码，通常称为 变更集 或 补丁 ，代表对项目代码库的更改（例如，添加新功能或修复错误）。

2. 他们 将 更改 集成 （或 合并 ）到该项目的集中权威代码存储库（例如，GitHub上的存储库）。

3. 如果与编程语言或应用程序相关，则 编译 项目源代码 ，然后将其 构建 为可部署版本（通常称为 工件 或 包 ）。

上面的步骤是许多现实设置的简化视图，省略了分支策略等考虑因素。 在考虑这个过程并思考每个阶段的责任时，会出现两个关键问题：

1. 我们怎么知道开发人员的变更集（来自第1步）是否可以集成到项目中？

• 更改不得破坏现有代码库， 例如 它们不会引入新的错误

• 变化需要 具有足够好的 质量。 “足够好”的确切级别取决于上下文：负责人类生活的应用程序（如医疗应用程序）与游戏没有相同的期望。

谁（或什么）负责执行步骤2-3？

在非CI开发模型中，第一个问题的答案可能包括 “点击合并和希望最好” 到 “希望开发人员运行测试” 。

同时，问题2倾向于由开发人员或操作手动完成，或者可能通过脚本部分自动完成。

持续集成采用不同的方法。 它试图自动化这两个问题的答案。

看看上面的高级工作流程，持续集成侧重于第2步和第3步。它验证了开发人员的更改是否可以集成到主代码库中，并且团队仍然可以成功构建项目并运行相关的测试。

在理想的CI环境中，每个代码更改都会在开发时进行集成。 一般来说，建议每次集成几次，甚至更好。

什么是持续交付和持续部署？

持续交付和持续部署使自动化更进一步，直到您的最新提交自动分发整个新版本的软件。

持续交付 意味着构建工件并准备好部署。 但如果没有人类的人工决定，它们就不会被部署。

持续部署 意味着所有流程都是自动化的，并且单个提交会触发自动化管道，最终将您的应用程序的新版本带到生产环境，而无需任何人为干预。

虽然许多公司实行持续交付，但很少有公司接受持续部署。 持续部署存在风险，因为任何人都可以通过简单的提交将错误引入生产，并且您需要引入流程来降低此风险。

持续集成的好处

这种对自动化集成的强调提供了超越传统开发工作流程的另一个重要优势

利用现代版本控制大多数软件项目使用 主干 分支（也称为 干线 或 主 ）。

在非CI环境中，开发人员通常会在 此主干的 分支 上长时间处理功能 。 随着时间的推移，随着其他开发人员整合他们的变化，这些分支往往越来越偏离主线。

集成功能分支可能是一个费力的过程，以确保所有更改仍然兼容。 这是一个开发人员非常害怕的过程，他们创造了“整合地狱”这个短语。 CI工作流程可以帮助您避免这个问题，因为它们强调简单和定期的集成。

持续集成不仅可以节省开发人员的时间，还可以避免他们不得不手动集成更改，而且还可以提高软件的可靠性。 团队可以放心地添加新功能，并通过编写代码（和相关测试）自动将其发布给用户。

持续集成实践的要求

持续集成工作流程有一些硬性要求。

1. 版本控制系统工具

2. 构建工具

3. Artifacts Repository Manager

持续集成依赖于版本控制系统

最重要的要求是代码库必须受版本控制。 应用于代码库的每个更改都必须安全地存储在专用版本控制系统（VCS）中。 代码受版本控制后，CI工具可以访问它。

市场上有几种工具，Git可能是目前最广泛使用的CVS工具，因此值得简短描述。

最初由Linus Torvalds创建的用于开发Linux内核的Git基于3个主要原则：

1. 以并发版本系统（CVS）为例，说明不该做什么

2. 支持分布式工作流程

3. 包括非常强大的防止腐败的保护措施，无论是偶然的还是恶意的

主要的Git特征包括：

• 支持非线性开发：与CVS相比，分支（和合并）非常快。 虽然CVS分支是在服务器端进行的，但Git上的分支是在开发人员机器上进行的。

• 分布式开发：每个开发人员都拥有整个存储库历史记录的本地副本。

• 高效处理大型项目：性能测试表明即使处理大型代码库，Git也很快。

• 用户身份验证：提交可以加密签名，确保提交的作者是其声称的人。

• 历史记录的加密认证：与区块链一样，特定提交的ID取决于其祖先的内容。 更改历史记录将更改提交ID。

• 垃圾收集：不必要的对象将在某些时候自动进行垃圾收集。 当需要空间时，也可以显式调用垃圾收集来打包Git存储库。

实现持续集成的构建工具

CI的第二个要求是构建工具：这样的工具将处理应用程序的源，并将以自动方式生成所需的软件。

一个软件的构建步骤以及构建工具取决于所选择的技术堆栈。 作为说明，这里是Java应用程序的构建步骤列表：

1. 如有必要， .java 从配置 生成 文件

2. 将源代码（ .java 文件） 编译 为字节码（ .class 文件）

3. 将测试代码编译为字节码

4. 执行单元测试

5. 如果有，执行集成测试

6. 将 .class 文件 打包 到JAR存档中

7. 如有必要，将JAR存储在Artifact Repository Manager中（见下文）

8. 如有必要，请在控制版本系统中相应地标记代码

要实现我们示例的操作链，可以使用几种构建工具， 例如 ：

• Ant，所有Java构建工具的基于XML的跨平台祖先

• Maven，一种基于XML的广泛声明，偏向于约定优于配置

构建工具和过程，无论它们是什么，都允许可重现的构建。

可重现构建的思想意味着同一组源代码应该产生一组相同的输出构件。 在开发人员的笔记本电脑或CI系统上构建的代码库应该会产生相同的结果。 这提供了几个好处：

• 首先，当某人的笔记本电脑上的代码最终出现在数据中心的服务器上时，开发人员环境与生产中运行的内容之间的奇偶校验可以减少意外问题。 或者用你可能听过或说过的流行短语，“它可以在我的机器上运行！”。

• 同样，如果CI系统中的测试通过，它可以最大限度地减少生产中断的可能性，因为您可以确信它们运行相同的代码。

• 最后，如果它们可以以一致且可重现的方式构建，则它允许在各阶段之间有效地缓存工件和共享二进制文件。

用于存储持续集成过程结果的工件存储库管理器

正如源代码需要存储在VCS中一样，构建过程产生的工件也需要存储。 此类工件可以存储在远程文件系统中，但与VCS一样，管理工件的专用软件提供了更多附加值：这是 二进制存储库管理器 的角色 ，或者在限制较少的定义中，是 工件存储库管理器 。

维基百科提供以下定义：

二进制存储库管理器是一种软件工具，旨在优化软件开发中使用和生成的二进制文件的下载和存储。 它集中管理组织生成和使用的所有二进制工件，以克服二进制工件类型的多样性，它们在整个工作流中的位置以及它们之间的依赖性所带来的复杂性。

工件存储库管理器提供以下主要功能：

• 缓存 ：因为存储库管理器安装在公司的边界内，所以开发人员访问它的速度比远程访问者快。 通过将其用作代理，它可以缓存下载的第三方工件并加快对它们的访问。

• 保留策略 ：repo管理器可以自动清除未使用的工件，并回收宝贵的空间。

• 高可用性 ：可以在集群中设置repo管理器，以便开发人员以及CI工具可以随时访问它。 回购经理的停机时间肯定会影响所有企业版本的平稳运行。

• 用户限制 ：最后但并非最不重要的是，repo管理器可以根据用户限制对特定工件或其组的访问权限。

一个简单的CI工作流程，从开发到真实构建

CI工作流程与开发最佳实践密切相关。 根据您的软件，堆栈和用例，可能存在大量可能的CI工作流程。 让我们看一个简化的工作流程作为一个例子，从开发到真正的构建自动化。

分枝

获取代码库的最新副本。 这里有两种可能性：如果它是第一次被访问，则需要“下载”它。 使用Git，这是通过 git clone 命令 实现的，该 命令将在本地复制远程代码库。

或者，如果代码库已经存在于本地，则只需要与远程存储库同步，您可以执行此操作， 例如 ：使用该 git pull 命令。

在版本控制系统中，有一个专用分支指向软件的最新稳定版本（通常 master ），这应该是应该发布到生产中的。

为了保护这个黄金标准免受尽可能多的错误，不应该直接在其上写任何东西。 因此，每个开发都应该从master创建一个专用分支开始。

为了保持组织的事情，有可能采用的命名方案为分支：流行的采用前缀一样 develop ， feature ， release ， hotfix ，等。

测试

现在可以开始正确的开发，无论是跨越一个或多个冲刺的全面功能开发还是快速生产错误修复。

根据一个人的上下文，可以在之前（这是：测试驱动设计）或编写代码之后编写测试。 但是，在之前或之后，需要编写测试，以确保代码正常工作，测试工具将捕获可能的未来回归。

测试代码的覆盖范围也取决于一个人的背景：对于负责人类生命的软件，例如平面导航或辅助手术，需要检查每行代码（甚至是双重或三重检查）。 在其他情况下，测试的投资回报可能不那么重要。

拉请求

请记住，更改不是直接在master上进行的，而是在专用分支上进行的。 开发完成后，是时候向团队成员询问这些更改是否可以合并到主分支中。

这是 拉取请求 的目标 ：您基本上要求您的团队接受黄金标准的更改并打开您的 补丁 以进行同行评审。

一旦 PR 已经打开，分支可以自动使用项目的构建工具，以确保我们的修改不会破坏我们的主分支的修改建。

质量保证

通常，还会发生其他步骤。 其中一个步骤是对已提交代码的自动审核：审核范围可能与安全性，代码质量，文档标准等有关。

在代码质量领域，很难不提及 SonarQube ，这是该领域领先的OpenSource平台之一。 SonarQube与主要CI工具集成，可在一个代码库上执行已配置的检查。 这就是持续检查的全部内容：

SonarQube不仅能够显示应用程序的运行状况，还能够突出显示新引入的问题。 通过质量门，您可以修复泄漏，从而系统地提高代码质量。

建设

一旦PR打开，自动构建就会自动启动，使用一个可用的CI工具，这些工具将完成所有构建步骤：编译，测试，打包等。如果一个（或多个）自动构建步骤触发了故障，我们说构建破了。

在大多数CI工具中，损坏的构建以红色显示，而传递的构建以绿色显示。 因此，您可能会听到人们将传递构建称为“绿色构建”。 如果构建被破坏，无论出于何种原因，由PR的起源处的开发人员来解决它。 在这个阶段，构建应该通过。

代码审查

自动化是伟大的，没有它，开发人员将无法达到他们今天所做的。 然而，它并非没有限制。

虽然诸如SonarQube一个工具可以检测一个简单的错误模式（ 如 在 双重检查锁定模式 ），它不能检测出无限多种可能的错误，只有另一个人的心灵可以这样做。

出于这个原因，代码更改之前的最后一步可以合并到master中，是由其他团队成员进行的手动代码审查（这是 PR的 用途！）。

可能有很多方法可以进行代码审查，因为有开发人员！ 我只想说你可能需要找到一个基础的，例如 在Code Review中寻找 的优秀内容 ， 并根据自己的需要进行调整。

标记，版本控制和存储构建的工件

在这个阶段，变化可以（最终）合并到主人。

通常，这表示发布或生产热修复。 为了确保一切正常，CI工具应该再次重放构建，这次在主分支上进行合并更改。
但是，还有其他操作。

首先，VCS需要相应地标记版本，以便将其标记为这样。
命名为标记和版本也存在，为分支，但经常与一个更有创意的扭曲约定：经常项目选择喜欢的主题 如 山名，湖名或 蛋糕的名字 ，仅举几例Exoscale内部使用。

但是，虽然“Placid Pangolin”（Ubuntu）或“Oreo”（Android）是值得记住的伟大营销名称，但软件开发人员应该并行使用标准版本控制方案（使用数字）。 建议遵循关于major，minor和bugfix版本的语义版本规则。 更多信息可以在 semver.org 上 找到 。

其次，构建结果工件需要存储在Artifacts Repository Manager中。 这样，如果发生意外情况并且需要执行回滚，则可以使用以前的工作版本，而无需再次从源构建。

持续集成工具：概述

随着持续集成的使用越来越广泛，有一个成熟的工具生态系统可以开始使用。 下面我们来看一下目前使用的一些最流行和最常见的CI / CD系统，从完全在云中运行的初创企业到在内部运行自己的复杂CI平台的大型企业组织。

詹金斯

Jenkins 是持续集成领域最古老的开源项目之一，仍然是最广泛使用的项目之一。

这么长的遗产有上升空间和缺点。 多年来，核心架构已经在从小规模部署到 世界上 一些 最大公司的 生产环境中经过了长时间的测试 ，并且有一个充满活力的Jenkins用户在线社区，可以帮助您解决可能遇到的问题。

但是，大型遗留代码库和向后兼容性要求意味着它的内部抽象通常过时 - 而且这些常常会泄漏给不同场景下的用户。

此外，虽然Jenkins拥有广泛的插件生态系统，可提供许多现代功能，但这些插件通常是社区开发的，可以在质量和可靠性方面有所不同。

近年来，Jenkins获得了一种新语言，用于描述称为 管道的 持续集成工作流程 。 这些允许开发人员声明和描述构建和部署过程。 Jenkins还允许您创建可以在不同项目中重用的模块，以标准化和简化常见流程。

简而言之，Jenkins拥有悠久的开发和使用历史，一个庞大而活跃的社区，并且具有高度可定制性。 也许出于这些原因，你可以说，“没有人因为选择詹金斯而被解雇。”

特拉维斯CI

Travis CI 几乎和Jenkins一样令人尊敬，虽然它的许多组件都是开源的，但如果没有企业帐户，就不可能自行托管。 但是，使用任何开源项目运行Travis都是免费的。

您希望Travis运行的每个任务都包含在 代码旁边 的 .travis.yml 文件中，这也意味着您可以从存储库的不同分支运行不同的任务。

Travis旨在简化，直接从GitHub托管的存储库工作，并维护许多应用程序中常见的服务库。 但是，如果您不使用GitHub或需要更多控制，那么其他选项可能更适合您。

Travis的一个有用功能是能够在多个操作系统上运行，这意味着您可以在不同目标上测试代码，而无需维护机器或虚拟映像。

GitLab持续集成/持续交付

GitLab最初是一个源代码托管服务，类似于GitHub，但也有开源版本。 与GitHub不同，GitLab现在包含一个 内置于其平台 的高级CI / CD实现（称为 AutoDevOps ）。

对于那些已经使用GitLab存储源代码的人来说，这种紧密集成是GitLab CI / CD产品最有用的方面之一。 您可以通过将.gitlab-ci.yml配置文件添加到源代码存储库的根目录来启用它。

您可以将GitLab CI / CD与GitHub存储库集成。

竹

Bamboo是Atlassian的持续集成/持续交付产品，Atlassian是一家在大多数软件环境中为其JIRA错误跟踪软件而闻名的公司。

Bamboo的主要优势之一是它与已经运行这些系统的其他Atlassian产品（如JIRA和Bitbucket）紧密集成。 它还有一个大型附加组件市场。

在缺点方面，Bamboo拥有较小的用户社区，因此用户可能更依赖于Atlassian的支持。

CircleCI

CircleCI是一种现代在线服务（也可作为托管版本提供），旨在提供强大的CI平台。 CircleCI将其平台集中在容器周围，并为测试提供快速启动时间。 工作流功能允许用户定义CI和CD作业的序列，即使对于最复杂的项目也是如此。

CircleCI的主要优势在于它是一个完全托管的CI解决方案，可以减少最终用户投入系统维护的时间。

结论

尽管持续集成最佳实践和工具对于实现正确性非常重要，但它们往往不足以使组织走上CI路径。 对于许多传统软件组织而言，从传统的手动步骤切换到CI流程需要对软件团队协同工作的方式进行深刻的改变。

为了能够成功地将变更集集成到代码库中，团队必须就工作模式和规范集合达成一致并坚持下去。 实现可靠的构建步骤有时需要进行严格的重构，并且不断地部署到生产中会打开团队需要围绕和处理的问题的全新视野。

但是，当一起考虑时，采用持续集成实践为软件组织带来的好处是不可否认的。 现在，这已成为软件世界的一个新常态，CI实践的采用增长只会在未来加速。

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/31557424/viewspace-2220399/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/31557424/viewspace-2220399/