发布推广中的 Balrog

概述

Balrog 是 Mozilla 的更新服务器。它负责将 Firefox 的新版本交付给现有的 Firefox 安装。如果您还不熟悉，在继续阅读本文档之前，熟悉 Balrog 的核心概念将很有帮助。您可以在 Balrog 的官方文档 中找到这些信息。

发布推广与 Balrog 之间的基本交互如下

  1. 使用多个 balrog 任务和 release-balrog-submit-toplevel 任务，将新的发布元数据提交到 Balrog。

  2. 在 release-balrog-submit-toplevel 任务中，更新测试通道以指向新的发布。

  3. 使用 release-update-verify 和 release-final-verify 任务验证新的发布更新。

  4. 在 release-balrog-scheduling 任务中，安排新的发布进行分发。

提交新的发布元数据

在 Balrog 能够分发更新之前，它需要许多不同的信息。这些信息大部分与更新文件 (MAR) 元数据（哈希值、文件大小、目标平台、目标语言环境）有关。这些信息由 balrog 任务提交。

我们还作为 release-balrog-submit-toplevel 任务的一部分提交了一些关于发布的更一般的信息（版本号、MAR URL 模板、发布名称等）。

所有 balrog 提交均由 balrogscript 工作进程 完成，并且发生在 promote 阶段。

更新测试通道

Balrog 具有“测试”通道，我们使用这些通道在分发之前验证新的发布更新。每当我们准备一个新的发布时，release-balrog-submit-toplevel 任务负责更新这些测试通道。这发生在 promote 阶段。

验证发布

一旦发布在测试通道上上线，release-update-verify 就会开始并执行一些基本检查。这发生在 promote 阶段。

发布推送到 CDN 后，release-final-verify 将运行并执行一些额外的检查。这发生在 push 阶段。

安排分发

当我们准备分发发布时，我们需要通过安排对相应的 Balrog 规则进行更改来让 Balrog 知道。如果设置了 release_eta，它将用作分发日期和时间。如果没有，发布将在未来 5 分钟内安排分发。无论哪种情况，在发布实际上线之前，都需要由多方在 Balrog 中进行签核。

此步骤由 release-balrog-scheduling 任务在 ship 阶段完成。

secondary 任务

您可能已经注意到 release-balrog-submit-toplevel、release-update-verify、release-final-verify 和 release-balrog-scheduling 任务的 secondary 变体。它们的功能与其主要对应项相同，但适用于“beta”更新通道。仅当我们构建候选发布版本时才会使用它们。