企业官网建设流程全解析

Budibase 漏洞修复与发布流程解析：私有修复、公开推广与 Cloud Hotfix 全链路

【免费下载链接】budibaseAI agents, automations and apps that run your operations. Model agnostic.项目地址: https://gitcode.com/GitHub_Trending/bu/budibase

导读

Budibase 在 docs/VULNERABILITY_RELEASE_PROCESS.md 中定义了一套兼顾「漏洞细节保密」与「发布效率」的修复发布流程：漏洞修复在私有仓库Budibase/cloud-security中开发与审查，通过自动化工作流转为公开 PR 合入Budibase/budibase:cloud，再由 Cloud hotfix 工作流精确发布该 commit，最后合并回master。读完本文，你将完整掌握这套流程的四个关键分支、七步操作链路、版本号递增规则（如v3.45.0-cloud.1 -> v3.45.0-cloud.2），以及「为何必须使用 merge commit 而非 squash/rebase」的底层原因，并能在当前仓库中找到对应的配套脚本实现。

一、为什么需要一条独立的漏洞发布通道

Budibase 是一个以 Cloud 服务与开源仓库共同支撑的平台。开源仓库中的常规发布面向所有用户，而安全漏洞的修复存在一个天然矛盾：

• 修复细节必须保密：在补丁随公开版本落地之前，过早暴露漏洞细节会给攻击者提供可利用窗口；
• 发布节奏必须可控：Cloud 服务需要在不影响常规主版本发布节奏的前提下，快速、精确地只携带漏洞修复上线。

因此，Budibase 采用「私有开发 + 公开推广 + 精确发布」三阶段通道：修复在私有仓库中完成并审查，通过自动化机制以公开 PR 形式合入cloud分支，最终由 Cloud hotfix 工作流发布。与之配套的还有 SECURITY.md 中声明的安全策略：作为开源产品，Budibase 仅对最新大版本修补安全漏洞，历史版本不会追溯修补；漏洞通过 GitHub Security Advisory 上报，维护者则遵循本流程文档完成修复与发布。

二、分支拓扑：四个分支的职责与关系

整个流程围绕四个分支运转，理解它们的职责是掌握后续所有步骤的前提：

四个分支形成一条单向的数据流：私有master从公开cloud同步 → 私有修复合入 → 推广回公开cloud→ Cloud hotfix 发布 → 合并回公开master。公开侧的两个分支始终保持线性祖先关系，私有侧只是公开cloud的一份「带保密补丁的镜像」，这种拓扑设计是整个流程能够使用 fast-forward 同步的前提。

三、端到端七步流程详解

步骤 1：同步私有分支（private-sync-from-public）

在Budibase/budibase-deploys仓库中运行private-sync-from-public工作流，将私有master从公开cloudfast-forward推进。

该工作流有一个关键安全机制：如果两个分支已经分叉（diverged），同步会直接停止，而不是强行合并。这一设计与第 5 节「合并策略」中的要求互为表里——只有始终保持 fast-forward 关系，私有仓库才能精确镜像公开cloud，后续的推广校验（步骤 3）才能成立。

步骤 2：在私有仓库实现并审查修复

在Budibase/cloud-security中基于私有master创建特性分支，实现修复后向私有master提交 PR：

1. 特性分支从最新的私有master切出，确保基于最新的公开cloud内容；
2. PR 必须通过配置的检查项并完成代码审查；
3. 批准并合并该 PR，即标志着修复已就绪、可进入公开推广阶段。

整个阶段不向外界暴露任何修复细节，这是漏洞保密的关键环节。

步骤 3：推广到公开仓库（private-promote-to-public）

在Budibase/budibase-deploys中运行private-promote-to-public。该工作流受两道硬性约束：

• 前置校验：除非私有master包含最新的公开cloudcommit，否则推广被阻止——防止基于过期基线发布补丁；
• 并发约束：同一时间只允许存在一个打开的私有到公开推广 PR，避免多个修复在cloud上相互叠加造成发布状态混乱。

