Online Boutique 版本发布全流程指南从语义化版本号到生产部署的自动化实践【免费下载链接】microservices-demoSample cloud-first application with 10 microservices showcasing Kubernetes, Istio, and gRPC.项目地址: https://gitcode.com/GitHub_Trending/mi/microservices-demo导读本文基于 microservices-demoOnline Boutique官方发布流程文档完整梳理该项目从选择版本号、构建镜像、生成清单、打包 Helm Chart、打 git 标签、开 PR 评审、写 Release Notes 到更新生产环境的端到端发布链路。读者将掌握两种发布方式GitHub Actions 的 Manual Release Builder 工作流与本地make-release.sh脚本、发布产物在仓库中的落盘位置release/、kustomize/base/、helm-chart/以及发布后运维生产集群与更新 major tag 的标准操作并看到每个环节背后脚本的源码级实现细节。一、发布前准备版本号与本地工具链1.1 选择下一个版本号遵循语义化版本SemVerOnline Boutique 的每个正式版本都使用语义化版本号vX.Y.Z具体选择规则如下包含重要功能变更升级 minor 版本号Y例如从v0.10.6升到v0.11.0仅修 bug 或常规季度发布升级 patch 版本号Z例如从v0.10.6升到v0.10.7。从脚本的强校验逻辑看版本号格式是被强制约束的。make-release.sh 中有一段显式检查if [[ $TAG ! v* ]]; then fail \$TAG must start with v, e.g. v0.1.0 (got: $TAG) fi也就是说TAG环境变量必须以v开头v0.10.6这样的格式才能通过校验。当前仓库的 Chart.yaml 中appVersion: v0.10.6、version: 0.10.6正是这种规范的落地体现应用版本保留v前缀Helm Chart 版本则去掉v前缀。1.2 确保发布工具在 PATH 中开始发布前需要确保以下命令可用命令用途安装说明gsedGNU sed用于批量替换 YAML 中的镜像 tagmacOS 通过gnu-sedBrew 包安装Linux 可直接用sed或符号链接gcloud构建镜像、推送镜像、连接 GKE 集群Google Cloud SDK 自带helm打包并推送 Helm Chart官方 Helm 客户端其中gsed的可移植性值得注意make-release-artifacts.sh 中专门做了兼容处理在 Linux 上把gsed定义为sed的别名函数# define gsed as a function on Linux for compatibility [ $(uname -s) Linux ] gsed() { sed $ }1.3 认证 gcloud发布过程中需要向 Google Cloud 推送镜像与 Chart因此必须提前完成登录与 Docker 仓库认证gcloud auth login gcloud auth configure-docker us-central1-docker.pkg.dev第二条命令为us-central1-docker.pkg.dev区域的 Artifact Registry 配置 Docker 凭据这是后续gcloud builds submit与helm push能够成功的前提。二、创建发布分支与 PR推荐走 GitHub Actions 工作流2.1 触发 Manual Release Builder 工作流官方推荐的第一种方式是使用仓库内的Manual Release BuilderGitHub Actions 工作流操作步骤为打开仓库的Actions标签页在左侧边栏选择Manual Release Builder工作流点击Run workflow下拉按钮填写参数The release version (e.g., v0.3.5)填vX.Y.Z格式的版本字符串The repository prefix for container images默认us-central1-docker.pkg.dev/online-boutique-ci/microservices-demo即镜像最终推送到的 Artifact Registry 仓库地址The Google Cloud Project ID for the release CI默认online-boutique-ci点击Run workflow开始执行。该工作流会自动完成以下五件事构建并推送所有服务的容器镜像重新生成 YAML 清单与 Kustomize base打包并推送 Helm Chart创建并推送新分支release/vX.Y.Z与 git tagvX.Y.Z自动打开一个指向main的 PR并在 PR 中包含发布检查清单release checklist。2.2 备选方案本地执行 make-release.sh如果需要在本地手动执行整个发布流程在完成上文「1.2」「1.3」的前置准备后在仓库根目录运行# assuming you are inside the root path of the microservices-demo repository export TAGvX.Y.Z # This is the new version (e.g. v0.3.5) export REPO_PREFIXus-central1-docker.pkg.dev/online-boutique-ci/microservices-demo # This is the Docker repository for tagged images export PROJECT_IDonline-boutique-ci # This is the Google Cloud project for the release CI ./docs/releasing/make-release.sh脚本执行完毕后前往 GitHub 的分支列表页面手动创建一个指向main的 Pull Request。之后 CI 会触发多轮检查并将发布内容暂存到一个临时集群上进行验证。PR 被批准且所有检查通过后即可合并分支合并时务必在 PR 描述中附上发布草稿release draft方便评审者审阅变更内容。合并过程中不要删除 release 分支也不要删除相关 tag。make-release.sh 的源码执行顺序从 make-release.sh 的实现可以看出整个流程被严格编排为四个阶段set -euo pipefail保证任何一步失败都会立即中断TAG${TAG:?TAG env variable must be specified} REPO_PREFIX${REPO_PREFIX:?REPO_PREFIX env variable must be specified e.g. us-central1-docker.pkg.dev\/online-boutique-ci\/microservices-demo} PROJECT_ID${PROJECT_ID:?PROJECT_ID env variable must be specified e.g. online-boutique-ci}三个环境变量缺失时脚本会直接报错退出${VAR:?message}语法首先检查工作区是否有未提交的改动git status -s非空则拒绝执行避免把本地脏状态带入发布然后git checkout main git pull确保基于最新主干开始发布依次调用make-docker-images.sh—— 构建并推送所有镜像make-release-artifacts.sh—— 生成release/下的清单并更新kustomize/base/make-helm-chart.sh—— 打包并推送 Helm Chart最后创建release/${TAG}分支、提交允许空提交--allow-empty、打 tag、推送分支与 taggit checkout -b release/${TAG} git add ${REPO_ROOT}/release/ git add ${REPO_ROOT}/kustomize/base/ git add ${REPO_ROOT}/helm-chart/ git commit --allow-empty -m Release $TAG git tag $TAG git push --set-upstream origin release/${TAG} git push --tags注意git add的三个路径release/、kustomize/base/、helm-chart/正是本仓库中全部「发布产物」的所在位置这从侧面印证了这些目录是每次发布时会被自动更新、提交并随 tag 一起发布的内容。三、发布链路的三个核心脚本拆解3.1 make-docker-images.sh遍历 src 目录逐个构建镜像make-docker-images.sh 负责为每个微服务构建并推送 Docker 镜像核心逻辑是遍历src/下的每个服务目录while IFS read -d $\0 -r dir; do svcname$(basename ${dir}) builddir${dir} #PR 516 moved cartservice build artifacts one level down to src if [ $svcname cartservice ] then builddir${dir}/src fi image${REPO_PREFIX}/$svcname:$TAG ... done (find ${REPO_ROOT}/src -mindepth 1 -maxdepth 1 -type d -print0)几个值得注意的实现细节特殊处理 cartservice由于 cartservice 的构建产物Dockerfile 等位于 src/cartservice/src比其它服务多一层目录脚本为它单独把builddir指向${dir}/src使用 Cloud Build 异步构建通过gcloud builds submit --async提交构建任务并轮询状态直到SUCCESS才继续遇到FAILURE、INTERNAL_ERROR、TIMEOUT、CANCELLED任一状态则中止整个发布追加 sample 镜像 tag每个镜像在构建完成后还会通过gcloud artifacts docker tags add打上一个sample-public-image-${TAG}的额外 tag供公开示例部署引用。镜像命名规则统一为REPO_PREFIX/服务名:TAG例如 release/kubernetes-manifests.yaml 中 frontend 的镜像地址为image: us-central1-docker.pkg.dev/online-boutique-ci/microservices-demo/frontend:v0.10.63.2 make-release-artifacts.sh生成三份发布产物make-release-artifacts.sh 负责把「开发态」的清单加工成「发布态」的产物主要产出如下产物一release/kubernetes-manifests.yaml将 kubernetes-manifests 目录下除kustomization.yaml之外的所有 YAML 拼接每个文件之间插入---分隔符然后用gsed正则把每个服务的image:行替换成$REPO_PREFIX/$svcname:$TAG的发布镜像地址。文件开头会写入license 头来自 docs/releasing/license_header.txt「Autogenerated. Do not manually edit.」自动生成警告# [START gke_release_kubernetes_manifests_microservices_demo]/# [END ...]标记方便文档工具定位该代码段。生成的 release/kubernetes-manifests.yaml 是生产部署用的完整清单当前仓库中约 980 行包含全部 11 个服务的 Deployment、Service 等资源。产物二release/istio-manifests.yaml将 kustomize/components/service-mesh-istio 组件目录下的 YAML同样排除kustomization.yaml直接拼接生成供 Istio 服务网格部署场景使用。当前仓库的 release/istio-manifests.yaml 中可以看到 VirtualService、Gateway、HTTPRoute 等 Istio/Gateway API 资源。产物三更新 kustomize/base/把 kubernetes-manifests 下的每个服务 YAML 复制到 kustomize/base并做同样的镜像 tag 替换。有一个例外redis.yaml不替换镜像因为 redis 使用官方redis:alpine镜像不属于us-central1-docker.pkg.dev/online-boutique-ci/microservices-demo仓库。替换后的 kustomize/base/kustomization.yaml 引用 11 个服务清单构成可被上层环境直接使用的 Kustomize base。3.3 make-helm-chart.sh打包并推送 Helm Chartmake-helm-chart.sh 负责发布 Helm Chart它会先改写 helm-chart/Chart.yaml 中的两个版本字段再执行打包与推送gsed -i s/^appVersion:.*/appVersion: \${TAG}\/ Chart.yaml gsed -i s/^version:.*/version: ${TAG:1}/ Chart.yaml helm package . helm push onlineboutique-${TAG:1}.tgz oci://us-docker.pkg.dev/online-boutique-ci/charts rm ./onlineboutique-${TAG:1}.tgz要点说明版本字段的差异appVersion保留v前缀如v0.10.6而 Chart 的version通过${TAG:1}去掉v如0.10.6这正是 Chart.yaml 中appVersion: v0.10.6与version: 0.10.6并存的原因推送目标固定Chart 被helm push到 OCI 仓库us-docker.pkg.dev/online-boutique-ci/charts与镜像仓库位于不同区域打包完成后立即删除本地.tgz文件避免污染工作区。Helm Chart 的用户侧可配置项集中在 helm-chart/values.yaml例如images.repository默认即镜像仓库地址、images.tag留空时默认使用 Chart 的appVersion、serviceAccounts.create、networkPolicies.create等发布后用户可通过这些参数定制部署。四、发布 Notes为 tag 编写发布说明PR 合并完成后需要为新建的 git tag 创建 Release在仓库Tags页面找到最新 tag 所在行点击面包屑进入详情选择Create release选项在 release notes 中简要描述自上一个版本以来的变更如修复的 bug、新增的功能可参考历史 releases 的写法。注意无需上传任何 assets。发布产物镜像、清单、Chart都会在 tag 对应的修订版本上自动就绪不需要手动附加二进制附件。五、更新生产环境部署到 online-boutique-release 集群发布说明公开后需要将生产环境升级到新版本5.1 连接生产集群gcloud container clusters get-credentials online-boutique-release \ --zone us-central1-c --project online-boutique-ci5.2 应用发布清单kubectl apply -f ./release/kubernetes-manifests.yaml这里部署的正是make-release-artifacts.sh生成的、已注入新版本镜像 tag 的 release/kubernetes-manifests.yaml。5.3 删除不必要的对象生产环境拓扑与默认演示部署略有差异需要移除两个资源kubectl delete service frontend-external kubectl delete deployment loadgeneratorfrontend-externalService生产环境改用 Ingress / Gateway 暴露前端不再需要这个 LoadBalancer 类型的 Service其定义位于 kubernetes-manifests/frontend.yamlloadgeneratorDeployment生产环境不应运行压测流量发生器。5.4 验证访问生产站点确认新版本可用。从仓库的 README.md 描述看Online Boutique 生产站点的域名验证流程已集成在发布检查清单中运维人员应确认页面、商品浏览、购物车、结算等核心链路均正常。六、更新 major tag日常发布采用vX.Y.Z三段式 tag同时仓库还会维护一个浮动的major tag如v0、v1始终指向最新 release方便用户引用「最新版」。更新 major tag 的操作如下export MAJOR_TAGv0 # Edit this as needed (to v1/v2/v3/etc) git checkout release/${TAG} git pull git push --delete origin ${MAJOR_TAG} # Delete the remote tag (if it exists) git tag --delete ${MAJOR_TAG} # Delete the local tag (if it exists) git tag -a ${MAJOR_TAG} -m Updating ${MAJOR_TAG} to its most recent release: ${TAG} git push origin ${MAJOR_TAG} # Push the new tag to origin流程要点切到已发布的release/${TAG}分支 → 删除远端与本地旧 major tag → 用带注释-a的方式重新打 major tag 并推送。由于git push --delete会先删除远端 tag若该 major tag 已存在会被重建并指向最新版本。七、发布后的内部通告新版本发布完成后可在 Google Groupg/online-boutique-announce上发布内部通告同步版本内容、变更要点与升级注意事项完成整个发布流程的最后一环。八、发布流程全景回顾一次完整的 Online Boutique 发布可以概括为以下流水线选定 TAG (vX.Y.Z) ↓ Manual Release Builder (GitHub Actions) └─ 构建并推送全部容器镜像make-docker-images.sh 逻辑 └─ 生成 release/kubernetes-manifests.yaml、release/istio-manifests.yamlmake-release-artifacts.sh 逻辑 └─ 更新 kustomize/base/ 镜像 tag └─ 打包推送 Helm Chartmake-helm-chart.sh 逻辑 └─ 创建 release/vX.Y.Z 分支 打 vX.Y.Z tag 自动开 PR ↓ PR 评审与 CI 检查通过后合并勿删分支与 tag ↓ 为 tag 编写 Release Notes无需上传 assets ↓ 更新生产集群kubectl apply release/kubernetes-manifests.yaml删除 frontend-external 与 loadgenerator ↓ 更新 major tag如 v0→ 内部通告整个流程的自动化脚本均位于 docs/releasing 目录发布产物统一沉淀在 release、kustomize/base 与 helm-chart 三个目录中。理解这套「镜像构建 → 清单生成 → Chart 打包 → 分支与 tag 管理 → 生产部署」的链路即可将此模式复用到其它云原生微服务项目的版本管理实践中。【免费下载链接】microservices-demoSample cloud-first application with 10 microservices showcasing Kubernetes, Istio, and gRPC.项目地址: https://gitcode.com/GitHub_Trending/mi/microservices-demo创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考