Azure devops 什么是团队服务发布定义'；部署后审批人'；？

对环境进行部署前批准是有意义的，但什么是部署后批准？我为什么要使用它？团队服务文档中没有定义验证测试是我能想到的主要场景。设想一个部署链

Dev->Test->UAT->Prod

所以我设置了一个触发器，在每次签入/提交时部署到dev，并运行一些基本的冒烟测试

然后，我设置了一个计划部署来测试3AM，并运行一组更全面的自动化测试，但是应用程序的某些部分仍然依赖于手动测试。测试人员可以根据是否发现任何bug来批准或拒绝发布后部署。如果测试人员（或测试负责人）不批准部署后步骤，则发布无法继续进行UAT

然后，您可能会有业务用户批准部署到UAT，并在测试完成后验证该版本是否可以上线。（另一项部署后检查）

最后，您可能会有一个批准部署到生产的检查

---

如果您在所有环境中都有100%的自动化测试，那么您就不需要这些手动干预，但是如果您仍然需要手动测试，那么这可以证明是一种相当轻量级的方法，可以确保合理的批准流程到位。

不同的组有时“拥有”不同的环境，因此，它们可以控制何时将内容部署到其环境中，以及何时准备好离开其环境。我通常使用以下场景来解释这一点：

您有一个由开发人员拥有的开发服务器。更改被推到那里，并由开发团队负责人签字。开发团队负责人对“开发”环境进行部署后批准

然后它进入QA环境。QA团队可能处于对先前构建的一些手动测试的中间。他们希望在下一次构建之前得出结论，因此QA团队负责人获得部署前批准。在此期间，开发人员可能会签署10个版本，但QA团队负责人可以选择只接受最新的版本，因为测试旧版本对任何人都没有好处

然后，QA团队签字并进入UAT环境。UAT归产品负责人所有，产品负责人经常向高层管理人员和/或最终用户演示即将发生的更改。产品负责人希望控制UAT部署的时间，因为他们不希望自己的演示被不恰当的部署破坏。如果没有QA团队拥有的部署后批准，产品负责人可能会采用一个未经测试、未经验证的构建并部署它，最终会演示一些严重损坏的东西，使每个人看起来都很糟糕

---

依此类推。

如果部署后审批人拒绝发布，环境是否重置为发布前状态？如果该版本中有一些迁移任务对数据库进行了更改，该怎么办？@muhammamoorkhan如果部署后审阅者拒绝该版本，则无法继续到管道中的下一个环境。版本已经部署到的环境不会发生任何变化。这些批准人步骤只是人工干预，以允许人员做出决策。