通过配置更改持续交付

Question

我想在每次提交源代码时实现持续交付，以便在git中掌握分支。但大多数情况下，代码本身并没有改变，随着代码发布，会有数据库更改，还会添加配置更改或新配置。

所以我的问题是当代码+ DB +配置发生变化时，如何在持续交付中处理这个问题。

让我们举一个例子，我有3个回购

Repo A - 源代码 - 检查新功能或错误修复。自动部署Git钩子在此repo上设置

回购B - 数据库更改

回购C - 配置更改

现在，开发人员有一些代码更改，其中包含配置更改以及数据库更改。因此，如果开发人员首先检查源代码（这将触发构建和部署），但需要一些时间来检查数据库更改和配置更改，则上游环境将使用旧数据库或旧配置的最新代码。这是不一致的，可能会导致不必要的结果。

我可以想到2个解决方案，以避免这个问题：

1）开发人员应接受培训，首先检查DB / config更改，然后检查源代码。

OR

2）还有1个repo - 称为app-releases，它是yaml文件以获取应用程序版本，DB更改元数据（如脚本文件名等）和配置更改标签或标签版本。    在此repo分支上进行自动部署。因此，开发人员可以根据需要进行签入，最后检查将触发构建的app-release文件。

还有其他建议请告诉我吗？

Answer 1

我从 MS SQL Server 的角度讲述。如果您正在使用 Visual Studio SQL Server数据工具加载项附带的数据库项目，那么在部署期间 DACPAC 部署会自动处理架构更改。您可以使用Powershell或SqlPackage.exe执行数据库 DACPAC 部署。这些工具将当前模式与目标数据库进行比较，并生成同步SQL脚本并执行它们。

DACPAC 部署的配置信息存储在Profile xmls中，在 DACPAC 部署期间使用配置文件xmls。每个环境都有单独的配置文件xmls：DEV，INT，UAT，PROD。因此，架构更改将基于配置文件xmls部署到相应的环境。