在 Redpanda,我们希望始终为开发人员提供快速、简单和高效的体验。这也适用于我们自己的工程师团队。

在考虑如何实现更稳定的持续集成 (CI) 管道时,我们想要同样的体验:快速、简单、高效。通过在我们的 CI 平台Buildkite上并行运行我们的管道步骤的多个实例,我们现在可以运行同一 Buildkite 步骤的多次重复,并且只使用单个步骤所需的时间。

今天,我们的开发人员只需在他们的 PR 上附加一个标签,比如“ci-repeat-X”,就可以并行启动任意数量的构建。在本文的其余部分,我将讨论我们如何使这种简单的开发体验成为可能。我讨论了我们如何通过利用 Buildkite 的parallelism属性和pre-command钩子来实现可重复构建,并结合用于触发并行构建的拉取请求上的 GitHub 标签。

Buildkite 并行编程

当 Buildkite 引入一个新功能以并行运行构建步骤的多次重复时,我们通过在我们的 CI 管道配置中添加一个称为并行性的属性来利用这一点。我们使用此属性来定义所需的并行度。我们开始使用一个常数值 1。

然而,挑战在于让parallelism值可配置,以便用户可以随时启用/禁用它,提供他们选择的值,该值表示每步的并行实例数。理想情况下,我们希望开发人员能够在 Buildkite 的上下文之外配置此数字。一个很好的候选者是 GitHub,但我们需要它和 Buildkite 之间的“桥梁”。无法在查询 GitHub 拉取请求的步骤命令中配置桥接器,因为在运行时配置步骤的并行属性为时已晚。在寻找实现这一点的方法时,我们发现了 Buildkite 的pre-command钩子。

Buildkite 前置命令

Buildkite 包含我们可以启用的钩子,以便在启动步骤命令之前 (pre-command) 或在步骤运行之后 (post-command) 自动执行它们。我们利用pre-command挂钩来发现用户想要配置为parallelism值的值。通过这样做,我们创建了一种在管道步骤执行之前运行我们想要的任何 bash 脚本的方法。这意味着我们可以调整pre-command挂钩中的变量,以更新 Buildkite 步骤的parallelism属性。

完成此操作后,我们解决了下一个自然问题:用户在打开拉取请求时更新此变量最有效的流程是什么?我们的选择是:

• 评论拉取请求(例如/hey-buildkite repeat 5)

• 编辑文件更新值并推送代码

• 添加 GitHub 标签(例如ci-repeat-5)

我们的选择路径是:

• 多产

• 易于使用

• 清洁

如果我们选择第一个选项,我们最终会进行一次大型的拉取请求对话,其中包含许多分散的评论,这些评论会使开发人员之间关于拉取请求的对话变得混乱。因此,我们没有选择此选项,因为它违反了第二条和第三条路径。

对于第二个选择,我们必须回答以下问题:

• 当我们要合并PR时会发生什么?

• 我们是否希望我们的默认分支基于这个文件并并行运行? (如果是这样,对我们的成本有什么影响?)

因此,选项二提出的问题也表明这不是最好的选择。此外,它违反了第二选择路径,因为用户每次想要更新并行请求级别时都必须推送代码。

因此,我们决定采用第三个也是最好的选择:添加 GitHub 标签。使用此过程,希望并行运行 PR 测试的用户只需在其 PR 中添加标签并重建管道。

工作流程

parallelism属性在pipeline.yml配置的每个 Buildkite 步骤中设置。它的值是通过名为PARALLEL_STEPS的环境变量动态提供的。我们只需要使用pre-command钩子修改这个环境变量。

在将步骤加载到查询 GitHub API 的 Buildkite 之前,我们编写了一个脚本来运行。这使我们能够获取此 PR 的标签(Buildkite 提供 PR 编号作为环境变量BUILDKITE_PULL_REQUEST)并将这些标签与模式ci-repeat-NN进行匹配。因此,我们准备好了整个工作流程:钩子查询并获取特定标签,发现数字,并将其导出为环境变量PARALLEL_STEPS。

费用呢?我们不应该要求用户在完成工作后删除这个标签吗?否则,不是每次提交都会让 Buildkite 并行运行多个步骤吗?如前所述,我们的目标是提高开发人员的生产力。要求用户在作业后删除标签是手动步骤,我们尽可能避免这些。当pre-command发现标签后,保留在PR上是没有用的,所以我们使用的bot可以删除它。因此,我们只需删除标签即可减少开发人员所需的手动步骤并降低成本。

构建时考虑到 DevProd

总之,我们并行运行多个 CI 步骤实例的过程是在考虑开发人员生产力的情况下创建的。通过在 Buildkite 上并行运行多个 CI 步骤实例,我们减少了构建的总运行时间并提高了 Redpanda 中 CI 测试的稳定性。

了解有关 Redpanda 的更多信息并在 GitHub](https://github.com/redpanda-data/redpanda/)上下载我们的二进制文件[。通过加入我们的 Slack 社区直接与我们的开发人员互动,就我们的 CI 步骤或其他任何问题提出问题。有关 Redpanda 及其功能的更多信息,浏览我们的文档。