同一个镜像推 3 遍到 3 套环境？CI/CD 制品晋升流水线的分层设计与 4 个生产决策
概述 你大概率见过这种发布流程：开发同学构建一个 Docker 镜像，打上 dev 标签推到开发仓库；测试通过后，重新打 staging 标签再推一遍；最后上线时，又打 prod 标签推第三次。同一个镜像，构建一次，推送三次，标签换了三个。 这看起来没什么问题——直到有一天，你发现 staging 环境验证的镜像和 prod 环境运行的镜像根本不是同一个。 制品晋升（Artifact Promotion）解决的就是这个问题。核心思想很简单：镜像只构建一次，通过 digest（内容哈希）唯一标识，跨环境晋升时复制的是同一个不可变制品，而不是重新打标签。这听起来像是常识，但我在多个团队落地后发现，真正把这条流水线跑通的团队不到三成。原因不是技术多复杂，而是涉及仓库架构、权限模型、安全门禁、回滚策略等多层决策，每层都有坑。 这篇文章拆解制品晋升流水线的分层设计，结合我在某新能源物流平台 120+ 微服务 K8s 迁移中落地的晋升管道，聊 4 个关键生产决策和踩过的坑。 制品晋升到底是什么 先说清楚概念。很多团队把"制品晋升"和"重新打标签"混为一谈，这是第一个误区。 重新打标签的做法： # 构建一次 docker build -t registry.company.com/app:dev-1.0.0 . docker push registry.company.com/app:dev-1.0.0 # "晋升"到 staging —— 重新 tag 再推 docker tag registry.company.com/app:dev-1.0.0 registry.company.com/app:staging-1.0.0 docker push registry.company.com/app:staging-1.0.0 # "晋升"到 prod —— 又 tag 又推 docker tag registry.company.com/app:staging-1.0.0 registry.company.com/app:prod-1.0.0 docker push registry.company.com/app:prod-1.0.0 这有什么问题？表面上三次推送的都是同一个镜像 ID，但 docker tag 只是在仓库里创建了一个新的标签引用。标签是可变的——有人可以在你不知情的情况下覆盖 staging-1....