VSTS：在构建过期时自动重新绑定/合并并重新排队构建验证门

Question

我们最近对PR上的构建验证门进行了更改，以便在当前PR完成之前，如果另一个提交使其成为主分支，则构建将“立即”到期。请参阅here。

尽管此更改可确保主数据始终准确/可构建/健康，但这似乎对开发人员的工作效率几乎没有负面影响：

1. 团队成员必须不断关注他们的PR，以重新进行构建验证。
2. 他们不仅需要手动重新编队构建，而且在执行此操作之前，他们必须在重新排队之前手动重新分支他们的分支。
3. 随着我们朝着更加小巧/可运送的签到主人的方向前进，没有。这种情况预计会增加。

我想自动化（1）和（2）。有没有办法我可以设置VSTS构建验证，这样对于所有打开的PR，在构建到期时，它会自动使用master重新/重新合并源分支，然后重新排队构建？

Answer 1

我在组织中遇到了这个问题。当有多个PR试图进入同一时间时，设置Build expiration to Immediately会变得过于繁琐。

AFAIK - 每当master更新时，都无法自动触发定位master的所有PR的重建。如果您想要挂钩VSTS事件并自己编写代码，我确定基础知识存在。但是上次我看起来并没有开箱即用。

我的组织所做的是接受妥协。我们配置PR，以便构建在1小时后过期。这样，当多个PR同时尝试合并时，没有争用。但是，这有你在原始问题VSTS : Invalidating builds on existing PRs when another commit makes it into master branch中描述的缺点，因为两个不兼容的PR快速合并，目标分支（即master）可能会被破坏。 / p>

我们最终只是接受了这种限制

• 我们在所有分支（功能，master等）上都有一个触发器，每当添加新提交时，我们会自动触发新的构建。这样，如果PR设法中断master，我们会在几分钟内收到有关它的电子邮件。

• 如果主分支（即master）被破坏，则所有新PR将开始失败的构建。因此，没有新的PR可以合并。这通常会引起所有人的关注，因此问题很快就浮出水面 - 整个团队开始努力修复master。

• 在部署master之前，我们运行完整的VSTS构建，包括单元测试。这样，如果主分支被破坏（由两个不兼容的PR或任何其他原因），我们确保停止部署。

所以，不幸的是，我们无法保证 master始终处于良好状态的100％。达到100％只会对我们的工作流程和工作效率产生太大的负面影响。因此，我们接受了我们的限制，并确保尽快通知我们，并在分支中断时处理这种情况。