TFS迁移Git时monorepo发布分支如何触发对应应用流水线？

新建发布分支时的增量触发实现 #

完全可以实现你要的「仅触发上一发布后有变更的应用流水线」的需求，有两种常用的落地方案：

• 单流水线内置校验逻辑：给每个应用的流水线都配置匹配所有发布分支（比如分支规则设为release/*）的触发规则，同时在流水线第一步加入变更校验步骤：用git diff --name-only <上一个最新发布分支的标签/分支名> HEAD拿到两次发布之间所有变更的文件路径，校验当前应用对应的目录（比如/ApplicationA）是否在变更路径列表里，没有变更的话直接终止流水线并标记为跳过即可，不会消耗多余的构建资源。
• 全局触发调度：单独搭建一个全局发布调度流水线，仅响应发布分支的创建事件，该流水线统一计算两次发布之间的路径变更，筛选出所有有更新的应用列表后，再通过DevOps平台的内置API调用对应应用的UAT部署流水线即可，这种方案适合应用数量超过10个的场景，不用给每个应用的流水线重复写校验逻辑。

发布分支的选型建议 #

结合你当前的工作流和monorepo的场景，更推荐用每个版本单独创建的短期发布分支，只有需要同时维护多个并行迭代的长期支持版本（比如同时维护对外交付的v2.x和v3.x两个大版本的补丁）的时候，才需要用长期运行的发布分支，理由如下：

• 完全匹配你参考的官方分支策略逻辑，每个版本的边界清晰，对应版本的热修复可以直接在对应发布分支上提交，验证完成后再反向合入main分支，不会和其他版本的代码混淆，出问题排查也更容易。
• 如果用长期运行的固定名称发布分支（比如固定叫release），每次发布完成后需要同步main分支的最新代码，在多应用并行开发的monorepo场景下，代码冲突的概率会大幅提升，反而会增加发布阶段的工作量。
• 短期版本发布分支配合前面提到的变更校验逻辑，刚好可以在每次新建分支时自动对比上一个发布版本的差异，完美匹配你要的增量触发需求。

你可以先给发布分支统一设定命名规则，比如release/[主版本号].[次版本号]，流水线的分支触发规则直接用通配符匹配即可，不用每次新建发布分支都修改流水线配置。

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