我想在每次提交源代码到 git 中的主分支时实现持续交付。但大多数时候，代码本身不会更改，随着代码发布，会有数据库更改以及配置更改或添加新配置。
所以我的问题是，当有代码 + DB + 配置更改时，如何在持续交付中处理这个问题。
让我们举个例子，我有 3 个存储库
存储库 A - 源代码 - 用于签入新功能或错误修复。在此存储库上设置了自动部署 Git 挂钩
存储库 B - 数据库更改
存储库 C - 配置更改
现在，开发人员有一些代码更改，这些更改包括配置更改和数据库更改。因此，如果开发人员首先签入源代码(这将触发构建和部署(，但需要一些时间来签入数据库更改和配置更改，则上游环境将具有具有旧数据库或旧配置的最新代码。这是不一致的，可能会导致不需要的结果。
我可以想到2个解决方案来避免这个问题：
1(开发人员应该接受培训，首先签入DB/配置更改，然后再签入源代码。
或
2( 还有 1 个存储库 - 称为应用程序发布，它是 yaml 文件，用于获取应用程序版本、数据库更改元数据(如脚本文件名等(和配置更改标签或标签版本。 在此存储库分支上进行自动部署。因此，开发人员可以根据需要签入，最后签入将触发构建的应用程序发布文件。
还有其他建议请告诉我吗？
我是从MS SQL Server的角度来看的。如果使用Visual Studio SQL Server 数据工具外接程序附带的数据库项目，则在DACPAC部署期间会自动处理架构更改。您可以使用Powershell或SqlPackage.exe执行数据库DACPAC部署。这些工具将当前架构与目标数据库进行比较，并生成同步 SQL 脚本并执行它们。
DACPAC部署的配置信息存储在配置文件 xml 中，配置文件 xml 在DACPAC部署期间使用。每个环境都有单独的配置文件XML：DEV，INT，UAT，PROD。架构更改将相应地部署到基于配置文件 xml 的相应环境。