部署从测试到生活的SQL Server数据库

Question

我想知道你们是如何管理2台SQL Server之间的数据库部署的，特别是SQL Server 2005. 现在有一个开发和一个活的。由于这应该是构建脚本的一部分（标准的windows批处理，甚至可以使用这些脚本的当前复杂性，我可能会在以后切换到PowerShell等），Enterprise Manager/Management Studio Express不计算在内。

你会复制.mdf文件并附加它吗？在处理二进制数据时，我总是会小心一些，因为这似乎是一个兼容性问题（即使开发和生活应始终运行同一版本的服务器）。

或者 - 由于缺少T-SQL中的“EXPLAIN CREATE TABLE” - 您是否做了一些将现有数据库导出到可以在目标服务器上运行的SQL脚本？如果是的话，有没有一种工具可以自动将给定的数据库转储到SQL查询中并且在命令行上运行？ （同样，Enterprise Manager/Management Studio Express不计算在内）。

最后 - 考虑到实时数据库已经包含数据的事实，部署可能不涉及创建所有表，而是检查结构和ALTER TABLE中的差异，而不是实时的，这可能还需要数据验证/转换现有的领域改变。

现在，我听到很多关于Red Gate产品的很棒的东西，但对于爱好项目，价格有点陡峭。

那么，什么是您使用从测试自动部署SQL Server数据库的生活吗？

Answer 1

我已经采取了手动编码所有的DDL（创建/更改/删除）语句，将它们添加到我的.sln作为文本文件，并使用正常的版本控制（使用颠覆，但任何版本控制应该工作） 。这样，我不仅可以获得版本控制的好处，而且可以通过dev/stage进行实时更新，这与代码和数据库的相同流程 - 标签，分支等工作完全相同。

否则，我同意展鹏是昂贵的，如果你没有一个公司买给你。如果你可以让一家公司为你购买它，它确实是值得的！

Answer 2

对于我的项目，我将在REd Gate的SQL Compare和Microsoft的Database Publishing Wizard之间进行交替，您可以免费下载 here。

的向导是不是一样光滑如SQL比较或SQL数据比较，但它的伎俩。一个问题是它生成的脚本可能需要重新排列和/或编辑才能一次流动。

在向上的一面，它可以将你的架构和数据是不坏的免费工具。

Answer 3

如果您有公司购买它，Quest Software的Toad内置了这种管理功能。它基本上是一个双击操作，用于比较两个模式并生成一个同步脚本。

他们有最流行的数据库的版本，当然也包括的SQL Server。

Answer 4

我的工作方式与Karl所做的一样，保留了所有用于创建和更改表格的SQL脚本，并保留在源代码管理的文本文件中。事实上，为了避免有一个脚本检查实时数据库，以确定哪些改变运行的问题，我平时的工作是这样的：

• 在第一个版本，我把一切都检测到一个SQL脚本中，并将所有表视为CREATE。这意味着我最终会在测试过程中丢弃和读取表格，但这在项目的早期阶段并不是什么大问题（因为无论如何我通常都会窃听我​​在那个时候使用的数据）。
• 在所有后续版本，我做两件事情：我提出一个新的文本文件来保存升级SQL脚本，包含只是该版本的改变。而且我对原始文件进行了更改，并创建了新的数据库脚本。这样升级只是运行升级脚本，但如果我们必须重新创建数据库，我们不需要运行100个脚本即可达到此目的。
• 取决于我如何部署数据库的变化，我也通常把一个版本表中保存数据库的版本数据库。然后，不管运行脚本的人决定，运行创建/升级脚本的任何代码都会使用该版本来确定要运行的内容。

如果你正在从测试移动到生产的一部分是数据，但是如果你想管理结构并且不支付一个漂亮但昂贵的数据库管理包，真的不是很难。我也发现这是保持你的数据库心智跟踪的一个很好的方法。

Answer 5

我同意脚本一切都是最好的方式是什么，我主张在工作。您应该编写从数据库和对象创建到填充查找表的所有内容。

任何你在UI做不但不会转化（特别是对于改变......没有那么多第一次部署），并最终将需要的工具像什么展鹏提供。

Answer 6

使用SMO/DMO，这是不是太难以生成您的架构的脚本。数据有点更有趣，但仍然可行。

一般情况下，我把“脚本它”的做法，但你可能想继续沿着这条考虑别的：

