持续集成 (CI) 教程

注意

持续集成对不同的用户和组织具有不同的含义。在本教程中，我们将涵盖用户对其包的源代码进行更改时，自动构建这些包的新二进制文件，并计算这些新包的更改是否能干净地集成或破坏组织的主要产品的情况。

在本教程中，我们将使用这个小型项目，该项目使用几个包（默认情况下是静态库）来构建几个应用程序，一个视频游戏和一个地图查看器实用程序。 game 和 mapviewer 是我们的最终“产品”，是我们分发给用户的。

digraph game { node [fillcolor="lightskyblue", style=filled, shape=box] rankdir="BT" "game/1.0" -> "engine/1.0" -> "ai/1.0" -> "mathlib/1.0"; "engine/1.0" -> "graphics/1.0" -> "mathlib/1.0"; "mapviewer/1.0" -> "graphics/1.0"; "game/1.0" [fillcolor="lightgreen"]; "mapviewer/1.0" [fillcolor="lightgreen"]; { rank = same; edge[ style=invis]; "game/1.0" -> "mapviewer/1.0" ; rankdir = LR; } }

依赖图中的所有包都对其直接依赖项使用版本范围进行 requires，例如，game 包含一个 requires("engine/[>=1.0 <2]")，因此依赖项的新补丁版本和次要版本将自动使用，无需修改配方。

注意

重要提示

  • 本节编写为实践教程。 旨在通过在您的机器上复制命令来重现。

  • 本教程介绍了一些工具、良好实践和 CI 问题的常见方法。 但没有万能的解决方案。 本教程不是应该完成事情的唯一方法。 不同的组织可能具有不同的需求和优先级、不同的构建服务能力和预算、不同的规模等。 教程中介绍的原则和实践可能需要进行调整。

  • 如果您有任何问题或反馈，请在 https://github.com/conan-io/conan/issues 上提交新 issue

  • 但是，一些原则和最佳实践对于所有方法都是通用的。 例如，包的不可变性、在仓库之间使用推广以及不将 channel 用于此目的都是应遵循的良好实践。

包和产品流水线

当开发人员对其包的源代码进行更改时，我们将考虑整个系统 CI 的两个不同部分或流水线：包流水线和产品流水线

  • 包流水线负责在更改其代码时构建单个包。 如有必要，它将为不同的配置构建它。

  • 产品流水线负责构建组织的主要“产品”（实现最终应用程序或交付物的包），并确保依赖项中的更改和新版本正确集成，并在必要时重建图中的任何中间包。

设想一下，如果某个开发人员对 ai 包进行更改，生成一个新的 ai/1.1.0 版本，包流水线将首先构建这个新版本。 但是，这个新版本可能会意外地破坏或需要重建一些消费包。 如果我们组织的 产品 是 game/1.0 和 mapviewer/1.0，那么可以触发产品流水线，在这种情况下，它将重建 engine/1.0 和 game/1.0，因为它们受到更改的影响。

仓库和推广

多个服务器端仓库的概念对于 CI 非常重要。在本教程中，我们将使用 3 个仓库

  • develop：这个仓库是开发人员配置在他们的机器上的主要仓库，以便能够 conan install 依赖项并工作。 因此，预计它会相当稳定，类似于 git 中的共享“develop”分支，并且仓库应包含组织预定义平台的预编译二进制文件，以便开发人员和 CI 无需执行 --build=missing 并一遍又一遍地从源代码构建。

  • packages：这个仓库将用于临时上传由“包流水线”构建的包，以避免直接上传到 develop 仓库并避免在这些包完全验证之前造成破坏。

  • products：这个仓库将用于临时上传由“产品流水线”构建的包，同时构建和测试新的依赖项更改是否会破坏主要“产品”。

digraph repositories { node [fillcolor="lightskyblue", style=filled, shape=box] rankdir="LR"; subgraph cluster_0 { style=filled; color=lightgrey; rankdir="LR"; label = "Packages server"; "packages\n repository" -> "products\n repository" -> "develop\n repository" [ label="promotion" ]; } }

推广是用于使包从一个流水线可用到另一个流水线的机制。 将上述包和产品流水线与仓库连接起来，将有 2 次推广

  • 当使用 packages pipeline 为单个包构建了不同配置的所有不同二进制文件，并上传到 packages 仓库后，可以认为该包的新版本和更改是“正确的”，并将其推广（复制）到 products 仓库。

  • 当 products pipeline 从源代码构建了由于 products 仓库中的新包版本而需要重建的所有必要包，并检查组织“产品”（例如 game/1.0 和 mapviewer/1.0）未被破坏，那么可以将包从 products 仓库推广（复制）到 develop 仓库，以便所有其他开发人员和 CI 都可以使用它们。

注意

本教程只是模拟了 开发 流。 在生产系统中，将会有其他的仓库和推广，例如 QA 团队的 testing 仓库，以及最终用户的最终 release 仓库，以便在通过验证后，包可以从 develop 推广到 testing 到 release。 有关推广的更多信息，请参阅 包推广。

让我们开始教程，转到下一节进行项目设置