流水线 - tag - 沐木https://oldletter.cn/tags/%E6%B5%81%E6%B0%B4%E7%BA%BF/流水线 - tag - 沐木Hugo -- gohugo.iozh-cnThu, 20 Jun 2024 00:00:00 +0000CI/CD 进阶：构建与发布分离，用 Release Manifest 管控生产发布https://oldletter.cn/posts/devops-02-build-once-deploy-many/Thu, 20 Jun 2024 00:00:00 +0000mumuhttps://oldletter.cn/posts/devops-02-build-once-deploy-many/

作者：林 | 系列：DevOps 实战 | 适合读者：后端/运维/DevOps 工程师

一、问题：你的生产发布靠什么保证"发的是测试通过的版本"？

很多团队的生产发布流程是这样的：

  1. 测试在测试环境验证通过
  2. 开发或运维在生产流水线里手动填一个 IMAGE_TAG
  3. 部署到生产

问题来了，这个 IMAGE_TAG 是谁填的？填的对不对？怎么证明测试环境用的就是这个 tag？

常见翻车场景：

  • 运维填错了 tag，把没测试过的版本发到生产
  • 测试验证的是 commit abc1234，但生产发的是 def5678
  • 出了问题想回滚，但不确定上一个稳定版本是哪个 tag
  • 多人协作时，谁发的、发了什么、什么时候发的，全靠聊天记录

核心矛盾：生产发布的"输入"没有约束，任何人都能填任何 tag。

二、解决方案：Release Manifest

2.1 核心思路

核心约束是一次构建、多环境部署，生产只提升已经验证的制品。

具体来说：

  1. dev/test 流水线负责构建镜像、推送 ACR、发布测试环境
  2. 测试环境发布成功后，生成一份 release-manifest.json（发布清单）
  3. 测试人员验证通过后，把 manifest 状态标记为 TEST_PASSED
  4. prod 流水线只接受一个输入：RELEASE_ID
  5. prod 流水线根据 RELEASE_ID 读取 manifest，只发布 manifest 里记录的镜像
flowchart TD Commit["代码提交"] --> Build["构建、测试并推送制品"] Build --> Manifest["生成发布清单"] Manifest --> Test["部署测试环境"] Test --> Verify{"验证通过"} Verify -- "否" --> Reject["终止该发布清单"] Verify -- "是" --> Approve["批准清单"] Approve --> Prod["按 RELEASE_ID 部署生产"] Prod --> Record["记录实际部署结果"]

关键约束：prod 不接受 IMAGE_TAG 输入，只接受 RELEASE_ID。镜像版本由 manifest 决定，不由人手填。

]]>