我们在 Azure DevOps 中有一个 CI/CD 设置，它通过主分支上的推送触发。是否可以使批准者成为导致构建触发器的用户？
这背后的想法是，我们的团队中有很多开发人员，所以我希望推动更改的特定开发人员决定他们是否要部署更改，而不是专门的审批者。
【问题讨论】：
标签： azure continuous-integration azure-devops continuous-deployment
简短的回答，不。
上下文： 这与良好做法相反，这就是为什么有一个选项要求其他 人作为批准者，而不是做出更改的人。您不希望做出更改的人是批准它的人，因为这样可以让一个人偷偷进行更改。这意味着错误可能会漏掉，甚至是故意的恶意更改。
最佳做法是要求进行更改的人以外的其他人审核和批准更改。
【讨论】：
虽然我完全同意@Daniel Mann 关于为什么不应该这样做的观点，但我看到它发生的方式是团队被指定为批准请求的接收者，并且 user requesting a release or deployment should not approve it 复选框保持未选中状态.
然后，为了避免审批请求的收件箱噪音，请关闭团队关于等待发布审批的通知。
编辑
如果您必须只指定一个人作为有效用户来批准部署更改，您也可以这样做，但它不会很漂亮。你可以每人有一个“舞台”。这些阶段将在预部署条件中使用工件过滤器，以仅向该阶段所针对的人发送批准电子邮件。
批准后，它会转发到实际部署阶段进行工作。
现在您需要在构建中添加用户名或其他内容作为标签。我不确定是否有工具/任务可以作为构建管道的一部分来保持它的连续性，但我知道你可以从 REST api 弄清楚如何做到这一点。也许您需要创建一个运行 PS 脚本以访问 REST api 并使用构建上的 requestedBy 属性值标记提供的构建的预批准阶段。
再一次，看看做到这一点有多难？这可能意味着您没有遵循最佳实践。 “让正确的事情变得容易，让错误的事情变得困难。” -未知
【讨论】：