Docker与Azure DevOps多阶段部署最佳实践咨询

首选方案：单次构建镜像，跨环境复用，部署阶段注入差异化配置。不推荐为DSV、HML、PRD每个环境单独构建镜像。

为什么不推荐每个环境单独构建镜像 #

• 破坏构建产物一致性：不同时间点单独构建的镜像，哪怕用的是同一份Dockerfile、同一份代码，也可能因为基础镜像补丁更新、依赖包版本漂移、构建时上下文差异，导致不同环境运行的实际产物不一致，很容易出现「测试环境全量验证通过，生产上线就出诡异问题」的情况，出问题之后也没法快速溯源定位是不是构建环节带来的差异。
• 增加不必要的成本：重复构建、重复推送镜像会拉长CI/CD流水线运行时间，额外占用Azure Container Registry的存储配额，环境越多浪费越明显。
• 提升配置泄露风险：如果每个环境单独构建，很容易出现把生产环境密钥、数据库地址这类敏感配置打包进测试环境镜像的情况，增加安全隐患。

单次构建多环境部署的落地路径（适配Azure生态） #

核心原则是：镜像内只包含不随环境变化的应用运行产物，所有环境相关的配置、密钥、连接串全部从镜像中剥离，在部署阶段动态注入。
实操步骤：

1. 构建环节仅执行一次
   • 配置Azure DevOps流水线的构建Job仅在代码合入主干、打版本Tag时触发一次，构建完成后给镜像打上唯一可溯源的标签（比如用Git提交短Hash、流水线构建ID，禁止用latest这类浮动标签），推送到Azure Container Registry留存。
   • 编写Dockerfile时不要COPY任何环境专属的配置文件进镜像，不要在构建步骤里写死任何环境相关的参数。
2. 分环境部署环节复用同一个镜像Tag，按需注入配置
   结合Azure的服务能力选合适的配置注入方式即可，不需要修改镜像内容：
   • 如果部署到Azure App Service/Container Apps：直接在对应环境的实例配置里加应用设置、连接字符串，容器启动时这些内容会自动以环境变量的形式注入到应用进程内，敏感值可以直接对接Azure Key Vault读取，不需要明文存。
   • 如果部署到AKS：把不同环境的配置存到Azure DevOps对应环境的变量组里，部署时动态替换K8s Deployment/ConfigMap/Secret清单里的占位符，所有环境的清单都引用同一个镜像Tag即可。
   • 配置量比较大的场景，可以直接对接Azure App Configuration服务，应用启动时根据当前部署环境的标识，拉取对应环境的配置项，连部署时的变量替换步骤都可以省略。
3. 配合Azure DevOps的环境门禁做流转：同一个镜像先自动部署到DSV环境，跑完单元测试、接口自动化测试之后，经审批流转到HML环境做集成、UAT测试，再经二次审批流转到PRD环境，全程镜像的内容、Hash完全不变，100%保证生产运行的产物就是前面所有环境验证通过的版本。

极少数需要单独构建镜像的场景 #

只有当不同环境的运行时内容存在本质差异时才需要单独构建，比如DSV环境需要内置调试工具、链路探针，PRD环境需要做极致裁剪移除所有调试依赖。这种场景也建议用同一个Dockerfile的多阶段构建能力产出不同变体，严格保证核心业务代码的构建产物完全一致，不要为每个环境单独维护构建逻辑。

内容的提问来源于stack exchange，提问作者thiago.adriano26