对环境进行预部署批准是有意义的，但什么是部署后批准以及为什么我可以使用它？团队服务文档中没有定义here
答案 0 :(得分：5)
验证测试是我能想到的主要场景。想象一下部署链
Dev -> Test -> UAT -> Prod
所以我设置了一个触发器，在每次签入/提交时部署到dev并运行一些基本的冒烟测试。
然后我设置了一个预定的部署到测试3AM并运行一套更全面的自动化测试，但是应用程序的某些部分仍然依赖于手动测试。测试人员可以根据他们是否发现任何错误批准或拒绝部署后的发布。如果测试人员（或测试负责人）未批准部署后步骤，则该版本无法进入UAT。
然后，您可能拥有批准部署到UAT的业务用户，并且一旦测试完成，验证该版本可以上线。 （另一个部署后检查）
最后，您可能会检查批准部署到生产。
如果您在所有环境中都进行了100％的自动化测试，那么您就不需要这种手动干预，但是如果您仍然需要手动测试，那么这可以证明是一种相当轻量级的方法来确保合理的审批流程到位。
答案 1 :(得分：3)
不同的群体有时＆＃34;拥有＆＃34;不同的环境，因此它们可以控制事物何时部署到他们的环境以及什么时候准备离开他们的环境。我通常用来解释这个的场景如下：
您拥有开发人员拥有的开发服务器。变更被推到那里并由开发团队领导签署。开发团队负责人为＆＃34; Dev＆＃34;进行部署后批准。环境。
然后它进入QA环境。 QA团队可能正在对之前版本进行一些手动测试。他们希望得出结论，在下一次构建出现之前，QA团队负责人会获得部署前批准。开发人员可能会在过渡期间签署10个版本，但QA团队负责人可以选择只采用最新版本，因为测试旧版本并不能让任何人做任何好事。
然后，QA团队退出并进入UAT环境。 UAT由产品所有者拥有，产品所有者经常演示即将对上层管理人员和/或最终用户进行的更改。产品所有者希望控制UAT部署何时发生，因为他们不希望他们的演示被不合时宜的部署破坏。如果没有QA团队拥有的部署后批准，产品所有者可能会采用未经测试的未经验证的构建并进行部署，并最终演示可怕的内容，使每个人看起来都很糟糕。
等等。