产品流水线：使用锁定文件的分布式完整流水线¶

本节将介绍多产品、多配置分布式 CI 流水线的完整实现。它将涵盖重要的实现细节

使用锁定文件来保证所有配置的一致且固定的依赖项集。
将构建的软件包上传到 products 仓库。
捕获“软件包列表”并使用它们来运行最终的晋升。
如何以编程方式迭代“构建顺序”

让我们像往常一样从清理本地缓存并定义正确的仓库开始

# First clean the local "build" folder
$ pwd  # should be <path>/examples2/ci/game
$ rm -rf build  # clean the temporary build folder
$ mkdir build && cd build # To put temporary files

$ conan remove "*" -c  # Make sure no packages from last run
# NOTE: The products repo is first, it will have higher priority.
$ conan remote enable products

与我们在 packages pipeline 中所做的类似，当我们想要确保在构建不同配置和产品时依赖项完全相同时，第一个必要的步骤是计算一个 conan.lock 锁定文件，我们可以将其传递给不同的 CI 构建代理，以在所有地方强制执行相同的依赖项集。这可以针对不同的 products 和配置逐步完成，并在最终的单个 conan.lock 锁定文件中聚合它。这种方法假设 game/1.0 和 mapviewer/1.0 将使用相同版本和修订的公共依赖项。

$ conan lock create --requires=game/1.0 --lockfile-out=conan.lock
$ conan lock create --requires=game/1.0 -s build_type=Debug --lockfile=conan.lock --lockfile-out=conan.lock
$ conan lock create --requires=mapviewer/1.0 --lockfile=conan.lock --lockfile-out=conan.lock
$ conan lock create --requires=mapviewer/1.0 -s build_type=Debug --lockfile=conan.lock --lockfile-out=conan.lock

注意

请记住，conan.lock 参数大多是可选的，因为那是默认的锁定文件名。第一个命令可以键入为 conan lock create --requires=game/1.0。此外，所有命令，包括 conan install，如果它们找到现有的 conan.lock 文件，它们将自动使用它，而无需显式的 --lockfile=conan.lock。本教程中的命令为了完整性和教学原因而显式完整地显示。

然后，我们可以计算每个产品和配置的构建顺序。这些命令与上一节中的命令相同，唯一的区别是添加了 --lockfile=conan.lock 参数

$ conan graph build-order --requires=game/1.0 --lockfile=conan.lock --build=missing --order-by=recipe --format=json > game_release.json
$ conan graph build-order --requires=game/1.0 --lockfile=conan.lock --build=missing -s build_type=Debug --order-by=recipe --format=json > game_debug.json
$ conan graph build-order --requires=mapviewer/1.0 --lockfile=conan.lock --build=missing --order-by=recipe --format=json > mapviewer_release.json
$ conan graph build-order --requires=mapviewer/1.0 --lockfile=conan.lock --build=missing -s build_type=Debug --order-by=recipe --format=json > mapviewer_debug.json

同样，build-order-merge 命令将与上一个命令相同。在这种情况下，由于此命令实际上不计算依赖关系图，因此不需要 conan.lock 参数，因此不会解析依赖关系

$ conan graph build-order-merge --file=game_release.json --file=game_debug.json --file=mapviewer_release.json --file=mapviewer_debug.json --reduce --format=json > build_order.json

到目前为止，此过程几乎与上一节的过程相同，只是捕获和使用了锁定文件。现在，我们将解释 products 流水线的“核心”：迭代构建顺序并分发构建，以及收集生成的已构建软件包。

以下是一些 Python 代码的示例，这些代码按顺序执行迭代（真正的 CI 系统会将构建并行分发到不同的代理）

build_order = open("build_order.json", "r").read()
build_order = json.loads(build_order)
to_build = build_order["order"]

pkg_lists = []  # to aggregate the uploaded package-lists
for level in to_build:
    for recipe in level:  # This could be executed in parallel
        ref = recipe["ref"]
        # For every ref, multiple binary packages are being built.
        # This can be done in parallel too. Often it is for different platforms
        # they will need to be distributed to different build agents
        for packages_level in recipe["packages"]:
            # This could be executed in parallel too
            for package in packages_level:
                build_args = package["build_args"]
                filenames = package["filenames"]
                build_type = "-s build_type=Debug" if any("debug" in f for f in filenames) else ""
                run(f"conan install {build_args} {build_type} --lockfile=conan.lock --format=json", file_stdout="graph.json")
                run("conan list --graph=graph.json --format=json", file_stdout="built.json")
                filename = f"uploaded{len(pkg_lists)}.json"
                run(f"conan upload -l=built.json -r=products -c --format=json", file_stdout=filename)
                pkg_lists.append(filename)

注意

此代码特定于 --order-by=recipe 构建顺序，如果选择 --order-by=configuration，则 json 是不同的，并且需要不同的迭代。

以下是上述 Python 代码正在执行的任务

对于构建顺序中的每个 package，都会发出 conan install --require=<pkg> --build=<pkg>，并且此命令的结果存储在 graph.json 文件中
conan list 命令将此 graph.json 转换为名为 built.json 的软件包列表。请注意，此软件包列表实际上存储了已构建的软件包和必要的传递依赖项。这样做是为了简单起见，因为稍后这些软件包列表将用于运行晋升，并且我们还希望晋升诸如 ai/1.1.0 之类的依赖项，这些依赖项是在 packages pipeline 中构建的，而不是由该作业构建的。
conan upload 命令将软件包列表上传到 products 仓库。请注意，upload 首先检查仓库中已存在哪些软件包，从而避免了昂贵的传输（如果它们已存在）。
conan upload 命令的结果被捕获到一个新的软件包列表中，称为 uploaded<index>.json，我们稍后将累积它，它将用于最终的晋升。

