我推迟问这个问题有一段时间了，因为在没有文字墙的情况下很难概括我们的情况和挑战，但情况越来越糟，所以我会尽力而为。我正在寻求一些帮助，以改进我们开发和管理应用程序数据库和开发人员环境的方式，特别是在跨环境的数据库依赖项方面。
我们是一家拥有大量遗留代码的中型公司。为了了解我们当前的应用程序数据库是什么样子，这里有一些大致的数字：50GB、450 个表、200 个视图和 400 个存储过程。此外，我们的生产服务器运行大约 15 个数据库，其中大部分需要或被我们的应用程序数据库需要。
澄清一下：当我说“需要”时，我指的是不会编译/将编译但不会在没有依赖项的情况下运行的数据库对象。这些对象的示例是链接服务器和复制订阅等服务器对象，或存储过程和视图等数据库对象。
在过去的一年中，我们对开发和部署数据库的方式进行了重大改进。迄今为止的改进包括引入专用开发人员环境、（几乎）所有数据库代码的版本控制、从 Git（基于触发器）自动部署以及向 SQL Server 集群的过渡。
我们正在努力解决的问题是如何处理从我们的应用程序数据库到其他数据库的依赖关系，而我似乎找不到合适的资源。这些依赖关系分为两个不同的挑战：
1. 同一台服务器上的数据库
目前来说，我们的应用数据库依赖于同一台服务器上的 5 个数据库。这些是具有单独存储库、部署管道、库和 Web 项目的数据库。在引导开发人员环境时，我们必须注意以特定顺序创建这些环境，以便成功应用 DDL 和 DML 脚本，以免我们面临依赖错误。仅此过程就引起了很多头痛。事实上，它引起了如此多的头痛，以至于我们的一些开发人员干脆放弃了本地开发人员环境，并在共享数据库中进行所有开发。
2. 远程服务器上的数据库只能用于生产
在我们的生产环境中，我们从少数远程 SQL Server 实例导入数据。其中一些数据是使用存储过程导入的，这些存储过程使用链接服务器对象引用远程服务器。为了运行存储过程，链接服务器对象需要存在。为了使链接服务器对象“成功”存在，它引用的远程服务器必须是可访问的。远程服务器只能从我们的生产服务器访问（这是正确的），但这会导致我们的存储过程在部署期间无法正确编译。
在“持续交付”一书中，作者 Dave Farley 强调，在真正的持续集成中，组装和运行项目所需的每一个资源都应该驻留在其存储库中。此外，他还指定每个环境都应该相同（凭据和连接字符串等配置除外）。我们的应用程序不满足这些原则，我什至不确定这样做是否可行。
我们的工具
感觉就像我在这里错过了一些核心架构原则。我们可以做些什么来缓解这些问题？也欢迎对相关文献提出建议。
sql-server best-practices development continuous-integration