问题描述
我们为不同的部署环境使用了不同的服务帐户，因此Dev拥有Account_A，Prod拥有Account_B，并且任何使用Account_A的测试应用都将无法访问Prod。或者，作为另一个示例，Account_A可以在Dev中具有读/写权限，但只能在Prod中具有读权限。
到目前为止，还没有关于数据库定义的源代码控制，只是到处都是手动脚本，我想为此在Azure DevOps中创建SSDT解决方案。我了解您如何设置发行版以处理跨环境的不同数据库名称（例如Db_Dev与Db_Prod），但是我无法找到有关跨环境的不同用户和权限的任何信息。
SSDT是否有可能？据我所知，我有2种选择，但我希望有更好的方法：
注意：我只是在谈论Windows身份验证用户和组。密码显然不会进入源代码控制。
解决方法
在DevOps方面，环境是资源的集合，例如Kubernetes集群和虚拟机，可以通过管道中的部署作为目标。环境名称的典型示例是Dev，Test，QA，Staging和Production。您可以通过指定允许哪些用户和管道将环境作为目标来保护环境。
您可以控制谁可以创建，查看，使用和管理环境 具有用户权限。有四个角色-创作者（作用域：全部 环境），阅读器，用户和管理员。在具体 环境的用户权限面板中，您可以设置 是继承的，您可以覆盖每个环境的角色。
更多详细信息，请检查以下链接：
,在SSDT中管理用户和权限在pain中有些痛苦，通常不在那里维护它们。但是，您仍然可以选择：
- 创建您提到的后脚本（错误的选择）
- 为每个环境创建单独的项目
我所说的单独项目是：您需要为每个环境创建单独的项目，然后添加主项目（所有对象都存在的地方）的引用，并将引用类型设置为“同一数据库”。然后，在该项目中，您将添加所有需要的用户/权限/修改。这些项目也将具有自己的发布配置文件。您可能还会遇到的第一个问题是，他的项目也应同时引用所有数据库/ dacpacs作为您的主项目。
,很久以前我在这里写过：https://schottsql.com/2013/05/14/ssdt-setting-different-permissions-per-environment/
您实际上是在处理环境变量和一堆部署后脚本，以实现此目的。更好的选择是为数据库角色分配权限，以使这些角色保持一致，然后根据需要将用户分配给每个环境中的角色-在SSDT之外。从长远来看，这比尝试在一系列部署后脚本中创建/维护登录名和用户要容易得多。