VSTS：如何触发包含多个Release Definition的部署

当然可以解决这个逐个手动部署的繁琐问题！下面给你几个Azure DevOps生态里实用的方案，按需选择就行：

方案1：用YAML Pipeline串联所有Release #

这是最直观的可视化方案，不用写复杂脚本：

• 新建一个空白YAML Pipeline，专门作为你的"全局触发入口"。
• 给每个Release Definition添加一个AzureRelease任务，配置好对应的Release ID、目标环境和Azure订阅连接。
• 示例YAML片段：

steps:
# 第一个Release Definition的触发任务
- task: AzureRelease@1
  inputs:
    azureSubscription: '你的Azure服务连接名'
    definitionId: '123' # 替换成你的Release ID
    releaseName: 'Global-Deploy-$(Build.BuildId)'
    environmentName: '目标环境名称'

# 第二个Release Definition的触发任务
- task: AzureRelease@1
  inputs:
    azureSubscription: '你的Azure服务连接名'
    definitionId: '456' # 替换成你的Release ID
    releaseName: 'Global-Deploy-$(Build.BuildId)'
    environmentName: '目标环境名称'

# 依次添加剩下18个Release的任务即可

• 保存后，只要手动触发这个Pipeline，就能一次性启动所有20个Release的部署，还能在Pipeline页面统一查看所有部署的进度和状态。

方案2：用REST API写脚本批量触发 #

如果觉得维护20个Pipeline任务太麻烦，写个简单脚本更高效：

• 用PowerShell或Bash调用Azure DevOps的Releases - Create API，批量触发所有Release。
• 示例PowerShell脚本：

# 配置基础参数
$orgUrl = "https://dev.azure.com/你的组织名称"
$projectName = "你的项目名称"
$patToken = "你的PAT令牌" # 需要拥有Release管理权限
$targetEnvironment = "目标环境名称"
$releaseDefIds = @(123, 456, 789, ...) # 填入20个Release Definition的ID数组

# 转换PAT为API认证需要的Base64格式
$base64Auth = [Convert]::ToBase64String([Text.Encoding]::ASCII.GetBytes(":$patToken"))

# 循环触发每个Release
foreach ($defId in $releaseDefIds) {
    $requestBody = @{
        definitionId = $defId
        environments = @(@{name = $targetEnvironment})
        releaseName = "Global-Deploy-$(Get-Date -Format 'yyyyMMddHHmmss')"
    } | ConvertTo-Json -Depth 10

    $apiUri = "$orgUrl/$projectName/_apis/release/releases?api-version=7.1-preview.8"
    Invoke-RestMethod -Uri $apiUri -Method Post -Body $requestBody -ContentType "application/json" -Headers @{Authorization=("Basic {0}" -f $base64Auth)}
    Write-Host "已成功触发Release ID: $defId 的部署"
}

• 你可以把这个脚本在本地运行，或者放到Azure DevOps的Pipeline里作为一个"触发任务"，一键执行就能搞定所有部署。

方案3：利用Release依赖串联（适合有部署顺序的场景） #

如果这20个Release之间有明确的先后部署顺序（比如A部署完成后才能部署B），可以用Release的内置依赖功能：

• 在每个Release Definition的目标环境设置里，添加部署完成后触发另一个Release的触发器。
• 或者在Release的前置条件里，指定必须等待某个其他Release的环境部署完成才能启动。
• 不过这个方案更适合有依赖链的场景，如果只是单纯批量无顺序部署，前两个方案会更直接高效。

小提示 #

• 不管用哪种方案，建议先在测试环境拿2-3个Release做验证，确保参数配置正确再批量操作。
• 后续如果新增Release Definition，只需要在YAML或脚本里添加对应的ID就行，维护成本很低。

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