为生产部署处理SQL更新

Question

我已经研究了很长一段时间了(大约两个月)，还没有找到一个很好的方法，所以我会邀请你们的专家，希望得到一些启示。

我在云中运行了一个非常传统的LAMP web应用程序。源代码是用Git和数据库模式(用于结构和默认数据的拆分SQL文件)编写的。

部署一个新的环境是相当的喜悦，开发或生产。Dev环境是用Vagrant和我编写的一些很好的shell提供脚本来部署的。生产环境是使用的一个子集部署的，这也非常容易做到。

当开发周期强制对SQL模式(结构或数据)进行更改时，事情就会开始中断。在这种情况下，开发人员会更改核心SQL脚本，以便所有的更改都进入VCS，这对于全新的环境来说是完全可以的。

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

最初，我认为我可以将SQL更改从核心SQL文件中移开--更小的子集，将核心SQL文件作为起点。当SQL结构发生变化时，我只需告诉devs创建一个新的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. 是否有任何开源工具可以在此过程中提供帮助？(我知道斯基奇，但我不太确定它是否适合这份工作。)

Answer 1

我不确定您是否还需要答案，但我在管理和部署模式更改时也遇到了同样的问题。Sqitch是我第一次尝试机械化迁移，但我并不真的喜欢它。

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