指定分支Pull Request完成合并后触发YAML流水线下一阶段方案
靠多分支CI触发器切阶段的思路从机制上就行不通：Azure DevOps的CI触发器只要检测到分支收到新提交，就会拉起一个全新的流水线运行实例，每个实例启动时的Build.SourceBranch参数就固定了，不可能在一个已经启动的实例里挂起等待后续beta、main分支的合并事件再跑后续阶段。你之前给各阶段加分支判断条件，最后只会跑出三个独立实例各跑对应阶段的结果，改条件判断解决不了这个问题。
核心逻辑是只保留alpha分支作为唯一CI触发入口，砍掉beta、main分支的CI触发，从根源避免新实例生成，在同一个流水线实例里通过环境审批做手动测试卡点，审批通过后流水线自动完成指定提交的分支合并，再串接下游环境的构建部署，完全匹配你要的流程。
第一步：修改触发器配置
把beta、main从CI触发分支列表里排除，只留alpha作为唯一入口：
trigger: batch: true branches: include: - alpha exclude: - beta - main
第二步：调整流水线阶段结构
删掉所有阶段上绑定Build.SourceBranch的判断条件，把阶段按顺序串成固定流转链路：
- 阶段1：构建Alpha版本、部署到Alpha servers
- 卡点1：Alpha环境审批（对应Alpha手动测试环节）
- 步骤：自动将本次触发流水线的指定提交从alpha合并到beta分支
- 阶段2：构建Beta版本、部署到Beta servers
- 卡点2：Beta环境审批（对应Beta手动测试环节）
- 步骤：自动将本次流转的指定提交从beta合并到main分支
- 阶段3：构建生产版本、部署到Production servers
三个环境的构建直接复用同一份源码即可，不需要单独切beta、main分支拉代码——因为分支合并是流水线自动完成的，能100%保证三个环境部署的是同一份经过前序测试的代码，不会出现版本错配，还能省去重复构建的时间。
第三步：关键配置细节
- 配置环境审批卡点
在Azure DevOps的「环境」管理页，找到你已经创建的dev、beta、prod三个环境，进入「审批和检查」配置项，添加对应测试人员组为必填审批人。流水线部署到对应环境前会自动暂停，等测试人员完成手动验证、点击审批通过后才会往下走，正好匹配你的手动测试需求。 - 配置自动分支合并步骤
在Alpha审批通过后、Beta构建开始前，加命令行任务完成精确提交合并，用系统内置的AccessToken做认证就行，不需要额外配置个人访问令牌：
- task: CmdLine@2 displayName: 合并本次指定提交到beta分支 inputs: script: | git config user.name "Azure Pipeline Bot" git config user.email "pipeline@yourorg.com" git checkout beta git pull origin beta git merge $(Build.SourceVersion) --no-ff -m "Auto merge alpha commit $(Build.SourceVersion) for run $(Build.BuildId)" git push origin beta env: SYSTEM_ACCESSTOKEN: $(System.AccessToken)
这里用$(Build.SourceVersion)精确指定合并触发本次流水线的那一个提交，不会把alpha分支上其他未经过测试的提交带到beta，完全符合你“仅合并本次指定变更”的要求。
Beta审批通过后、生产构建开始前，加逻辑完全一致的合并步骤，把目标分支换成main即可。
3. 开通必要权限
给项目的「Project Collection Build Service」账号分配alpha、beta、main三个分支的贡献权限，允许流水线账号直接推送代码到分支，避免合并push时报权限错误。
兜底优化
如果需要防止有人直接往beta、main分支提交代码漏过发布流程，可以给这两个分支配置PR构建验证策略，不要加CI触发器：所有往beta、main分支提交的PR必须先过流水线构建校验，不会触发新的发布流程，不影响正常的单实例流转逻辑。
整个流程从PR合并到alpha分支启动后，后续的测试卡点、分支合并、多环境部署全部在同一个流水线实例内完成，不会产生额外的独立运行，你可以在同一个运行详情页看到全流程的日志、审批记录、关联的代码版本，不会出现之前三个实例各跑一段的问题。
内容的提问来源于stack exchange，提问作者T4under4
