Metabase 如何自动化发布：从手工清单到每日补丁

过去，发布 Metabase 需要手动完成一长串检查清单。如今，我们每天都会发布一个新补丁，无需任何人动手。以下是我们如何做到这一点的。

我从手动时代开始

2022 年，当我第一次被分配轮值担任发布经理时，发布 Metabase需要遵循一份冗长而复杂的检查清单：在本地开发机器上构建二进制文件，进行一些手动点击测试以验证二进制文件的完整性，运行一些脚本将其容器化，最后上传到 Docker Hub 和我们的网站。这过程并不算糟糕，尤其是因为我们每两周（或更久）才发布一个新的 Metabase 小版本，每三到四个月才发布一个新的主版本。

我知道我们可以做得更好，原因有几点：

1. 我太懒了，不想走完这长长的检查清单。
2. 这个过程极易出错（在我的教学发布中，第一次上传到网站失败了，因为上传的开发者离他的 Wi-Fi 路由器太远了）。
3. 我太懒了，不想走完这长长的检查清单。

将检查清单转变为 GitHub Actions

这需要将一堆杂乱的 Bash 和 Clojure 脚本转换为更连贯（且经过测试）的 TypeScript 函数集。

该流程的初稿包含三个独立的工作流：

1. 构建
2. 测试
3. 发布

每个工作流独立运行，将 GitHub 产物传递给下一个工作流。分离的工作流使整个过程相当手动化，但在我们自动化一个关键系统时，拥有高度控制权是有帮助的。

复用经过测试的构建

最终，我们意识到构建和测试分开其实毫无理由。我们从来没有出现过想要构建一个产物但不想测试它的情况，因此我们将流程精简为两个工作流：

1. 构建 + 测试
2. 发布

我们的构建过程也相当浪费，耗时约 30 分钟。但我们有了一个想法。我们在测试过程中已经在构建二进制文件，只是没有为这些二进制文件分配版本号。所以我们的下一步是跳过构建，转而抓取最近构建的二进制文件，并为其打上发布版本的标签。除了从发布过程中减少近半小时外，这也让我们对构建的完整性有了更大的信心。从那时起，我们发布的每一个二进制文件都不仅经过预发布冒烟测试，还经过了完整的测试套件。

1. 打标签版本 + 测试
2. 发布

随着我们对这个工作流越来越有信心，它真的变成了只需触发几个 GitHub Actions 的事情，我们将发布频率从每两周一次改为每周一次。我们经常每周发布多个主要 Metabase 版本的小版本（如 v61.2 和 v60.9）。

让发布自行运行

随着我们习惯了更快地发布，我们的成功团队尤其对我们能够更快地向特定客户发布错误修复感到兴奋，甚至每周的节奏也开始显得不必要地缓慢。为什么我们不应该尽快向客户发布错误修复呢？因此，从2024 年 8 月开始，我们开始每个工作日都发布补丁。

但我的懒惰变得更加强烈。我意识到，让人手动启动每日补丁毫无意义。因此，我们将发布设置为 cron 调度，并设置了一些非常保守的测试关卡。每天下午，该流程会为最近的两个主要 Metabase 版本发布补丁，基于通过所有测试的最新提交构建。这种完全自主的发布模式要求将我们所有的发布步骤串联起来：

1. 打标签版本 + 测试 + 发布

有一段时间，我们以这种方式每天发布补丁，直到我们开始质疑为什么小版本发布还需要人工参与。我们想不出一个好的理由，因此我们也为小版本发布设置了每周 cron。

三击发布，Windows 95 风格

一切都进展得如此之快，为什么不在我们有 Metabase Cloud 的变更或客户需要紧急修复时按需发布呢？因此，我们在内部 CI 系统中构建了一个 UI，使发布新版本 Metabase 成为字面意义上的三次点击操作。

Windows 95 主题让它更快了。

事实证明，懒惰，持续应用几年，看起来很像持续交付。

这对 Metabase 用户意味着什么

你不需要每天升级你的 Metabase，但如果你在等待一个修复，你可以在修复的当天就获得它，而不是两周后。如果你使用Metabase Cloud，你无需做任何事情就能获得它。如果你自托管，在你需要时获取补丁，或者在你准备好之前继续使用当前版本。

更多来自 Metabase 工程团队

• 认识 Repro-Bot，我们的 GitHub 问题分类代理
• 我们如何构建十个自定义子代理来驯服一个 50 万行的 Clojure 代码库
• 提升流行 Clojure 开发工具 clojure-lsp 的性能
• 我们如何选择 LibreChat —— 并最终得到一个 Slack 代理

如果你有兴趣帮助我们持续发布，我们一直在招聘。