将 SQL Server 数据库从测试部署到上线

08-06-2019
|

题

我想知道你们如何管理 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 不算在内）。

最后 - 考虑到实时数据库已经包含数据，部署可能不涉及创建所有表，而是检查结构的差异并更改实时表，这在现有字段更改时可能还需要数据验证/转换。

现在，我听到了很多关于红门产品，但对于业余爱好项目，价格有点贵。

那么，您使用什么来自动部署 SQL Server 数据库从测试到上线的过程？

解决方案

我已经开始对所有 DDL（创建/更改/删除）语句进行手动编码，将它们作为文本文件添加到我的 .sln 中，并使用正常版本控制（使用 subversion，但任何修订控制都应该起作用）。这样，我不仅获得了版本控制的好处，而且从开发/阶段进行实时更新对于代码和数据库来说是相同的过程 - 标签、分支等工作都是一样的。

否则，如果你没有公司为你购买，我同意redgate是昂贵的。如果你能找到一家公司为你购买，那就真的值得了！

其他提示

对于我的项目，我交替使用 REd Gate 的 SQL Compare 和 Microsoft 的数据库发布向导（您可以免费下载）这里.

该向导不像 SQL Compare 或 SQL Data Compare 那样灵活，但它可以起到作用。一个问题是它生成的脚本可能需要一些重新排列和/或编辑才能一次性流动。

从好的方面来说，它可以移动您的架构和数据，这对于免费工具来说并不坏。

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

它相当昂贵，但我使用了试用版一段时间，并认为它非常棒。它使数据库像任何其他代码一样易于使用。

和 Rob Allen 一样，我使用 Redgate 的 SQL Compare/Data Compare。我还使用 Microsoft 的数据库发布向导。我还有一个用 C# 编写的控制台应用程序，它采用 sql 脚本并在服务器上运行它。这样您就可以从命令行或批处理脚本中运行带有“GO”命令的大型脚本。

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

我的工作方式与 Karl 相同，将用于创建和更改表的所有 SQL 脚本保留在我保留在源代码管理中的文本文件中。事实上，为了避免必须让脚本检查实时数据库以确定要运行哪些 ALTER 的问题，我通常这样工作：

在第一个版本中，我将测试期间的所有内容放入一个 SQL 脚本中，并将所有表视为 CREATE。这意味着我最终会在测试期间大量删除和读取表格，但这在项目早期并不是什么大问题（因为我通常会破解当时使用的数据）。
在所有后续版本中，我做了两件事：我创建了一个新的文本文件来保存升级 SQL 脚本，其中仅包含该版本的 ALTER。我对原始脚本进行了更改，并创建了一个新的数据库脚本。这样，升级只需运行升级脚本，但如果我们必须重新创建数据库，我们不需要运行 100 个脚本即可到达那里。
根据我部署数据库更改的方式，我通常还会在数据库中放置一个版本表来保存数据库的版本。然后，我运行创建/升级脚本的任何代码都使用版本来确定要运行的内容，而不是对要运行的脚本做出任何人为决定。

如果您从测试转移到生产的部分内容是数据，那么这不会有帮助，但如果您想管理结构而不是支付漂亮但昂贵的数据库管理包的费用，那么实际上并不是很困难。我还发现这是一种在心里跟踪数据库的好方法。

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

他们有大多数流行数据库的版本，当然包括 Sql Server。

我同意将一切都编写成脚本是最好的方法，也是我在工作中提倡的。您应该编写从数据库和对象创建到填充查找表的所有内容的脚本。

您仅在 UI 中执行的任何操作都不会翻译（特别是对于更改......对于第一次部署来说没有那么多），最终需要像 Redgate 提供的工具。

使用 SMO/DMO，生成模式脚本并不太困难。数据更有趣一些，但仍然可行。

一般来说，我采用“编写脚本”方法，但您可能需要考虑以下一些内容：

区分开发和暂存，以便您可以使用数据子集进行开发......我将创建一个工具来简单地提取一些生产数据，或者在涉及安全性的情况下生成虚假数据。
对于团队开发，对数据库的每次更改都必须在团队成员之间进行协调。架构和数据更改可以混合在一起，但单个脚本应该启用给定的功能。一旦所有功能准备就绪，您可以将它们捆绑在一个 SQL 文件中，并针对生产恢复运行该文件。
一旦您的登台通过验收，您就可以在生产计算机上再次运行单个 SQL 文件。

我使用过 Red Gate 工具，它们是 伟大的 工具，但如果你买不起，那么构建工具并以这种方式工作离理想也不算太远。

我正在使用 Subsonic 的迁移机制，所以我只有一个 dll，其中的类按顺序排列，有 2 种方法，向上和向下。nant 有一个持续集成/构建脚本挂钩，这样我就可以自动升级数据库。

这不是世界上最好的事情，但它胜过编写 DDL。

RedGate Sql比较我认为这是一条路。我们定期进行数据库部署，自从我开始使用该工具以来，我从未回头。非常直观的界面，最终节省了大量时间。

专业版还将负责源代码控制集成的脚本编写。

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

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

我不喜欢自动应用架构更改，例如新表、新列等。在进行生产发布时，我喜欢逐个命令地检查更改脚本，以确保每个脚本都能按预期工作。没有什么比在生产中运行一个大的更改脚本并因为忘记了一些在开发中没有出现的小细节而出现错误更糟糕的了。

我还了解到索引需要像代码文件一样对待并放入源代码管理中。

而且您绝对应该拥有 2 个以上的数据库 - 开发数据库和实时数据库。您应该有一个每个人都用于日常开发任务的开发数据库。然后是模拟生产的临时数据库，用于进行集成测试。然后，如果可行的话，可能是最近的完整生产副本（从完整备份恢复），因此您的最后一轮安装测试与尽可能接近真实情况的内容相悖。

我将所有数据库创建作为 DDL 进行，然后将该 DDL 包装到模式维护类中。首先，我可能会做各种事情来创建 DDL，但从根本上来说，我在代码中完成所有模式维护。这也意味着，如果需要执行无法很好地映射到 SQL 的非 DDL 操作，您可以编写过程逻辑并在 DDL/DML 块之间运行它。

然后，我的数据库有一个定义当前版本的表，因此可以编写一组相对简单的测试：

数据库存在吗？如果没有创建它。
DB是当前版本吗？如果没有，则按顺序运行方法，使架构保持最新（您可能希望提示用户确认，并且最好在此时进行备份）。

对于单用户应用程序，我只是就地运行它，对于网络应用程序，如果版本不匹配，我们当前会将用户锁定，并且我们运行一个独立的架构维护应用程序。对于多用户，这将取决于特定的环境。

优势？我非常有信心，使用此方法的应用程序的架构在这些应用程序的所有实例中都是一致的。它并不完美，存在一些问题，但它有效......

在团队环境中开发时会遇到一些问题，但这或多或少是必然的！

墨菲

我目前正在为你做同样的事情。不仅包括SQL Server数据库从测试到上线的部署，还包括从本地->集成->测试->生产的整个流程。所以能让我每天轻松的就是我做的事 NAnt 任务与 Red-Gate SQL 比较. 。我不在 RedGate 工作，但我不得不说这是一个不错的选择。

许可以下： CC-BY-SA 和归因

不隶属于 StackOverflow