Question

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

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

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

感谢您的回复！

Answer 1

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

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

SQL Server具有Generate and Publish Scripts Wizard，如果您想将现有数据库放入源代码管理中，这可能非常有用。

Answer 2

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

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

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

但是，如您所知，有一些DDL脚本无法执行两次。例如，'CREATE TABLE mytable ...'脚本只能执行一次。如果您的系统已经投入生产，那么您无法在“CREATE TABLE ...”脚本的标题中提供“DROP TABLE mytable”语句。因此，对于生产系统，您需要创建仅提供更改的所谓 delta脚本。在这种情况下，您可以简单地创建一个名为employees_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）如果您需要部署系统的全新安装 - 您可以按顺序运行所有脚本，例如首先是 employees.sql ，然后是 employees_upgr20091001.sql 等。

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

Answer 3

在一个项目中，我在DDL脚本中更改了所有数据库。这些脚本包含将DB升级到特定版本所必需的SQL语句。脚本的文件名还包含要升级数据库的数据库的版本号（_versionnumber.sql）

接下来，我有一个小应用程序，它通过以正确的顺序执行这些脚本文件（从DB的当前版本到最后一个脚本文件）将数据库升级到最新版本。

对于新项目，我现在使用Migrator.NET。此框架允许您在C＃类中编写数据库更改。该框架有一个控制台应用程序，您可以使用它来执行数据库更改，也可以将它与msbuild一起使用。

Answer 4

脚本化并存储您在SQL中所做的每一项更改都是IMO的最佳方式。

数据库部署最佳实践

4 个答案: