数据库部署最佳实践

大多数情况下,我们更改表中的现有数据库表,存储过程,函数或参数以进行软件升级/错误修正.当我们将更改部署到生产或预生产等其他环境时,我们的数据库更改的某些部分将被遗忘.

在我们公司,一些开发人员使用数据库差异分析应用程序来找出测试和生产环境之间的差异.一些开发人员存储他们在db上所做的每个更改的t-sql,就像我一样.

我想知道你在做什么来将db更改部署到生产环境.为什么选择这种方式？或者必须做什么？

谢谢你的回复!

我们在源代码管理下有数据库.以这种方式跟踪任何更改.别的什么都是噩梦.

杰夫也有一篇文章 - http://blog.codinghorror.com/get-your-database-under-version-control/

根据您的设置和数据库,数据库发布向导 - http://www.codeplex.com/sqlhost/Wiki/View.aspx?title=Database%20Publishing%20Wizard-可能非常有用.

每个数据库对象应存储在版本控制系统中的单独文件中。版本控制系统可能包含以下示例中的文件：

|- tables
     |- employees.sql
     |- contracts.sql
|- packages
     |- contract_api.sql
|- functions
     |- get_employee_name.sql
...etc...

每当您修改某些数据库对象时，也必须在版本控制系统中修改相应的SQL（DDL）文件。例如，如果您修改包contract_api，那么您将更新文件contract_api.sql。由于此文件已被修改-例如，可以通过持续集成引擎进行安装。

但是，您知道，有些DDL脚本不能执行两次。例如，“ CREATE TABLE mytable ...”脚本只能执行一次。而且，如果您的系统已经投入生产，那么您将无法在“ CREATE TABLE ...”脚本的标题中提供“ DROP TABLE mytable”语句。因此，对于生产系统，您需要创建仅提供更改的所谓的增量脚本。在这种情况下，您可以简单地创建一个名为employee_upd01.sql的新文件，其中包含语句“ ALTER TABLE mytable ADD COLUMN ...”。

一段时间后，您的存储库可能如下所示：

|- tables
     |- employees.sql
     |- employees_upgr20091001.sql
     |- employees_upgr20091004.sql
     |- contracts.sql
|- packages
     |- contract_api.sql
|- functions
     |- get_employee_name.sql
...etc...

这样就可以了，因为：1）当您需要将当今的增量更改交付给数据库时-部署今天已修改的文件2）如果您需要部署系统的全新安装-您可以按顺序运行所有脚本，例如首先是employee.sql，然后是employee_upgr20091001.sql，等等。

由于每个数据库对象都位于版本控制系统中的单独文件中，因此您可以很好地控制所有更改。