工作流的执行动作是：向Budibase/budibase推送一个临时security/*分支，并据此打开一个非草稿（non-draft）PR指向cloud。

这里需要特别强调文档中的一句提醒：漏洞在推广动作执行的这一刻变为公开信息。因此，在团队尚未准备好审查、合并并发布该 PR 之前，不要运行推广工作流——保密窗口的关闭时机完全由推广动作触发，而非修复代码完成之时。

步骤 4：公开 PR 的检查、审查与合并

推广生成的公开 PR 走正常的公开检查流程（CI、测试、评审等），审查通过后合入cloud。从这一步开始，修复进入公开主干，后续发布以cloud分支上的这个 commit 为基准。

步骤 5：运行 Cloud hotfix 工作流发布精确 commit

使用已合并的公开 PR 编号，在Budibase/budibase-deploys中运行 Cloud hotfix 工作流。它执行三项验证与动作：

1. 验证该 PR 是cloud上最新的变更——保证发布内容与分支状态严格一致；
2. 只发布这个精确 commit——不会顺带携带任何其他未验证的变更；
3. 仅递增 Cloud revision，即只递增-cloud.N后缀，不触碰基础版本号：

v3.45.0-cloud.1 -> v3.45.0-cloud.2

这个版本号格式在当前仓库中有直接佐证：scripts/create-hotfix.sh 中通过正则^v[0-9]+\.[0-9]+\.[0-9]+-cloud(\.[0-9]+)?$匹配形如vX.Y.Z-cloud[.N]的 tag，并用git tag -l "v*-cloud*" --sort=-v:refname从所有 cloud tag 中挑选最新者作为 hotfix 基线——可见-cloud.N后缀正是 Cloud 发布通道的版本标识，主版本号X.Y.Z与常规发布共用。

步骤 6：合并回 master

Cloud 部署成功后，自动化创建的「cloud→master」merge-back PR 会走正常检查流程完成合并。至此，漏洞修复同时出现在cloud与master两条公开分支上，后续常规发布版本也将包含该修复。

步骤 7：为下一轮修复重置同步基线

在开始下一个私有修复之前，再次运行private-sync-from-public，把私有master重新对齐到包含本次修复后的公开cloud。这也印证了文档开头对分支拓扑的要求：私有master「在新漏洞工作开始前应始终包含最新的公开cloudcommit」。

四、配套脚本：仓库中的 hotfix 实操支撑

虽然private-sync-from-public、private-promote-to-public与 Cloud hotfix 工作流本身位于Budibase/budibase-deploys（独立于本仓库），但当前仓库提供了与这套流程配套的本地脚本，可以直接对照阅读：

1. 创建 hotfix 分支：scripts/create-hotfix.sh

该脚本从最新的 cloud release tag 创建发布基线分支与 hotfix 分支，用法为：

bash scripts/create-hotfix.sh [--version VERSION] [--dry-run]

参数说明：

脚本的关键行为（可作为本流程第 5 步的本地演练）：

• 运行前检查工作区是否干净（git status --porcelain非空即退出），防止 hotfix 混杂未提交的本地改动；
• 通过git fetch origin --tags拉取全部 tag，按语义化版本排序选取最新 cloud tag；
• 从cloud_tag解析出版本号，推导基线分支名X.Y.Z与 hotfix 分支名hotfix/X.Y.Z；
• 若同名分支在本地或远端已存在，脚本直接报错退出，保证每个 hotfix 只创建一次；
• 实际创建时先git switch -c <base> <cloud_tag>推送基线分支，再从基线切出hotfix/<version>并推送，最后提示在该分支上应用修复或从mastercherry-pick。

根目录 package.json 中注册了对应命令："hotfix:create": "bash scripts/create-hotfix.sh"，可通过yarn hotfix:create调用。

2. 盘点待发布内容：scripts/pendingReleases.js

该脚本与「合并回 master 后确认还有哪些 PR 待进入下一次 Cloud 发布」的场景配套：

• 通过git tag --list "v*-cloud*" --sort=-version:refname找到最新 cloud release tag（支持TAG环境变量覆盖）；
• 以该 tag 的提交时间为起点，用gh pr list查询所有已合并到master的 PR，生成「待发布 PR」清单（编号、合并时间、作者、标题）；
• 支持--dry-run仅在终端输出清单；配置SLACK_BOT_TOKEN与SLACK_CHANNEL_ID后可直接推送到 Slack。

根目录 package.json 中注册为"pending-releases": "node scripts/pendingReleases.js"，即yarn pending-releases。

五、合并策略：为什么必须使用 merge commit

这是整个流程中容易被忽视、却决定链路能否持续运转的关键约束：

公开推广 PR（进入cloud）与 merge-back PR（cloud合入master）必须使用 merge commit，以保留分支祖先关系（branch ancestry），使同步始终可以保持 fast-forward only。

原因可以拆解为两层：

1. fast-forward 同步依赖线性历史：private-sync-from-public之所以能「一键 fast-forward」，正是因为它信任公开cloud的历史是线性的、无分叉的。只要cloud上的每个变更都以 merge commit 落盘，私有master就能直接快进到最新 commit；
2. squash/rebase 会制造「伪分叉」：squash 合并把多个 commit 压成一个新 commit、rebase 会改写 commit 哈希，即使代码内容完全等价，Git 也会把它们视为不同的历史节点。一旦这种「内容相同但历史不同」的分叉出现，下一次同步或发布的校验（如步骤 3 的「必须包含最新 cloud commit」检查）就会判定失败，阻塞整条链路。

文档同时强调：工作流永远不会在分叉之上 force-push 覆盖。如果意外出现了分叉，正确做法是通过一个经过审查的 PR 显式解决，而不是用push --force强行抹平——这既保护了公开分支历史的可信度，也避免覆盖掉可能包含其他团队变更的提交。

六、流程要点速览与最佳实践

• 保密窗口由推广动作关闭：漏洞在private-promote-to-public执行时公开，只有团队就绪才允许触发；
• 发布内容精确可控：Cloud hotfix 只发布「cloud上最新且唯一」的那个 PR commit，版本号仅递增-cloud.N后缀；
• 同步保持线性：私有master对公开cloud只做 fast-forward；发现分叉立即停止，绝不 force-push；
• 合并方式统一：推广 PR 与 merge-back PR 一律使用 merge commit，禁止 squash/rebase；
• 发布节奏闭环：每轮修复以private-sync-from-public开始，也以它结束，保证私有基线永远贴着公开cloud的最新状态。

通过「私有修复保密开发 → 自动化推广公开 → 精确 hotfix 发布 → 合并回主干」这一闭环，Budibase 在保持漏洞细节尽可能晚公开的同时，保证了 Cloud 服务与开源主干都能以可审计、可回滚、可追溯的方式获得安全修复。需要深入实现细节的读者，可继续阅读 scripts/create-hotfix.sh、scripts/pendingReleases.js 以及 SECURITY.md 中与本流程对应的安全策略声明。

【免费下载链接】budibaseAI agents, automations and apps that run your operations. Model agnostic.项目地址: https://gitcode.com/GitHub_Trending/bu/budibase