我们的发布管道配置了多个阶段。对于合并到 master 的每个 pull request，都会自动创建一个新版本。我们有DEV => TST => REL => PRD.
现在，我们还使用这些阶段来执行自动化测试。所以在DEV之后有一个阶段来做一些基本的自动化测试（AT）。所以我们最终得到DEV => AT => TST => REL => PRD. AT 依赖于 DEV 才能正常运行。
我们的问题如下。当版本 X 正在执行 AT 并且同时合并拉取请求导致发布 X+1 部署到 DEV 时，这会导致版本 X 的 AT 失败。有没有办法让 Release X+1 在队列中等待，直到为 Release X 完成 AT？
我们也可以通过在部署期间避免 DEV 停机来解决这个问题，或者将测试隔离在不受自动部署等影响的环境中。但是根据我们所拥有的，以及我们可以用来改进它的时间，我们希望知道是否有办法让管道实例更加了解彼此......
但是根据我们所拥有的，以及我们可以用来改进这一点的时间，我们想知道是否有一种方法可以让管道实例更加了解彼此......
抱歉，恐怕我们目前还没有这种开箱即用的功能。
这是一个关于类似主题的讨论，您可以跟踪它并在那里发表评论以分享您的反馈。（因为那个是用于构建管道而不是用于发布，您可以发布发布管道的新功能请求）
作为临时解决方法：
您可以将 AT 阶段中的步骤移动到 DEV 阶段。创建代理作业AT并将 AT 阶段的内容移动到 DEV 阶段的 AT 作业中，并确保在Deployment queue settings下面禁用并行阶段部署Pre-deployment conditions：
此设置适用于阶段级别，但不适用于发布级别。所以它只有在你将 AT 阶段的内容移动到 DEV 阶段时才有效。（您也可能从这个类似的问题中得到提示）
在 Gates 中调用 azure devops rest api：
1.创建一个Generic service connection：
网址：https ://vsrm.dev.azure.com/OrgName/ProjectName/_apis/release/releases/3?api-version=5.1
将用户名和密码留空。
2.将默认"AuthToken": "$(system.AccessToken)"更改为"Authorization": "Bearer $(System.AccessToken)"。
然后其余的 api 将使用当前上下文中的令牌执行。
