如何在Azure YAML管道中复用指定历史构建产物实现多环境部署

Azure YAML管道完全支持复用历史构建产物的跨环境部署需求，原生提供机制保障“一次构建、逐环境部署、全程不重复编译”的流程落地，从根源上避免因为主分支代码迭代导致部署基线和已验证版本不一致的问题。

整个方案的核心是把构建逻辑和部署逻辑从管道结构上完全解耦，不让任何部署环节关联重新构建的触发点，具体操作分为3个核心步骤：

• 构建逻辑全量前置，仅在流水线最开头执行一次
  在管道最顶端定义独立的构建stage，仅完成代码拉取、依赖安装、编译、单元测试、产物打包全流程；流程完成后通过内置的PublishPipelineArtifact任务，把打包完成的产物上传到Azure管道的托管制品存储中，这部分逻辑全程只会在流水线启动时跑一次，后续所有环节都不会重复执行。
• 所有环境部署环节统一拉取已上传的制品，绝对不触发构建逻辑
  dev、integration、staging slot、生产环境的每一个部署stage/job，开头都通过内置的DownloadPipelineArtifact任务，指定拉取来源为当前流水线运行时上传的同一份制品；整个部署环节只做环境配置、文件上传、服务启动这类部署动作，完全不执行拉取最新源码、安装依赖、编译打包这类构建操作。
• 补充历史制品复用能力，支撑跨版本回溯部署
  针对“某次dev验证通过的版本，间隔数天直接推到后续环境”的场景，给DownloadPipelineArtifact任务配置历史制品拉取规则：任务支持指定拉取某一次历史流水线运行产生的制品，不需要每次部署都等最新代码构建完成。只需要把部署阶段的制品拉取来源，指向之前dev验证通过的那次历史运行的制品ID，就能直接复用已验证的产物完成后续环境部署，全程不会产生新的构建流程。

• 不要在部署类job里配置默认的源码checkout步骤，一旦引入checkout逻辑，遇到主分支有新提交时就会自动拉取最新代码触发重新构建，直接打破版本一致性。
• 多job并行部署多环境/多slot时，要确保所有job的制品拉取配置指向同一个制品来源，避免出现不同环境拉取不同构建版本产物的错配问题。
• 不要在部署阶段引入任何依赖实时代码状态的编译命令，所有需要在部署环节生成的文件，都应该在最开头的构建阶段提前打包完成，和产物一起上传、一起部署。

内容的提问来源于stack exchange，提问作者Auto geek