Azure devops 在多回购CD管道中自动化部署前审批

抱歉发了这么长的邮件

我有一个Git多回购环境。每个回购协议代表一个项目。每个回购协议都有自己的CI和CD管道。从主题分支中提取请求合并代码以开发行。从develop分支触发CD，并使用新构建的工件更新DEV服务器。当开发人员在DEV上执行并验证他们的工作时，另一个服务器QA将使用相同的工件进行更新。这是CD管道的第二阶段

在定制的敏捷流程中，用户故事工作项类型的部分流程如下所示：

已部署->待审核->由QA审核

新添加的代码通过任务工作项提交和推送。因此，当任务处于关闭状态时，这意味着拉取请求完成，代码从主题分支合并到开发分支

任务是链接到用户情景的任务是子任务

例如，用户故事a链接到任务1和任务2。每个任务都与项目1和项目2相关

任务1的拉取请求完成后，将触发项目1的CI/CD，并将代码部署到开发服务器上。任务1的状态已关闭，但故事A的状态仍处于活动状态，因为任务2尚未关闭

任务2的拉取请求完成后，将触发项目2的CI/CD，并将代码部署到开发服务器上。由于任务1和任务2已关闭，任务2的状态已关闭，故事1的状态更改为已部署

上面的逻辑由我编写的PowerShell脚本处理，该脚本在每个项目的CD管道中执行。

我的问题是，在任务2完成后，如何为每个项目A和B触发CD管道的阶段QA部署？最简单的解决方案是在每个管道的每个QA阶段之前添加部署前批准，但这是一个漫长的手动过程，考虑到每天创建和完成数百个任务

提前感谢。

< P>可以考虑向QA阶段添加查询工作项部署门。

首先，您需要创建一个查询，如下图所示，以获取符合条件的任务

---

然后在Gate中选择此查询，并将下限阈值（查询中匹配工作项的最小数量）设置为2，这样，如果查询中关闭的任务数量为2，则执行部署到QA阶段。但是，在每次部署到QA阶段时，您需要修改查询中用户故事的ID，否则先前关闭的条目也会被查询，这将影响此部署。

我确实考虑过这一点，但是我手动修改查询中的ID是不可行的。此外，许多故事可能有两个以上的相关任务；这个数字是通用的。你认为有没有一种方法可以让这一切自动化？感谢您在问题中提到的，您每天需要执行数百次部署。无论您是通过脚本还是UI进行判断，都需要手动指定项目的ID。否则，以前成功执行的项目将影响此判断，因此此逻辑想要执行完全自动化应该是不可行的。我有一个新想法。在版本中，我们可以通过BUILD\u SOURCEVERSION环境变量获得相关的提交。根据此提交，我们可以使用RESTAPI跟踪与pull请求相关的任务，然后判断任务的状态。谢谢您的建议。我正在做一些类似于您建议的事情，但是我仍然找不到一种方法来自动化QA阶段的Approve部署。目的是在没有人工干预的情况下触发第二阶段QA。据我所知，在这种情况下，没有人工干预就触发第二阶段QA是不可行的。您可以在我们的网站上添加此功能的请求，该网站是我们提供产品建议的主要论坛。