实际上，这转化为以下命令（您可以执行这些命令以继续本教程）

# engine/1.0 release
$ conan install --requires=engine/1.0 --build=engine/1.0 --lockfile=conan.lock --format=json > graph.json
$ conan list --graph=graph.json --format=json > built.json
$ conan upload -l=built.json -r=products -c --format=json > uploaded1.json

# engine/1.0 debug
$ conan install --requires=engine/1.0 --build=engine/1.0 --lockfile=conan.lock -s build_type=Debug --format=json > graph.json
$ conan list --graph=graph.json --format=json > built.json
$ conan upload -l=built.json -r=products -c --format=json > uploaded2.json

# game/1.0 release
$ conan install --requires=game/1.0 --build=game/1.0 --lockfile=conan.lock --format=json > graph.json
$ conan list --graph=graph.json --format=json > built.json
$ conan upload -l=built.json -r=products -c --format=json > uploaded3.json

# game/1.0 debug
$ conan install --requires=game/1.0 --build=game/1.0 --lockfile=conan.lock -s build_type=Debug --format=json > graph.json
$ conan list --graph=graph.json --format=json > built.json
$ conan upload -l=built.json -r=products -c --format=json > uploaded4.json

在此步骤之后，新构建的软件包将位于 products 仓库中，我们将拥有 4 个 uploaded1.json - uploaded4.json 文件。

简化不同的发布和调试配置，我们的仓库状态将类似于

我们现在可以将不同的 uploadedX.json 文件累积到一个包含所有内容的单个软件包列表 uploaded.json 中

$ conan pkglist merge -l uploaded0.json -l uploaded1.json -l uploaded2.json -l uploaded3.json --format=json > uploaded.json

最后，如果一切运行良好，并且我们认为这组新版本和新软件包二进制文件已准备好供开发人员和其他 CI 作业使用，那么我们可以运行从 products 到 develop 仓库的最终晋升

从 products->develop 晋升¶

# Promotion using Conan download/upload commands
# (slow, can be improved with art:promote custom command)
$ conan download --list=uploaded.json -r=products --format=json > promote.json
$ conan upload --list=promote.json -r=develop -c

我们最终的 develop 仓库状态将是

develop 仓库的此状态将具有以下行为

安装 game/1.0 或 engine/1.0 的开发人员默认将解析为最新的 ai/1.1.0 并使用它。他们也会找到依赖项的预编译二进制文件，并且他们可以继续使用最新的依赖项集进行开发。
使用锁定文件的开发人员和 CI 锁定 ai/1.0 版本，仍然可以继续使用该依赖项，而不会发生任何中断，因为新版本和软件包二进制文件不会破坏或使以前存在的二进制文件无效。

此时，可能会出现关于如何处理 Ci 中使用的锁定文件的问题。请注意，conan.lock 现在包含锁定的 ai/1.1.0 版本。可能存在不同的策略，例如将此锁定文件存储在“products”git 仓库中，以便在开发人员检出这些仓库时轻松获得它。但是请注意，此锁定文件与 develop 仓库的最新状态匹配，因此开发人员检出一个“products”git 仓库并针对 develop 服务器仓库执行 conan install 将自然地解析为锁定文件中存储的相同依赖项。

如果以某种方式捆绑了“产品”（安装程序、debian/rpm/choco/etc 软件包），则最好至少将此锁定文件存储在任何发布包中，以包含或附加到此捆绑发布中，供软件的最终用户使用，用于生成它的锁定文件，因此无论开发仓库中发生什么变化，这些锁定文件都可以在以后的时间从发布信息中恢复。

最终评论¶

正如在本 CI 教程简介中评论的那样，这并不打算成为一个万能的解决方案，一个您可以按原样在您的组织中部署的 CI 系统。到目前为止，本教程介绍了开发人员持续集成过程的“快乐路径”，以及如何测试和验证作为更大产品一部分的软件包中的更改，作为这些产品的一部分。

本 CI 教程的重点是介绍一些重要的概念、良好实践和工具，例如

定义组织“产品”的重要性，即需要针对开发人员创建的新依赖项版本进行检查和构建的主要交付成果。
在验证之前，不应将开发人员的新依赖项版本上传到主开发仓库，以免破坏其他开发人员和 CI 作业。
如何使用多个仓库来构建 CI 流水线，该流水线隔离未经验证的更改和新版本。
如何在 CI 中使用 conan graph build-order 有效地构建大型依赖关系图，以及如何将不同配置和产品的构建顺序合并在一起。
当存在并发 CI 构建时，为什么 lockfiles 在 CI 中是必要的。
版本控制的重要性，以及 package_id 在大型依赖关系图中仅重新构建必要内容的作用。
不使用 user/channel 作为在 CI 流水线中更改的软件包的可变和动态限定符，而是使用不同的服务器仓库。
在新软件包版本验证后，运行跨服务器仓库的软件包晋升（复制）。

仍有许多实现细节、策略、用例和错误场景尚未在本教程中涵盖

如何集成需要新的重大版本更新的软件包的重大更改。
不同的版本控制策略，在某些情况下使用预发布版本、使用版本或依赖于配方修订。
锁定文件如何在不同构建之间存储和使用，如果持久化它们是否合适以及在哪里持久化。
不同的分支和合并策略、夜间构建、发布流程。

我们计划扩展此 CI 教程，包括更多示例和用例。如果您有任何问题或反馈，请在 https://github.com/conan-io/conan/issues 中创建工单。