Azure DevOps微服务单体仓库多流水线阶段串行执行配置咨询

需求是否可行？ #

可行，有两种常用实现方式：

方式1：配置流水线依赖触发 #

在每个子服务的流水线YAML中，设置依赖上游服务的完整流水线执行完成后再触发自身。以app2-pipeline.yml为例：

resources:
  pipelines:
  - pipeline: app1Pipeline
    source: 'app1流水线的名称'
    trigger:
      branches:
        include:
        - main # 替换成实际触发的分支

同理，app3-pipeline.yml中依赖app2的流水线。这样就能保证App1完整跑完两个阶段后，App2才开始执行，App2跑完再触发App3。

方式2：合并为单条主流水线 #

在仓库根目录创建一条主流水线，将每个服务的流水线作为模板引入，通过dependsOn让各服务的完整流程串行执行。示例main-pipeline.yml：

stages:
- stage: Run_App1
  jobs:
  - template: app1/app1-pipeline.yml@self
- stage: Run_App2
  dependsOn: Run_App1
  jobs:
  - template: app2/app2-pipeline.yml@self
- stage: Run_App3
  dependsOn: Run_App2
  jobs:
  - template: app3/app3-pipeline.yml@self

每个stage对应一个服务的完整流程，前一个stage执行完毕后才会启动下一个。

不推荐这么做的原因 #

• 整体执行时间大幅拉长：原本可以并行跑多个服务的构建阶段，现在串行后总耗时是三个流水线的耗时总和，而非耗时最长的单个流水线时间，效率严重下降。
• 故障影响范围扩大：只要其中一个服务的流水线执行失败，后续所有服务的流水线都会被阻断，而并行模式下单个服务失败不会影响其他服务。
• 资源利用率低下：Azure DevOps的运行器资源无法得到充分利用，原本可以同时处理多个任务，现在只能逐个执行，造成资源浪费。
• 维护成本上升：如果用依赖触发的方式，新增服务时需要修改多个流水线的依赖配置；如果用主流水线模式，主文件会随着服务数量增加变得臃肿，后续调整或新增服务都更麻烦。

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