拓冰网站定制 
Velero 版本发布全流程指南从 RC 到 GA 的完整发布操作手册【免费下载链接】veleroBackup and migrate Kubernetes applications and their persistent volumes项目地址: https://gitcode.com/GitHub_Trending/ve/velero本篇指南完整讲解 Velero 项目的版本发布流程从版本类型定义、发布候选RC与正式版GA的准入标准到 changelog 生成、文档版本化、tag-release.sh打标签发布、GoReleaser 构建 GitHub Release、Homebrew/Chocolatey 分发、插件与 Helm Chart 同步发布直至最终对外公告的每一个环节。读者读完本篇后可以对照仓库中的真实脚本如 hack/release-tools/tag-release.sh完整走通一次 Velero 的发布流程并理解每个步骤背后的设计与脚本实现细节。Velero 的版本类型与发布模型GA、Pre-release 与 RC 的定义Velero 的版本号遵循语义化版本SemVer规范官方文档给出了如下分类版本类型说明示例GAGeneral Availability正式发布版本仅包含 major 和 minor 版本1.0major、1.5minorPre-release预发布通往 GA 过程中的任何发布版本1.4.0-beta.1、1.5.0-rc.1RCRelease Candidate发布候选包含计划随 GA 发布的所有内容本身仍是预发布版本1.5.0-rc.1这一分类不是随意约定的而是被发布脚本严格强制校验的。仓库中的 hack/release-tools/chk_version.go 用一段正则表达式约束版本号格式var releaseRegex regexp.MustCompile(^v(?Pmajor[[:digit:]])\.(?Pminor[[:digit:]])\.(?Ppatch[[:digit:]])(-{1}(?Pprerelease(alpha|beta|rc)\.[[:digit:]]))*)该正则同时匹配 GA 格式如v1.4.3与预发布格式如v1.2.4-beta.2、v1.5.0-rc.1并通过命名捕获组解析出major、minor、patch、prerelease四个组成部分输出为 bash 可eval的环境变量VELERO_MAJOR、VELERO_MINOR、VELERO_PATCH、VELERO_PRERELEASE。也就是说版本号合法性在发布第一步就被脚本强制把关任何不符合上述格式的VELERO_VERSION都会导致脚本直接退出exit 1这正是发布流程可执行化设计的体现。Train leaves the station 发布模型Velero 采用火车离站train leaves the station式的时间驱动发布模型到达预定时间节点即生成一个 RC测试中发现 bug 就再生成新的 RC测试全部通过后才生成正式发布构建。这种模型强调按时发布优先而不是功能齐了才发布。发布准入标准RC 与 GA 的质量门槛Release Candidate 准入条件在进入 RC 阶段前候选 commit 必须满足没有遗留的重大 bugNo major bugs outstanding单元测试全部通过E2E 测试在最新版 Kubernetes 上的AWS、vSphere 和 kind环境通过一旦进入 RC 阶段即进入**代码冻结code freeze**状态此后只允许合并与发布相关的必要变更。仓库中对应的 e2e 测试代码位于 test/e2e 目录。GA 正式发布准入条件RC 想要转为正式发布还必须满足更高标准单元测试全部通过E2E 测试在Azure、vSphere、Kind、AWS、GCP五个平台上分别针对最新版 Kubernetes 与最早受支持的 Kubernetes 版本通过手动测试通过手动测试用例会逐步转化为自动化测试当上述任一环节发现 bug 时维护者会评估该 bug 是否为发布阻塞release blocker若是则修复后重新生成 RC 并重启整个测试周期。发布前的准备工作为 GA 版本撰写发布博客每个 major/minor 版本都需要创建并发布一篇博客向社区介绍新特性具体写作与发布指引见本文发布博客的写作要点一节。Changelog 与文档 PR这是整个准备工作中最繁琐、也是信息量最大的一步官方文档将其拆解为以下步骤创建版本化 changelog 文件在changelogs/目录下复制最近的 changelog 文件得到changelogs/CHANGELOG-major.minor.md如CHANGELOG-1.15.md仓库中已有 changelogs/CHANGELOG-1.15.md 等系列文件可作参照。生成未发布变更清单运行make changelog该命令实际调用 hack/release-tools/changelog.sh。脚本会遍历changelogs/unreleased目录仓库当前存有大量以PR号-贡献者名命名的未发布条目文件对每个文件解析出 PR 号与贡献者输出形如* 变更内容 (#PR号, 贡献者)的条目列表然后将输出粘贴到CHANGELOG-major.minor.md的 All Changes 一节下并更新文件顶部的版本链接。更新主 CHANGELOG编辑仓库根目录的 CHANGELOG.md保持结构规整——Current release 一节只保留当前 GA 版本Development release 一节只放最新的预发布版本并把之前的预发布移入 Older releases 列表。仓库当前 CHANGELOG.md 的现状就是该结构的实际样例。仅 GA清空未发布目录删除changelogs/unreleased下的所有条目文件。changelog.sh脚本末尾也提示执行git rm ${CHANGELOG_PATH}/*完成清理。生成版本化文档运行make gen-docs调用 hack/release-tools/gen-docs.sh传入合适的变量。官方给出两种示例预发布VELERO_VERSIONv1.5.0-rc.1 NEW_DOCS_VERSIONv1.5.0-rc.1 make gen-docsGAVELERO_VERSIONv1.5.0 NEW_DOCS_VERSIONv1.5 make gen-docs注意VELERO_VERSION与NEW_DOCS_VERSION的语义不同VELERO_VERSION是发布的具体版本同一 major.minor 下可能有v1.5.0、v1.5.1等多个小版本而NEW_DOCS_VERSION决定站点 URL 与版本下拉框里显示的名称例如 GA 后可以一直是v1.5。PREVIOUS_DOCS_VERSION为可选变量不设置时脚本会自动取site/content/docs/下字母序最后的目录作为对比基线。gen-docs.sh的内部逻辑非常值得细读它先把上一个版本化文档目录整体复制到新目录并git add建立 diff 基线再用main目录内容覆盖之对 ToC 文件site/data/docs/version-toc.yml同样先复制后覆盖随后通过sed将文档内指向main分支的版本化链接替换为$VELERO_VERSION并更新 site/config.yaml 的latest字段、版本列表以及 site/data/toc-mapping.yml 的映射条目。清理旧的预发布版本化文档如果目标版本已存在预发布版本化文档例如要发布v1.5.0-rc.1或v1.5但site/content/docs/v1.5.0-beta.1已存在需要依次删除site/content/docs/pre-release-version目录删除site/data/docs/pre-release-version-toc.yml从 site/data/toc-mapping.yml 移除对应映射从 site/config.yaml 移除该预发布版本的所有引用。创建/更新 Upgrade to $major.minor 页面若不存在则创建该升级指南页面main与已版本化目录都要做若已存在则把文件中旧的版本号字符串更新为新版本号。仓库中可参考site/content/docs/main下的既有升级文档。审查并提交 PR按 site/README-HUGO.md 的补充说明完成文档生成收尾审查 diff或运行make serve-docs本地预览站点效果最后提交包含 changelog 与版本化文档的 PR。排障提示执行make serve-docs时若遇到You dont have enough free space in /var/cache/apt/archives/错误运行docker system prune释放空间即可。固定基础镜像Pin the base image为保证发布可复现reproducibility在打 RC 标签之前需要确保发布分支上的 Dockerfile 中基础镜像通过digest而非 tag引用。Velero 镜像基于 Google 的 Distroless 镜像构建按 digest 固定引用可以防止基础镜像被重新推送后引入不确定性。执行 Velero 发布前置条件包含 changelog 与文档的 PR 必须已合并这样其内容才会进入发布标签对应的 commit。该流程对预发布与 GA 同样适用。仓库已配置名为upstream的远程仓库可用git remote -v检查tag-release.sh 默认使用upstream可通过环境变量REMOTE覆盖。理解 tag-release.sh 的核心逻辑发布的核心脚本是 hack/release-tools/tag-release.sh。从源码看它按顺序完成以下动作参数与环境检查脚本开头set -eo pipefail保证任何一步失败即中断。它要求VELERO_VERSION与GITHUB_TOKEN必须已设置否则打印提示并 exit 1并检查工作区必须干净git status --short为空否则 exit 3避免误把未提交内容带入发布。版本校验与解析先执行go run $DIR/chk_version.go --verify校验版本格式失败 exit 2再执行eval $(go run $DIR/chk_version.go)解析出版本组件。发布类型判断根据解析结果自动判断VELERO_PATCH ! 0→ 判定为patch 发布如v1.9.1自动假设标签打在 release 分支上无VELERO_PRERELEASE→ 判定为GA 发布同样假设打在 release 分支上有VELERO_PRERELEASE→ 判定为pre-release。交互确认脚本会打印基于版本字符串做出的全部假设是否为 patch/pre-release/GA、标签应落在哪个分支并等待回车确认按ctrl-c可随时取消。拉取并切换分支git fetch $remote --tags后若是发布分支场景release-$major.$minor会检查远端分支是否存在不存在则报错退出并 checkout 本地分支或跟踪远端分支否则 checkout$remote/main。打标签并推送tag_and_push()执行git tag $VELERO_VERSION仅当以publish参数调用时才执行git push $remote $VELERO_VERSION。调用 GoReleaser以RELEASE_NOTES_FILEchangelogs/CHANGELOG-$VELERO_MAJOR.$VELERO_MINOR.md和PUBLISH$publish运行make release构建发布产物并可选生成 GitHub release。干跑清理dry-run 模式下publishFALSE脚本在结束后切回原分支并删除本地标签git tag -d $VELERO_VERSION保证正式发布时不会与残留标签冲突。分步发布操作在 GitHub 上手动创建 release 分支命名形如release-$major.$minor例如release-1.9。干跑dry-run打标签——不会向 GitHub 推送任何内容VELERO_VERSIONv1.9.0-rc.1 REMOTEupstream-remote GITHUB_TOKENREDACTED ON_RELEASE_BRANCHTRUE ./hack/release-tools/tag-release.sh发现任何问题先在此阶段修复。排障提示如果 dry-run 出现随机错误可以重跑一次。正式打标签并推送VELERO_VERSIONv1.9.0-rc.1 REMOTEupstream-remote GITHUB_TOKENREDACTED ON_RELEASE_BRANCHTRUE ./hack/release-tools/tag-release.sh publish此时脚本才会把标签推送到远端并由 GoReleaser 生成 draft 状态的 GitHub release。发布 GitHub Release在仓库 Releases 页面编辑该 draft release需要注意若是patch 发布如v1.9.1CHANGELOG-1.9.md的完整内容会进入 release 正文必须删除上一版本如v1.9.0的 changelog 内容只保留最新 patch 版本的部分快速检查格式GoReleaser 会自动为预发布版本勾选 pre-release 复选框但建议人工二次确认确认 GitHub Actions 已构建并推送全部镜像需要一段时间确认镜像出现在 Docker Hub 的velero/velerotags 页面确认发布产物assets已上传最后点击发布。测试发布产物此时 Docker 镜像应已公开做一次 smoke test从 GitHub release 下载 CLI用它安装 Velero 到集群或手动把现有 deployment 更新到新镜像验证velero version输出符合预期执行一次 backup/restore确认功能正常。make release目标背后的实现也值得了解它会进入构建容器执行 hack/release-tools/goreleaser.sh。该脚本强制要求GITHUB_TOKEN、RELEASE_NOTES_FILE、REGISTRY三个变量先执行goreleaser check校验 .goreleaser.yml 配置格式PUBLISH非TRUE时以--snapshot模式生成本地快照不发布任何产物为TRUE时才真正执行goreleaser release生成 draft release。这一设计确保了本地验证与真正发布通过一个开关严格隔离。Homebrew 发布仅 GA为方便 macOS 用户通过 Homebrew 安装 Velero CLI每个 GA 版本都需要更新 Homebrew 版本若没有现成的 Homebrew GitHub token先在 GitHub 创建一个具备gist与public_repo权限的 token导出环境变量export HOMEBREW_GITHUB_API_TOKENyour_token_here运行 hack/release-tools/brew-update.sh。从脚本源码可见其流程先检查本机是否安装了brew未安装则报错退出然后以https://github.com/vmware-tanzu/velero/archive/$VELERO_VERSION.tar.gz作为源码包 URL执行brew update确保 formula 最新最后调用brew bump-formula-pr velero --url$URL由 Homebrew 助手完成测试并自动打开创建 PR 的浏览器页面。Windows Chocolatey 版本更新在 Windows 机器上按照 Velero Chocolatey 包的说明创建 Windows Chocolatey 包并参照现有 Velero chocolatey 包安装脚本内容更新tools\chocolateyinstall.ps1文件。Velero Chocolatey 包目前由社区维护者 Adam Rush 维护若没有上传新版本的权限需联系其协助。插件发布Velero 团队维护的插件遵循独立的发布说明见同一文档目录下的 plugin release instructions 文档。插件镜像构建完成后务必同步更新 test/e2e 中使用这些插件的 e2e 测试避免测试与发布版本脱节。Helm Chart 发布仅 GAVelero 的 Helm Chart 托管在独立的 chart 仓库中GA 发布时需要同步完成根据当前 GA 版本更新 Helm Chart 的crds目录下的 CRD并为 Helm Chart 的 CRD 添加相应标签在Chart.yaml中升级 Chart 的version字段在Chart.yaml中升级 Velero 版本对应的appVersion并在values.yaml中升级镜像的tag如插件版本有变化在values.yaml中同步升级插件版本更新README.md中的升级说明upgrade指令及相关 tag。发布博客的写作与发布博客内容要点一篇合格的 Velero 发布博客应当包含感谢所有为本次发布做出贡献的贡献者尽量点名致谢也可以专门介绍新加入的维护者突出本次发布的主题或聚焦领域例如安全加固、bug 修复、特性改进等可参考过往发布博客总结本次发布引入的新特性或新工作流也可以涵盖项目层面的新倡议如行为准则更新若新特性较多可额外规划后续发布深入讲解的博客不必全部挤在同一篇里发布。博客 PR 与发布节奏创建包含发布博客的 PR通常直接复制最近一篇博客再替换内容最省事同时需要更新site/content/_index.md让 Latest Release Information 区域包含指向新博客的链接博客计划在发布当天发布。发布后的对外公告发布完成后通过以下渠道向社区同步消息仅 GA合并博客 PRVelero 官方 Twitter 账号发文鼓励维护者转发扩散社区 Slack 频道Google group 邮件列表。公告内容应包含感谢所有贡献者、简要列出本次发布亮点、附上发布博客 / release notes / GitHub release 页面的链接。结语Velero 的发布流程是一套文档即脚本、脚本即文档的工程实践本文档页与 hack/release-tools 目录下的tag-release.sh、chk_version.go、changelog.sh、gen-docs.sh、goreleaser.sh、brew-update.sh等脚本一一对应既有详尽的步骤说明又提供了可重复执行的工具链。对希望深入参与 Velero 维护、或借鉴其发布流水线设计的开发者来说对照本篇指南逐行阅读这些脚本是理解整个发布体系最直接有效的路径。【免费下载链接】veleroBackup and migrate Kubernetes applications and their persistent volumes项目地址: https://gitcode.com/GitHub_Trending/ve/velero创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Velero 版本发布全流程指南：从 RC 到 GA 的完整发布操作手册
Velero 版本发布全流程指南从 RC 到 GA 的完整发布操作手册【免费下载链接】veleroBackup and migrate Kubernetes applications and their persistent volumes项目地址: https://gitcode.com/GitHub_Trending/ve/velero本篇指南完整讲解 Velero 项目的版本发布流程从版本类型定义、发布候选RC与正式版GA的准入标准到 changelog 生成、文档版本化、tag-release.sh打标签发布、GoReleaser 构建 GitHub Release、Homebrew/Chocolatey 分发、插件与 Helm Chart 同步发布直至最终对外公告的每一个环节。读者读完本篇后可以对照仓库中的真实脚本如 hack/release-tools/tag-release.sh完整走通一次 Velero 的发布流程并理解每个步骤背后的设计与脚本实现细节。Velero 的版本类型与发布模型GA、Pre-release 与 RC 的定义Velero 的版本号遵循语义化版本SemVer规范官方文档给出了如下分类版本类型说明示例GAGeneral Availability正式发布版本仅包含 major 和 minor 版本1.0major、1.5minorPre-release预发布通往 GA 过程中的任何发布版本1.4.0-beta.1、1.5.0-rc.1RCRelease Candidate发布候选包含计划随 GA 发布的所有内容本身仍是预发布版本1.5.0-rc.1这一分类不是随意约定的而是被发布脚本严格强制校验的。仓库中的 hack/release-tools/chk_version.go 用一段正则表达式约束版本号格式var releaseRegex regexp.MustCompile(^v(?Pmajor[[:digit:]])\.(?Pminor[[:digit:]])\.(?Ppatch[[:digit:]])(-{1}(?Pprerelease(alpha|beta|rc)\.[[:digit:]]))*)该正则同时匹配 GA 格式如v1.4.3与预发布格式如v1.2.4-beta.2、v1.5.0-rc.1并通过命名捕获组解析出major、minor、patch、prerelease四个组成部分输出为 bash 可eval的环境变量VELERO_MAJOR、VELERO_MINOR、VELERO_PATCH、VELERO_PRERELEASE。也就是说版本号合法性在发布第一步就被脚本强制把关任何不符合上述格式的VELERO_VERSION都会导致脚本直接退出exit 1这正是发布流程可执行化设计的体现。Train leaves the station 发布模型Velero 采用火车离站train leaves the station式的时间驱动发布模型到达预定时间节点即生成一个 RC测试中发现 bug 就再生成新的 RC测试全部通过后才生成正式发布构建。这种模型强调按时发布优先而不是功能齐了才发布。发布准入标准RC 与 GA 的质量门槛Release Candidate 准入条件在进入 RC 阶段前候选 commit 必须满足没有遗留的重大 bugNo major bugs outstanding单元测试全部通过E2E 测试在最新版 Kubernetes 上的AWS、vSphere 和 kind环境通过一旦进入 RC 阶段即进入**代码冻结code freeze**状态此后只允许合并与发布相关的必要变更。仓库中对应的 e2e 测试代码位于 test/e2e 目录。GA 正式发布准入条件RC 想要转为正式发布还必须满足更高标准单元测试全部通过E2E 测试在Azure、vSphere、Kind、AWS、GCP五个平台上分别针对最新版 Kubernetes 与最早受支持的 Kubernetes 版本通过手动测试通过手动测试用例会逐步转化为自动化测试当上述任一环节发现 bug 时维护者会评估该 bug 是否为发布阻塞release blocker若是则修复后重新生成 RC 并重启整个测试周期。发布前的准备工作为 GA 版本撰写发布博客每个 major/minor 版本都需要创建并发布一篇博客向社区介绍新特性具体写作与发布指引见本文发布博客的写作要点一节。Changelog 与文档 PR这是整个准备工作中最繁琐、也是信息量最大的一步官方文档将其拆解为以下步骤创建版本化 changelog 文件在changelogs/目录下复制最近的 changelog 文件得到changelogs/CHANGELOG-major.minor.md如CHANGELOG-1.15.md仓库中已有 changelogs/CHANGELOG-1.15.md 等系列文件可作参照。生成未发布变更清单运行make changelog该命令实际调用 hack/release-tools/changelog.sh。脚本会遍历changelogs/unreleased目录仓库当前存有大量以PR号-贡献者名命名的未发布条目文件对每个文件解析出 PR 号与贡献者输出形如* 变更内容 (#PR号, 贡献者)的条目列表然后将输出粘贴到CHANGELOG-major.minor.md的 All Changes 一节下并更新文件顶部的版本链接。更新主 CHANGELOG编辑仓库根目录的 CHANGELOG.md保持结构规整——Current release 一节只保留当前 GA 版本Development release 一节只放最新的预发布版本并把之前的预发布移入 Older releases 列表。仓库当前 CHANGELOG.md 的现状就是该结构的实际样例。仅 GA清空未发布目录删除changelogs/unreleased下的所有条目文件。changelog.sh脚本末尾也提示执行git rm ${CHANGELOG_PATH}/*完成清理。生成版本化文档运行make gen-docs调用 hack/release-tools/gen-docs.sh传入合适的变量。官方给出两种示例预发布VELERO_VERSIONv1.5.0-rc.1 NEW_DOCS_VERSIONv1.5.0-rc.1 make gen-docsGAVELERO_VERSIONv1.5.0 NEW_DOCS_VERSIONv1.5 make gen-docs注意VELERO_VERSION与NEW_DOCS_VERSION的语义不同VELERO_VERSION是发布的具体版本同一 major.minor 下可能有v1.5.0、v1.5.1等多个小版本而NEW_DOCS_VERSION决定站点 URL 与版本下拉框里显示的名称例如 GA 后可以一直是v1.5。PREVIOUS_DOCS_VERSION为可选变量不设置时脚本会自动取site/content/docs/下字母序最后的目录作为对比基线。gen-docs.sh的内部逻辑非常值得细读它先把上一个版本化文档目录整体复制到新目录并git add建立 diff 基线再用main目录内容覆盖之对 ToC 文件site/data/docs/version-toc.yml同样先复制后覆盖随后通过sed将文档内指向main分支的版本化链接替换为$VELERO_VERSION并更新 site/config.yaml 的latest字段、版本列表以及 site/data/toc-mapping.yml 的映射条目。清理旧的预发布版本化文档如果目标版本已存在预发布版本化文档例如要发布v1.5.0-rc.1或v1.5但site/content/docs/v1.5.0-beta.1已存在需要依次删除site/content/docs/pre-release-version目录删除site/data/docs/pre-release-version-toc.yml从 site/data/toc-mapping.yml 移除对应映射从 site/config.yaml 移除该预发布版本的所有引用。创建/更新 Upgrade to $major.minor 页面若不存在则创建该升级指南页面main与已版本化目录都要做若已存在则把文件中旧的版本号字符串更新为新版本号。仓库中可参考site/content/docs/main下的既有升级文档。审查并提交 PR按 site/README-HUGO.md 的补充说明完成文档生成收尾审查 diff或运行make serve-docs本地预览站点效果最后提交包含 changelog 与版本化文档的 PR。排障提示执行make serve-docs时若遇到You dont have enough free space in /var/cache/apt/archives/错误运行docker system prune释放空间即可。固定基础镜像Pin the base image为保证发布可复现reproducibility在打 RC 标签之前需要确保发布分支上的 Dockerfile 中基础镜像通过digest而非 tag引用。Velero 镜像基于 Google 的 Distroless 镜像构建按 digest 固定引用可以防止基础镜像被重新推送后引入不确定性。执行 Velero 发布前置条件包含 changelog 与文档的 PR 必须已合并这样其内容才会进入发布标签对应的 commit。该流程对预发布与 GA 同样适用。仓库已配置名为upstream的远程仓库可用git remote -v检查tag-release.sh 默认使用upstream可通过环境变量REMOTE覆盖。理解 tag-release.sh 的核心逻辑发布的核心脚本是 hack/release-tools/tag-release.sh。从源码看它按顺序完成以下动作参数与环境检查脚本开头set -eo pipefail保证任何一步失败即中断。它要求VELERO_VERSION与GITHUB_TOKEN必须已设置否则打印提示并 exit 1并检查工作区必须干净git status --short为空否则 exit 3避免误把未提交内容带入发布。版本校验与解析先执行go run $DIR/chk_version.go --verify校验版本格式失败 exit 2再执行eval $(go run $DIR/chk_version.go)解析出版本组件。发布类型判断根据解析结果自动判断VELERO_PATCH ! 0→ 判定为patch 发布如v1.9.1自动假设标签打在 release 分支上无VELERO_PRERELEASE→ 判定为GA 发布同样假设打在 release 分支上有VELERO_PRERELEASE→ 判定为pre-release。交互确认脚本会打印基于版本字符串做出的全部假设是否为 patch/pre-release/GA、标签应落在哪个分支并等待回车确认按ctrl-c可随时取消。拉取并切换分支git fetch $remote --tags后若是发布分支场景release-$major.$minor会检查远端分支是否存在不存在则报错退出并 checkout 本地分支或跟踪远端分支否则 checkout$remote/main。打标签并推送tag_and_push()执行git tag $VELERO_VERSION仅当以publish参数调用时才执行git push $remote $VELERO_VERSION。调用 GoReleaser以RELEASE_NOTES_FILEchangelogs/CHANGELOG-$VELERO_MAJOR.$VELERO_MINOR.md和PUBLISH$publish运行make release构建发布产物并可选生成 GitHub release。干跑清理dry-run 模式下publishFALSE脚本在结束后切回原分支并删除本地标签git tag -d $VELERO_VERSION保证正式发布时不会与残留标签冲突。分步发布操作在 GitHub 上手动创建 release 分支命名形如release-$major.$minor例如release-1.9。干跑dry-run打标签——不会向 GitHub 推送任何内容VELERO_VERSIONv1.9.0-rc.1 REMOTEupstream-remote GITHUB_TOKENREDACTED ON_RELEASE_BRANCHTRUE ./hack/release-tools/tag-release.sh发现任何问题先在此阶段修复。排障提示如果 dry-run 出现随机错误可以重跑一次。正式打标签并推送VELERO_VERSIONv1.9.0-rc.1 REMOTEupstream-remote GITHUB_TOKENREDACTED ON_RELEASE_BRANCHTRUE ./hack/release-tools/tag-release.sh publish此时脚本才会把标签推送到远端并由 GoReleaser 生成 draft 状态的 GitHub release。发布 GitHub Release在仓库 Releases 页面编辑该 draft release需要注意若是patch 发布如v1.9.1CHANGELOG-1.9.md的完整内容会进入 release 正文必须删除上一版本如v1.9.0的 changelog 内容只保留最新 patch 版本的部分快速检查格式GoReleaser 会自动为预发布版本勾选 pre-release 复选框但建议人工二次确认确认 GitHub Actions 已构建并推送全部镜像需要一段时间确认镜像出现在 Docker Hub 的velero/velerotags 页面确认发布产物assets已上传最后点击发布。测试发布产物此时 Docker 镜像应已公开做一次 smoke test从 GitHub release 下载 CLI用它安装 Velero 到集群或手动把现有 deployment 更新到新镜像验证velero version输出符合预期执行一次 backup/restore确认功能正常。make release目标背后的实现也值得了解它会进入构建容器执行 hack/release-tools/goreleaser.sh。该脚本强制要求GITHUB_TOKEN、RELEASE_NOTES_FILE、REGISTRY三个变量先执行goreleaser check校验 .goreleaser.yml 配置格式PUBLISH非TRUE时以--snapshot模式生成本地快照不发布任何产物为TRUE时才真正执行goreleaser release生成 draft release。这一设计确保了本地验证与真正发布通过一个开关严格隔离。Homebrew 发布仅 GA为方便 macOS 用户通过 Homebrew 安装 Velero CLI每个 GA 版本都需要更新 Homebrew 版本若没有现成的 Homebrew GitHub token先在 GitHub 创建一个具备gist与public_repo权限的 token导出环境变量export HOMEBREW_GITHUB_API_TOKENyour_token_here运行 hack/release-tools/brew-update.sh。从脚本源码可见其流程先检查本机是否安装了brew未安装则报错退出然后以https://github.com/vmware-tanzu/velero/archive/$VELERO_VERSION.tar.gz作为源码包 URL执行brew update确保 formula 最新最后调用brew bump-formula-pr velero --url$URL由 Homebrew 助手完成测试并自动打开创建 PR 的浏览器页面。Windows Chocolatey 版本更新在 Windows 机器上按照 Velero Chocolatey 包的说明创建 Windows Chocolatey 包并参照现有 Velero chocolatey 包安装脚本内容更新tools\chocolateyinstall.ps1文件。Velero Chocolatey 包目前由社区维护者 Adam Rush 维护若没有上传新版本的权限需联系其协助。插件发布Velero 团队维护的插件遵循独立的发布说明见同一文档目录下的 plugin release instructions 文档。插件镜像构建完成后务必同步更新 test/e2e 中使用这些插件的 e2e 测试避免测试与发布版本脱节。Helm Chart 发布仅 GAVelero 的 Helm Chart 托管在独立的 chart 仓库中GA 发布时需要同步完成根据当前 GA 版本更新 Helm Chart 的crds目录下的 CRD并为 Helm Chart 的 CRD 添加相应标签在Chart.yaml中升级 Chart 的version字段在Chart.yaml中升级 Velero 版本对应的appVersion并在values.yaml中升级镜像的tag如插件版本有变化在values.yaml中同步升级插件版本更新README.md中的升级说明upgrade指令及相关 tag。发布博客的写作与发布博客内容要点一篇合格的 Velero 发布博客应当包含感谢所有为本次发布做出贡献的贡献者尽量点名致谢也可以专门介绍新加入的维护者突出本次发布的主题或聚焦领域例如安全加固、bug 修复、特性改进等可参考过往发布博客总结本次发布引入的新特性或新工作流也可以涵盖项目层面的新倡议如行为准则更新若新特性较多可额外规划后续发布深入讲解的博客不必全部挤在同一篇里发布。博客 PR 与发布节奏创建包含发布博客的 PR通常直接复制最近一篇博客再替换内容最省事同时需要更新site/content/_index.md让 Latest Release Information 区域包含指向新博客的链接博客计划在发布当天发布。发布后的对外公告发布完成后通过以下渠道向社区同步消息仅 GA合并博客 PRVelero 官方 Twitter 账号发文鼓励维护者转发扩散社区 Slack 频道Google group 邮件列表。公告内容应包含感谢所有贡献者、简要列出本次发布亮点、附上发布博客 / release notes / GitHub release 页面的链接。结语Velero 的发布流程是一套文档即脚本、脚本即文档的工程实践本文档页与 hack/release-tools 目录下的tag-release.sh、chk_version.go、changelog.sh、gen-docs.sh、goreleaser.sh、brew-update.sh等脚本一一对应既有详尽的步骤说明又提供了可重复执行的工具链。对希望深入参与 Velero 维护、或借鉴其发布流水线设计的开发者来说对照本篇指南逐行阅读这些脚本是理解整个发布体系最直接有效的路径。【免费下载链接】veleroBackup and migrate Kubernetes applications and their persistent volumes项目地址: https://gitcode.com/GitHub_Trending/ve/velero创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考