如何在Azure DevOps Pipelines中实现兼容经典发布流程的多阶段部署调度

你遇到的不是多阶段流水线的能力边界问题，是没有用到多阶段流水线自带的阶段级独立触发配置能力，完全不需要拆分成多条独立流水线，就能覆盖你提到的所有经典流水线的特性。

对应你现有发布链路的配置逻辑 #

你原有的经典流水线发布链路为：

1) Development - 构建成功后自动触发部署
2) Test - 每日0:30定时部署，支持白天随时手动部署
3) UAT - 夜间自动承接Test环境完成自动化测试的版本，支持灵活手动部署
4) Staging - 手动审批门禁
5) Production - 手动审批门禁

每个阶段匹配对应的配置规则即可：

• Development阶段：直接配置为与构建流水线联动，构建成功后自动触发部署，这部分你已经实现，无需调整。
• Test阶段：
  • 关掉默认的「前置阶段完成后自动部署」开关，避免Development部署完立刻推到Test，打乱夜间批量发布的节奏
  • 开启阶段级的计划触发，配置定时规则为每日凌晨0:30，调度时自动拉取Development环境最近一次成功部署的版本触发部署
  • 保留阶段的手动触发权限，白天有紧急变更时，可以直接在流水线运行详情页手动选择Test阶段部署，和之前经典流水线的手动推送体验完全一致
• UAT阶段：
  • 同样关掉「Test阶段完成后自动部署」的默认规则，给Test环境预留数小时的自动化测试运行窗口，避免刚部署完就直接推UAT
  • 开启阶段级的计划触发，根据自动化测试的实际运行时长（比如Test环境凌晨0:30部署、自动化测试跑3小时），配置对应的凌晨定时规则，测试跑完自动拉取Test环境的当前版本部署到UAT
  • 保留手动触发权限，紧急变更时可以跳过Test环节直接手动推UAT
• Staging、Production阶段：直接在阶段的前置条件里配置手动审批门禁，选「所有审批人通过后才允许执行部署」的规则就行，和你当前的使用体验没有差别。

特殊场景的实现方式 #

• 「跳过指定阶段部署」：手动触发流水线时，在运行配置面板里直接选要部署到的最高目标阶段，系统会自动跳过没选中的前置阶段，不需要额外写逻辑
• 「上一阶段部分成功也允许部署」：把对应阶段的运行前置条件从默认的succeeded()改成succeededOrFailed()，就能在前置阶段存在非阻塞失败的情况下继续执行部署，不会被流程卡住
• 全链路状态追溯：所有阶段都在同一条多阶段流水线内，单条运行记录会完整展示从Development到Production每一步的部署版本、审批记录、测试结果、运行耗时，不需要跨多个独立流水线拼接发布状态，完全符合多阶段流水线的设计原则。

常见配置误区 #

不少人会把多阶段流水线的触发规则当成全局统一的，实际上Azure DevOps早就支持为每一个独立阶段配置专属的计划触发、手动触发规则，根本不需要因为要给某一阶段单独设定时调度就拆成独立流水线。

内容的提问来源于stack exchange，提问作者Erik P. Ernst