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 上报维护者则遵循本流程文档完成修复与发布。二、分支拓扑四个分支的职责与关系整个流程围绕四个分支运转理解它们的职责是掌握后续所有步骤的前提分支仓库职责masterBudibase/cloud-security私有私有版cloud分支在开始新一轮漏洞工作前必须包含最新的公开cloudcommit特性分支 PRBudibase/cloud-security私有漏洞修复的开发单元合入私有mastercloudBudibase/budibase公开Cloud hotfix 与漏洞发布的唯一来源分支masterBudibase/budibase公开在 Cloud 部署成功后通过 merge-back PR 接收已发布的变更四个分支形成一条单向的数据流私有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特性分支从最新的私有master切出确保基于最新的公开cloud内容PR 必须通过配置的检查项并完成代码审查批准并合并该 PR即标志着修复已就绪、可进入公开推广阶段。整个阶段不向外界暴露任何修复细节这是漏洞保密的关键环节。步骤 3推广到公开仓库private-promote-to-public在Budibase/budibase-deploys中运行private-promote-to-public。该工作流受两道硬性约束前置校验除非私有master包含最新的公开cloudcommit否则推广被阻止——防止基于过期基线发布补丁并发约束同一时间只允许存在一个打开的私有到公开推广 PR避免多个修复在cloud上相互叠加造成发布状态混乱。工作流的执行动作是向Budibase/budibase推送一个临时security/*分支并据此打开一个非草稿non-draftPR指向cloud。这里需要特别强调文档中的一句提醒漏洞在推广动作执行的这一刻变为公开信息。因此在团队尚未准备好审查、合并并发布该 PR 之前不要运行推广工作流——保密窗口的关闭时机完全由推广动作触发而非修复代码完成之时。步骤 4公开 PR 的检查、审查与合并推广生成的公开 PR 走正常的公开检查流程CI、测试、评审等审查通过后合入cloud。从这一步开始修复进入公开主干后续发布以cloud分支上的这个 commit 为基准。步骤 5运行 Cloud hotfix 工作流发布精确 commit使用已合并的公开 PR 编号在Budibase/budibase-deploys中运行 Cloud hotfix 工作流。它执行三项验证与动作验证该 PR 是cloud上最新的变更——保证发布内容与分支状态严格一致只发布这个精确 commit——不会顺带携带任何其他未验证的变更仅递增 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合并回 masterCloud 部署成功后自动化创建的「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]参数说明参数作用--version VERSION指定基础版本格式必须为X.Y.Z如3.44.1默认从最新vX.Y.Z-cloud[.N]tag 自动检测--dry-run只打印将要创建的基线分支与 hotfix 分支名称不执行任何 git 写操作-h / --help打印用法说明脚本的关键行为可作为本流程第 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 PRcloud合入master必须使用 merge commit以保留分支祖先关系branch ancestry使同步始终可以保持 fast-forward only。原因可以拆解为两层fast-forward 同步依赖线性历史private-sync-from-public之所以能「一键 fast-forward」正是因为它信任公开cloud的历史是线性的、无分叉的。只要cloud上的每个变更都以 merge commit 落盘私有master就能直接快进到最新 commitsquash/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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Budibase 漏洞修复与发布流程解析：私有修复、公开推广与 Cloud Hotfix 全链路
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 上报维护者则遵循本流程文档完成修复与发布。二、分支拓扑四个分支的职责与关系整个流程围绕四个分支运转理解它们的职责是掌握后续所有步骤的前提分支仓库职责masterBudibase/cloud-security私有私有版cloud分支在开始新一轮漏洞工作前必须包含最新的公开cloudcommit特性分支 PRBudibase/cloud-security私有漏洞修复的开发单元合入私有mastercloudBudibase/budibase公开Cloud hotfix 与漏洞发布的唯一来源分支masterBudibase/budibase公开在 Cloud 部署成功后通过 merge-back PR 接收已发布的变更四个分支形成一条单向的数据流私有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特性分支从最新的私有master切出确保基于最新的公开cloud内容PR 必须通过配置的检查项并完成代码审查批准并合并该 PR即标志着修复已就绪、可进入公开推广阶段。整个阶段不向外界暴露任何修复细节这是漏洞保密的关键环节。步骤 3推广到公开仓库private-promote-to-public在Budibase/budibase-deploys中运行private-promote-to-public。该工作流受两道硬性约束前置校验除非私有master包含最新的公开cloudcommit否则推广被阻止——防止基于过期基线发布补丁并发约束同一时间只允许存在一个打开的私有到公开推广 PR避免多个修复在cloud上相互叠加造成发布状态混乱。工作流的执行动作是向Budibase/budibase推送一个临时security/*分支并据此打开一个非草稿non-draftPR指向cloud。这里需要特别强调文档中的一句提醒漏洞在推广动作执行的这一刻变为公开信息。因此在团队尚未准备好审查、合并并发布该 PR 之前不要运行推广工作流——保密窗口的关闭时机完全由推广动作触发而非修复代码完成之时。步骤 4公开 PR 的检查、审查与合并推广生成的公开 PR 走正常的公开检查流程CI、测试、评审等审查通过后合入cloud。从这一步开始修复进入公开主干后续发布以cloud分支上的这个 commit 为基准。步骤 5运行 Cloud hotfix 工作流发布精确 commit使用已合并的公开 PR 编号在Budibase/budibase-deploys中运行 Cloud hotfix 工作流。它执行三项验证与动作验证该 PR 是cloud上最新的变更——保证发布内容与分支状态严格一致只发布这个精确 commit——不会顺带携带任何其他未验证的变更仅递增 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合并回 masterCloud 部署成功后自动化创建的「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]参数说明参数作用--version VERSION指定基础版本格式必须为X.Y.Z如3.44.1默认从最新vX.Y.Z-cloud[.N]tag 自动检测--dry-run只打印将要创建的基线分支与 hotfix 分支名称不执行任何 git 写操作-h / --help打印用法说明脚本的关键行为可作为本流程第 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 PRcloud合入master必须使用 merge commit以保留分支祖先关系branch ancestry使同步始终可以保持 fast-forward only。原因可以拆解为两层fast-forward 同步依赖线性历史private-sync-from-public之所以能「一键 fast-forward」正是因为它信任公开cloud的历史是线性的、无分叉的。只要cloud上的每个变更都以 merge commit 落盘私有master就能直接快进到最新 commitsquash/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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考