处理生产部署的 SQL 更新

Question

我现在研究了很长时间（大约两个月），还没有找到一个好的方法，所以我会请教各位专家，希望能有所启发。

我在云中运行了一个非常传统的 LAMP Web 应用程序。源代码是使用 Git 进行 VCS 处理的，以及数据库架构（拆分 SQL 文件用于结构和默认数据）。

部署新环境是一种乐趣，无论是开发还是生产。开发环境使用 Vagrant 以及我编写的一些不错的 shell 配置脚本进行部署。生产环境是使用 Vagrant 配置脚本的一个子集部署的，这也很容易做到。

当开发周期对 SQL 模式（结构或数据）进行更改时，事情开始出现问题。在这种情况下，开发人员会更改核心 SQL 脚本，以便所有更改都进入 VCS，这对于全新的环境来说是完全没问题的。

问题出在已经部署的生产环境中：对于那些，我必须手动获取 SQL 更改的所有补丁，因为修订版首先在所有生产服务器中实际运行，以便我可以在之后手动应用它们。这需要很长时间才能发生，是一项非常脆弱且容易出错的任务。

最初，我认为我可以将 SQL 更改从核心 SQL 文件的较小子集移开，让核心 SQL 文件作为起点。当 SQL 结构发生变化时，我可以告诉开发人员创建一个新的 SQL 文件，其中仅包含该开发周期中的更改。

因此，例如：

- structure_begin.sql: the SQL schema as it is now.
|- structure_devcycle1.sql: first set of changes to the structure
|- structure_devcycle2.sql: second set of changes to the structure, and so forth...

然后，通过使用 Git 钩子，我可以有选择地自动将它们部署到生产环境中。但我不知道这是否是一个好方法。在这里我可以问：

1. 有没有人解过这个谜题？
2. 生产环境中 SQL 更改的发布管理和部署自动化的最佳实践是什么？
3. 是否有任何开源工具可以在此过程中提供帮助？（我知道Sqitch，但我不太确定它是否适合这份工作。）

Answer 1

我不确定您是否仍然需要答案，但我在管理和部署架构更改方面遇到了同样的问题。Sqitch 是我尝试实现迁移机械化的第一个工具，但我并不是很喜欢它。

正如您所描述的，我们有单独的 .sql 文件，其中包含 CREATE TABLE 和反映我们数据库架构的其他指令。我们创建了简单的工具来在架构更改时生成 SQL 补丁。看看它： https: //github.com/condograde/sqlibrist。有详细教程，如何使用。