Azure DevOps多管道同环境部署如何避免状态检查无限循环

你当前的判断逻辑仅通过接口返回的count>0判定存在运行中部署，没有排除当前管道自身触发的运行记录——检查任务运行时生成的inProgress状态记录会被当成“其他管道的部署任务”，自然会触发无限等待的死循环。

• 先获取当前管道运行的唯一标识
  在执行检查逻辑前，先从Azure DevOps的系统预置变量里拿到两个核心值：当前管道的definitionId、当前发布的releaseId，作为后续排除自身记录的依据。如果你的检查任务是部署流程内的第一个步骤，此时还未生成正式部署的deploymentId，用releaseId做排除标识完全足够。
• 调整判断逻辑，过滤自身记录后再做校验
  不要直接用返回结果的count字段做判断，要遍历接口返回的所有inProgress状态的部署条目：
  • 若条目的definitionId和当前管道ID不一致，属于其他管道的运行记录，计入待等待的任务
  • 若条目的definitionId和当前管道ID一致，但releaseId和当前发布ID不一致，属于当前管道之前卡住的旧运行记录，也计入待等待的任务
  • 剩下的就是当前这次发布自己生成的检查阶段记录，直接排除不计入
    过滤完成后如果剩余条目数大于0，说明确实有其他部署在占用环境，等待固定间隔（比如30秒）后重新查询；如果剩余条目数为0，直接启动正式部署即可。
• 可选优化：减少无效接口调用
  你现在分别调用3次接口查固定3个管道的运行状态，其实可以去掉definitionId参数，加上目标环境ID做过滤，一次查询所有部署到同个环境的inProgress记录，后续新增同环境的管道也不用修改检查逻辑，示例接口：

  https://vsrm.dev.azure.com/ABC/DEF/_apis/release/deployments?deploymentStatus=inProgress&targetEnvironmentId=<你的目标环境ID>
  

// 从系统变量获取当前运行标识
currentDefId = process.env.RELEASE_DEFINITIONID
currentReleaseId = process.env.RELEASE_RELEASEID

// 轮询检查逻辑
async function checkCanDeploy() {
  const res = await fetch(apiUrl)
  const allInProgress = res.value
  // 过滤掉自身记录
  const blockingDeployments = allInProgress.filter(item => {
    if(item.definition.id != currentDefId) return true
    if(item.release.id != currentReleaseId) return true
    return false
  })

  if(blockingDeployments.length > 0) {
    // 有其他占用，等待后重试
    await new Promise(resolve => setTimeout(resolve, 30000))
    return checkCanDeploy()
  }
  // 无占用，开始部署
  return startDeploy()
}

注意：如果你的检查逻辑是在部署阶段外的独立校验任务里运行，要确保拿到的releaseId是当前正在执行的发布实例ID，不要拿成定义ID，避免排除逻辑失效。

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