• 发展和分期之间的区别，这样你可以用数据的一个子集开发.. 。我会创建一个工具来简单地下拉一些生产数据，或者在涉及安全性的地方生成假数据。
• 对于团队开发，每个数据库更改都必须在团队成员之间进行协调。模式和数据更改可以混合在一起，但单个脚本应启用给定的功能。一旦你的所有功能都准备好了，你就可以将这些功能捆绑在一个SQL文件中，并在生产恢复时运行。
• 一旦您的分段已被清除，您将再次在生产计算机上运行单个SQL文件。

我已经使用了红门的工具，他们是伟大的工具，但如果你买不起，构建工具和工作这种方式与理想不太远。

Answer 7

像罗布·艾伦，我使用的SQL比较/数据由展鹏进行比较。我也使用Microsoft的数据库发布向导。我也有一个我在C＃中编写的控制台应用程序，它需要一个sql脚本并在服务器上运行它。这样，您可以通过命令行或批处理脚本在其中运行带有“GO”命令的大型脚本。

我使用Microsoft.SqlServer.BatchParser.dll和Microsoft.SqlServer.ConnectionInfo。控制台应用程序中的dll库。

Answer 8

我同意将所有内容都保存在源代码控制中，并手动编写所有更改。对单个版本的模式更改会进入专门为该版本创建的脚本文件。所有存储的特效，视图等都应该放到单个文件中，并像源代码管理一样处理.cs或.aspx。我使用powershell脚本来生成一个大的.sql文件来更新可编程性的东西。

我不喜欢自动化模式更改的应用程序，如新表，新列等。在执行生产版本时，我喜欢通过命令执行更改脚本命令以确保每个都按预期工作。没有什么比在生产中运行一个大的变更脚本和获取错误更糟的了，因为你忘记了一些没有出现在开发中的细节。

我也了解到索引需要像代码文件一样处理并放入源代码控制。

而且你绝对应该有超过2个数据库 - dev和live。你应该有一个每个人都用于日常开发任务的开发数据库。然后是一个模拟生产的临时数据库，用于进行集成测试。然后，如果可行的话，也许是一个完整的生产副本（从完全备份恢复），所以最后一轮安装测试与尽可能接近真实情况的东西相反。

Answer 9

不要忘记微软对此问题的解决方案：Visual Studio 2008 Database Edition。包括用于部署数据库更改的工具，在用于模式和/或数据更改的数据库之间产生差异，单元测试和测试数据生成。

这是非常昂贵的，但我用了一段时间的试用版，并认为它是辉煌的。它使数据库与任何其他代码一样易于使用。

Answer 10

我将所有数据库创建为DDL，然后将该DDL包装到模式维护类中。我可能会首先做各种事情来创建DDL，但从根本上讲，我会在代码中完成所有的架构维护。这也意味着如果你需要做非DDL的东西，那么你可以编写程序逻辑并在DDL/DML之间运行它。

我DBS则有它定义了当前版本的表，这样可以编写一个相对简单的测试集：

1. 是否存在DB？如果不创建它。
2. DB是当前版本吗？如果没有，则依次运行这些方法，以使模式保持最新（您可能希望提示用户确认，并且 - 理想情况下 - 在此时执行备份）。

对于单用户应用程序，我只是在适当的位置运行此应用程序，对于Web应用程序，我们当前锁定用户，如果版本不匹配并且有我们运行的独立架构维护应用程序。对于多用户，它将取决于特定的环境。

优势？那么我有很高的信心，即使用这种方法的应用程序的架构在这些应用程序的所有实例中都是一致的。它不完美，有问题，但它的工作原理...

在团队环境中开发时存在一些问题，但这或多或少都是给定的！

墨菲我使用的是亚音速的迁移机制

Answer 11

所以我只是在squential以便有2个方法，上下类的DLL。有一个连续的集成/构建脚本钩入nant，以便我可以自动升级数据库。

它不是世界上最好的thign，但它击败了编写DDL。

Answer 12

RedGate SqlCompare是一种在我看来的方式。我们定期进行数据库部署，自从我开始使用该工具以来，我从未回头过。 非常直观的界面，最终节省大量时间。

Pro版本也会负责源代码控制集成的脚本。

Answer 13

我目前正在为你工作。不仅将SQL Server数据库从测试部署到现场，还包括从本地 - >集成 - >测试 - >生产的整个过程。那么，什么可以让我轻松地每天都是我做NAnt task with Red-Gate SQL Compare。我不是为RedGate工作，但我不得不说这是个不错的选择。

Answer 14

我还为所有对象和数据维护脚本。对于部署，我写了这个免费的实用程序 - http://www.sqldart.com。它会让你重新排序你的脚本文件，并在事务内运行整个脚本。