我们公司现在已经为 MS Windows 端聘请了一名全职发布工程师，我们正在考虑 MS SQL Server 的发布管理流程。
如果我们对他们部署 SQL Server 脚本的能力有信心，那么通常只让发布经理来做还是由 DBA 通常做的事情？我们的企业正在快速发展，我们的 DBA 有点超负荷（令人惊讶的是还有什么新东西）但我们可以雇用更多，但这是另一回事。
你们如何管理这个？您是否允许发布经理访问产品以推出更改？您是否取消权利并在需要释放时将其打开？我想我会让他们访问一个 sproc，让他们可以访问 prod 一个小时，但它会记录调用它的人。
还是我完全不在乎，而这是 DBA 应该始终管理的事情？
任何想法将不胜感激！
编辑：
更新： 还有当我们遇到异常时会发生什么？例如，开发人员声明“这些表应该与其他环境相匹配（我所说的环境是指客户生产环境，而不是 qa/stage/etc.）”。通常他们会进行抽查。我做了一个校验和并注意到最终只是空白问题的问题。在这种情况下，我们是否在进行基本故障排除后将其推回给发布经理/质量人员进行修复？
另一个例子：我们有大约 20 个开发人员的脚本，有时他们相互依赖。脚本的顺序是错误的。我跟不上 20 个开发人员的工作，也无法管理数据，但经过一些故障排除后，我们发现了问题并更改了顺序。这是 DBA 通常应该深入参与的事情，还是在基本测试和检查之后公平，我们将其发回给发布经理和开发人员进行修复？
首先，每个环境都不一样。在我的环境中有效的方法不会自动在您的环境中起作用。（我们 = DBA 团队）
在我的这个过程中，我们有以下环境
开发 - 通常我们会恢复实时副本以准备发布并根据需要清理数据。然后我们备份它并使开发人员能够随意恢复到该备份。然后他们准备并测试他们的部署脚本。我们希望开发人员在需要转到 UAT 之前已经完全成功地测试了升级/发布过程。在此阶段，我们通常需要提供帮助和建议
UAT - 我们将再次恢复实时副本并进行清理（如果我们要使用 QA 环境）。然后，发布和配置管理器向我们提供来自开发人员的正确升级脚本，我们将检查它们，在监控的同时运行它们，以便能够提供 CAB 所需的有关服务丢失、升级时间和任何所需更改的所有信息到维护/监控脚本，然后我们建议发布经理。
有时我们使用 QA 环境，通常是在上述两个环境中使用了经过清理的数据，并且业务需要 QA 而不是测试团队。
CAB - 发布经理为 CAB 提供所有信息，以便他们从后续步骤中做出决定，以准确列出发布期间发生的事情。他们还负责存储用于从 Dev 到 UAT 的脚本，并将它们提供给我们用于发布到现场。我们仅使用由发布经理提供并在 CRP 中引用的脚本。我们显然会检查脚本是否与我们在 UAT 中使用的脚本相同，因为我非常谨慎
上线——我们完全按照 CAB 授权的变更发布计划中的步骤部署上线，通常与其他团队协调
我们这样做的部分原因是因为这是我们必须在此处遵循的过程（使用 CAB 等），但在回答您的问题时，这是因为 DBA 团队负责数据的安全性和可访问性。还因为我们拥有从意外问题中恢复的技能、知识和经验。实时数据库发生什么是我们的责任，我们非常重视。除 DBA 团队外，其他任何人都不得在实时数据库上执行任务。我们是监护人和保镖（门男/女）
为您更新。我将这类问题反馈给开发人员，并要求他们在我部署到 UAT 之前修复它。一旦脚本完成（在 UAT），我们知道它将在现场运行。
对于您的另一个例子 - 这是发布经理的工作。如果他们向我们提供失败的脚本，我们会将其退回给他们并要求他们在我们部署到 UAT 之前修复它。我们不会在 UAT 中部署任何需要遵守或更改所提供说明的东西，并且在少数情况下会发生这种情况（在我们运行脚本以使发布能够通过 UAT 后，开发人员使用应用程序帐户来操作一些数据）我站在 CAB 中解释这一点，并解释说我不乐意在没有正确测试发布的情况下发布它。这通常有效 :-) 我知道我很苛刻，但我也很公平。
我告诉发布经理和开发人员，将发布传递给 UAT 的过程不仅是对发布的测试，也是对发布将如何执行的测试，因此我们将在两个示例中遵循完全相同的步骤（开发 - UAT 和 Live ) 如果它在 UAT 中失败，它会返回给他们修复。
我希望这有帮助