在自动生成之前部署/运行数据库更改

很显然,您需要自动运行数据库更改脚本——其中的挑战是如何决定运行什么。答案是,您需要将模式版本存储在数据库(或数据库元数据)中,并选择相应运行的脚本——无论是从头开始运行数据库还是应用适当的更改。

我的解决方案是将我的数据库模式维护完全放在代码中,我认为这是迄今为止我所做的最好的编写版本:

How to create "embedded" SQL 2008 database file if it doesn't exist?

如果代码足够智能,可以在应用程序或其自己的控制台应用程序中在线升级模式,那么您应该能够将自动模式更改集成到CI构建脚本中。

自从我写了上面的内容之后,我一直在进一步研究这个问题——结果发现我所做的与Ruby迁移(我相信在亚音速中也有类似的功能)没有什么不同,只是我目前没有任何“向下”的能力来逆转模式更改(一个有趣的我担心有潜在破坏性的代码“live”)。有一个开源.NET项目 Migrator.net 这看起来很有用,但我不确定它的维护有多积极。

附录

自从我第一次编写这个实体框架代码以来,它们就开始在迁移方面取得进展,所以现在值得一看。然而,我认为它还不完全存在,像其他几种选择一样,我看到它并不简单。我需要把我的包打包,让它可用!

有很多方法可以解决这个问题。我在许多公司使用的一种方法 here 基本上,它是处理自动数据库更新任务的源代码,以及一些如何和为什么的解释。

我还建议检查数据包(只是谷歌),我没有使用它,但我的理解是它可以用来自动更新数据库(可能是错误的)。

我会说,我不建议使用数据库比较工具来生成脚本……而不需要非常小心。问题通常是您将您的dev-db(您的更改所在的位置)与build-box-db进行比较,但您的db可能包含(并且可能包含)您为正在进行的“工作中”bug修复所做的其他更改。

不管怎样,就像我说的,有很多方法可以做到这一点,调查一些选择,选择最适合你和你的团队风格的。

自动驾驶快乐:-)