1

我们针对不同的部署环境使用不同的服务帐号，所以 Dev 有 Account_A，Prod 有 Account_B，任何使用 Account_A 的测试应用都无法访问 Prod。或者，作为另一个示例，Account_A 在 Dev 中可以具有读/写权限，但在 Prod 中只有读权限。

到目前为止，还没有对数据库定义进行源代码控制，到处都是手动脚本，我想为此在 Azure DevOps 中创建一个 SSDT 解决方案。我了解如何设置版本以处理跨环境的不同数据库名称（例如 Db_Dev 与 Db_Prod），但我无法找到有关跨环境的不同用户和权限的任何信息。

这在 SSDT 中可能吗？据我所知，我有两个选择，但我希望有更好的方法：

  1. 处理源代码控制之外的用户和权限
  2. 在部署后的脚本中以某种方式处理它们。

警告：我只是在谈论 Windows 身份验证用户和组。密码显然不会进入源代码控制。

4

3 回答 3

2

我很久以前在这里写过这个：https ://schottsql.com/2013/05/14/ssdt-setting-different-permissions-per-environment/

为了做到这一点，您确实在处理环境变量和一堆部署后脚本。您更好的选择是将权限分配给数据库角色，以便它们都是一致的，然后在每个环境中适当地将您的用户分配给这些角色 - 在 SSDT 之外。从长远来看，这比尝试在一系列部署后脚本中创建/维护登录名和用户要痛苦得多。

于 2020-10-01T21:40:41.013 回答
1

在 DevOps 方面，环境是资源的集合，例如 Kubernetes 集群和虚拟机，可以通过管道进行部署。环境名称的典型示例是 Dev、Test、QA、Staging 和 Production。您可以通过指定允许哪些用户和管道以环境为目标来保护环境。

您可以控制谁可以创建、查看、使用和管理具有用户权限的环境。有四种角色 - 创建者（范围：所有环境）、读者、用户和管理员。在特定环境的用户权限面板中，您可以设置继承的权限，并且可以覆盖每个环境的角色。

更多详情，请查看以下链接：

https://docs.microsoft.com/en-us/azure/devops/pipelines/process/environments?view=azure-devops#security

于 2020-10-01T07:27:39.920 回答
1

在 SSDT 中管理用户和权限有点痛苦，而且通常不会在那里维护。但是，您仍然有选择：

  • 如您所述创建后置脚本（错误的选择）
  • 为每个环境创建单独的项目

我所说的单独项目的意思是：您需要为每个环境创建单独的项目，然后添加主项目的引用（所有对象都存在）并将引用类型设置为“相同的数据库”。然后在该项目中，您将添加所有需要的用户/权限/修改。这些项目也将有自己的发布配置文件。您可能面临的 1 个问题是，他的项目也应将所有数据库/dacpacs 引用为您的主要项目。

于 2020-10-01T09:20:09.480 回答