在多个项目中，我们遇到了与您相同的情况，下面是我们解决问题的方法。
情况
一个数据库用于多个相关的事情。承包商正在开发依赖于数据库的应用程序子集。员工正在同一个数据库中处理应用程序的另一个子集。dba负责迁移。
存储库
我们有两个存储库-一个用于应用程序开发，另一个用于数据库。合同和员工在应用程序存储库中编写代码。数据库存储库中正在发生数据库更改。dba正在从db存储库迁移出去。应用程序更改控制团队正在部署应用程序存储库中的代码。DBA和应用程序变更控制团队进行了充分的协调，以正确的方式部署正确的东西。
分支策略
承包商在应用程序和数据库存储库上创建了一个功能分支（例如用户首选项）。对数据库的更改将放在数据库存储库中。对应用程序的更改将进入应用程序存储库。一旦编写了足够的依赖于数据库更改的代码，他们就会对发行版进行特性标记并将其推出。变更管理和dba审查了将两个存储库中的用户首选项分支的请求拉到一起，以确保它们能够正确部署，然后将分支合并到master并完成它们的发布过程。在受控环境中打开和关闭功能标志，以确保没有后期生产问题。团队成员在一天中多次合并。这种方法很有效。您可能注意到，ci/cd并不是完全自动化的。各小组相互讨论了他们对db所做的更改，所以每个人都知道会发生什么。
基于 Backbone.js 的开发
在另一种情况下，我们决定在app和db存储库中创建本地分支。我们将测试代码和数据库的变化，并尽快干净地合并。dba和变更管理团队在通过qa、生产前检查等之后，每天都部署到生产中。令人惊讶的是，我们没有那么多冲突，而且那些冲突很容易解决。我们强调创建数据库更改，并在开发人员测试了他们的理论后立即将其推到master上。数据库的更改先于代码。
就像一个特性标志一样，开发人员在允许用户交互之前检查他们的db依赖关系。如果在某种程度上，没有找到他们的代码所依赖的db更改，那么就会显示一条优美的消息，并且会有一封电子邮件供更改管理人员查看依赖关系。同样令人惊讶的是，事情进展得相当顺利。
更复杂的例子
一个受监管的公司有多个承包团队，一些做敏捷，一些瀑布，一些使用他们自己炮制的开发方法。公司的员工有多个团队，不同的承包商有相同的差异。他们必须一起工作来创建特性，解决问题等等。听起来很混乱，对吧？他们创建了一个每日cab会议——cab代表变更批准委员会。每个团队将花5分钟的时间来教育cab他们打算将什么推向生产以及他们的依赖关系。有不同的存储库和版本控制系统。
非常小的改动被允许进行，并被推向生产。巨大的变革将以巨大的声势进行。变更管理团队从不同的repos/版本控制系统收集代码，在他们的sim（模拟）环境中播放（先是db，然后是app变更），然后计划生产。大的变化发生在持久的分支中，这些分支每晚都会随着小的变化而更新。在大变动即将结束的月份，小变动会暂停几天。大的变化会消失，然后小的变化会恢复。坦率地说，它远没有达到完美的程度，但只要有两个全职员工像鹰一样监视部署，它就可以工作。
这两家公司的共同点是，应用程序开发人员都有一个功能标记，并运行一个飞行前检查表，以确保所有的依赖关系都到位，使他们的功能能够成功运行。这样，如果遗漏了什么，就会记录错误，并优雅地通知用户该做什么/给谁打电话。

许多应用程序连接到同一个数据库通常是个坏主意，这也是人们转向微服务的主要原因之一。因此它们具有数据隔离，并且一个服务与另一个服务数据库不相关。
如果你有一个大的解决方案处理许多项目，我建议你使用
数据库备份
dbup是一个.net库，可以帮助您将更改部署到sql server数据库。它跟踪哪些sql脚本已经运行，并运行使数据库更新所需的更改脚本。
它不是orm，它使用纯sql。在代码中创建一个sql脚本列表，它也是源代码管理的一部分，每次启动应用程序时，都会检查是否应用了所有迁移，如果没有，则会应用最后的更改。
迁移检查和数据库更新可以自动化
作为ci/cd管道的一部分。
作为应用程序中的启动任务，在每次启动应用程序时运行。你可以在AndrewLock的博客中找到一个如何设置启动任务的例子。