发布#
注意
本文档仅供发布团队使用。请随意跳过。
此流程概述了为 AIBrix Github 项目创建和发布版本所需的步骤。请遵循这些步骤，以确保发布周期的顺利和一致。
准备代码#
选项 1 RC 版本发布#
对于像 v0.4.0-rc.2 这样的 RC 版本发布，无需检出新分支，我们直接针对 main 分支进行标签和发布。
选项 2 次版本发布#
对于像 v0.3.0 这样的新次版本发布，请检出一个名为 release-0.3 的新分支。
git checkout main && git fetch upstream main && git rebase upstream/main
git checkout -b release-0.1 # cut from main branch
git push origin release-0.1
注意
这里我们假设 origin 指向上游，如果不是，则像 upstream 这样的其他远程应该是正确的推送远程。
选项 3：补丁版本发布#
Bug 修复应首先合并到 main 中。然后将 bug 修复 cherry-pick 到目标发布分支，例如 release-0.3。但是，由于冲突，修复可能无法 cherry-pick 到 release-0.3。如果是这种情况，直接向发布分支提交 PR。对于像 v0.3.1 这样的补丁版本，请重用发布分支 release-0.3，它应该在次版本发布时已创建。对于补丁发布，我们不 rebase main，因为它会引入新功能。所有修复都必须直接 cherry-pick 或提交 PR 到 release-0.3。
针对 RC 版本发布进行性能回归测试#
test/regression/ 目录包含用于发布测试的基准配置
v0.2.1/：性能基准
v0.3.0/：KV 缓存变体
v0.4.0/：基于 Helm 的 SGLang/VLLM 测试模板
每次发布前，使用 test/regression/vX.Y.Z/ 中的配置运行性能基准测试。
注意
建议为每个版本构建特定的测试用例，因为关注点不同。保持测试用例与最新版本同步也很重要，这样我们也可以针对新版本使用以前的测试用例。
发布新版本#
确保清单镜像标签已更新且 Python 版本已更新。一个示例 PR 是 Cut v0.4.0-rc.2 release。合并 PR。
注意
容器镜像实际上尚未构建，我们保留标签名称，它将在标签创建后构建。
创建标签并推送到远程#
用于 RC 发布
# make sure you fetch the earlier PR locally
git fetch upstream main
git rebase upstream/main
# create the tag
git tag v0.4.0-rc.2
# push the tag
git push upstream v0.4.0-rc.2
用于官方发布
# make sure you fetch the earlier PR locally
git fetch upstream release-0.4
git rebase upstream/release-0.4
# create the tag
git tag v0.4.0
# push the tag
git push upstream v0.4.0
监控发布管道#
推送标签后，发布管道（例如 CI/CD 工作流）应自动开始。这可能包括： - 运行测试和验证 - 构建清单工件 - 构建容器镜像并推送到注册表 - 构建 Python 库并上传到 PyPI
监控管道的进度，确保其成功完成
在 Github 上发布版本#
发布管道将在 Github Releases 中创建一个草稿预发布版本。转到仓库中的“Releases”部分，选择与您创建的标签对应的草稿发布版本。包含发布说明，总结更改（新功能、错误修复、重大更改等）。可以选择附加二进制文件、文档或其他资产。最后，让我们发布版本。
将镜像同步到火山引擎容器注册表#
目前，发布管道仅将镜像推送到 dockerhub。为了在 VKE 中使用它们，我们需要重新标记镜像并推送到 VKE 容器注册表。
注意
这要求您使用一台同时拥有 VKE 和 Dockerhub 访问权限的机器。在推送之前，不要忘记获取临时凭据并登录注册表服务。
./hack/release/sync-images.sh v0.3.0 aibrix-container-registry-cn-beijing.cr.volces.com
./hack/release/sync-images.sh v0.3.0 aibrix-container-registry-cn-shanghai.cr.volces.com