在数据库驱动的网站开发中使用 SQL Compare

这是我们CodeProject赞助商的展示评论。这些评论旨在为您提供我们认为对开发人员有用且有价值的产品和服务信息。

引言

Red Gate 网站——一个运行在 SQL Server 2000 上的 ASP.NET 站点——最近进行了大规模的重构。在这里，项目开发人员 Richard Mitchell 和 Steven Davidson 描述了他们如何将 Red Gate 的数据库模式比较工具 SQL Compare 作为其项目环境的有机组成部分。

他们使用该工具来保持开发、测试和生产数据库的同步，并实现高效的团队开发，而无需手动编写对象脚本和为源代码管理系统编写更新脚本。其目的是提供一个高度有效的团队开发模型的洞察，该模型基于 SQL Compare 的使用。

项目环境

该项目有两个开发人员和一个测试人员。项目环境包括两个本地开发 SQL Server 数据库（每个开发人员一个）、一个测试数据库（虚拟）以及生产数据库。

请注意，模式同步主要从一台本地开发计算机（Richard 的服务器）驱动。虽然没有什么能阻止你在每台机器上安装 SQL Compare，但这确实意味着按照这种模型只需要一个 SQL Compare 许可证，假设从安装了 SQL Compare 的机器上，SQL Compare 可以连接到测试环境。

在我们的设置中，测试数据库位于虚拟机上。这是一个“锁定”的环境，测试服务器无法“看到”生产服务器或本地开发服务器。这意味着我们在虚拟机主机上运行了第二个 SQL Compare 副本。

开发模型

这里提出的开发模型只是 SQL Compare 可以纳入的众多模型之一。然而，基于我们对替代模型的个人经验，我们发现它能在小型开发团队中实现最大的生产力，同时保持非常高的可靠性。

它可以这样描述：

1. 在开发开始之前，将生产数据库恢复到三个 SQL Server 实例（两个本地开发实例加上测试实例）中的每一个。
2. 使用 SQL Compare 获取生产数据库的基线模式快照，并将其加载到我们的源代码管理系统（Sourcegear Vault）中。
3. 开发在每个本地开发机器上开始。
4. 当新版本准备好部署到测试机时，SQL Compare 用于在两个开发数据库之间执行双向同步。例如，Richard 会将他数据库中更新的对象推送到 Steven 的数据库。完成此操作后，他会将其新更新的 Steven 的数据库与他自己的数据库进行比较，并将任何不同的对象拉回到他自己的数据库中。此时，两个开发数据库都已更新并同步了所有更改。
5. 将本地开发数据库的新快照保存到源代码管理系统中。
6. SQL Compare 用于比较生产数据库（或基线快照）与当前的本地数据库。会脚本化“安装脚本”，该脚本会将两者同步，并将其保存到源代码管理系统中。
7. 虚拟机主机上的 SQL Compare 用于将测试数据库与 Richard 的本地开发数据库同步。
8. 步骤 4 到 7 将被迭代执行，直到最终版本完成。
9. 当最终版本准备就绪时，将生产数据库恢复到测试机，并在测试机上执行最终安装脚本；然后进行最终测试。
10. 现在已测试的安装脚本将应用于生产数据库。

开发机器之间的**推送-拉取同步**（**步骤 4**）只需几分钟。SQL Compare 生成的同步脚本包含所有必需的依赖对象更改——由于没有手动脚本，因此它可靠且无错误。本质上，这是该模型的**真正**优势。

应该注意的是，由于此开发模型不是由源代码管理系统驱动的，因此在**步骤 4** 中存在合并冲突的可能性。在同步过程中，如果两个开发人员都更新了同一个数据库对象，那么就有总是存在一套更改可能被覆盖的危险。SQL Compare 只能告诉你两个对象不同，并且一旦对某个特定对象执行了同步，在该同步箭头尖端处的数据库中对该对象所做的任何更改都将丢失。

但是，我们认为在小型开发团队中合并冲突是罕见的，而且这并没有真正影响到我们。如果曾怀疑在给定的构建周期内同一对象可能被两个开发人员修改过，那么在同步之前，两个开发人员只需查看 SQL Compare 的差异屏幕即可。

我们可以相当随意地在本地开发和测试数据库之间执行模式同步（**步骤 7**）。这显然发生在主要的项里程碑和交付物时，但除此之外，“按需”进行。在主要的开发阶段，这可能每周发生一次；如果我们正在修复 bug，可能每天发生几次。

如果我们引入了一个严重的 bug，走了一个为期几天的死胡同，或者需要改变我们的方法，保存到源代码管理系统中的 SQL Compare 快照（**步骤 2 和 5**）提供了一个有用的**回滚机制**。SQL Compare 目前不直接与源代码管理集成（即，SQL Compare 模式快照不是“对象粒度”的），因此在少数情况下，当我们需要的帮助是找出某个 bug 可能在何处引入时，我们会使用一个名为 Scream 的免费、公开可用的工具。该工具已集成到我们的源代码管理系统中，并允许我们查看两个 SQL Compare 快照文件之间的差异。

注意：*目前的计划是，SQL Compare 的下一个版本将直接与源代码管理系统集成*。

当为新的网站数据库生成最终安装脚本时，测试该脚本然后将其安装在生产服务器上的过程（**步骤 9 和 10**）是无缝的：我们确信我们在生产服务器上创建的数据库与我们开发的数据库完全一致。

SQL Compare 开发模型与源代码管理模型

我们可以将此开发模型与另一种常见模型进行比较，即单独将数据库对象脚本化进出源代码管理系统。当创建一个新对象时，开发人员会为它创建一个脚本并将其保存在源代码管理中。当对象被修改时，开发人员手动创建一个“更新脚本”（一系列运行 SQL 文件和数据插入脚本的命令），最终将生产数据库与他们的开发数据库同步。

如果做得好，基于源代码管理的模型的主要优点是它提供了直接的对象级版本历史记录和标记。然而，任何使用过此模型的开发人员都会告诉你：它也有缺点。

• 由于（常常很复杂的）对象相互依赖性，管理源代码管理中的**DROP**/CREATE 与**ALTER **过程非常困难。
• 开发人员很容易忘记将修改过的对象添加到源代码管理中，以及/或者未能相应地修改更新脚本。

后者尤其是一个经常令人头痛和痛苦的原因。要*验证*最终的更新脚本是否真实反映了最终的数据库，这是非常困难的。

SQL Compare 驱动的模型消除了这两个痛点。所有依赖的对象都会得到适当的更新，并且永远不会怀疑最终的更新脚本是否真实反映了经过测试的数据库。很难估计这为我们节省了多少开发时间。

当然，如果你确实需要从源代码管理驱动开发，那么一旦生成最终更新脚本，就可以完美地将 SQL Compare 集成到源代码管理模型中。你可以将更新脚本应用于暂存服务器，然后使用 SQL Compare 验证新创建的数据库是否准确反映了最终的开发数据库。SQL Compare 在其可以集成到的不同开发模型的数量方面是多功能的。

其他开发技术

以下是两种可以包含在内的技术，以进一步改进此开发模型。

进行数据更改

在进行一些模式更改后，通常需要加载某些数据来支持这些更改。例如，Red Gate 网站上的新下载过程不再是不可变的步骤序列；它是完全数据驱动的。显然，如果不支持数据的插入，那么就没有下载过程了！

我们使用 SQL Data Compare 生成查找表脚本，并将它们编译成一个“更新后”脚本，该脚本在模式更新后运行。根据数据类的规模，可能可以通过手动方式完成。

当然，更进一步说，如果必要数据的插入能够成为 SQL Compare 模型的一部分，那就更好了。

将最新的模式拉取到测试机

在我们的模型中，更新是从本地开发机推送到虚拟测试机的。虽然这提供了对过程的良好控制，但让测试人员能够将最新的模式文件从源代码管理拉取到测试机，然后用它来同步他们的本地测试数据库会很有用。通过在测试机上运行一个批处理文件，可以很容易地实现这一点，该文件将从持续集成构建环境（zip 文件将包含来自本地开发的最新快照）拉取最新的二进制文件。二进制文件将被部署，然后可以使用 SQL Compare Pro（命令行）将测试数据库与最新快照同步。

摘要

对我们来说，最重要的是 SQL Compare 为开发过程带来的确定性和灵活性。它让我们能够以独立但协调的方式工作，主要原因是将每个本地开发数据库的同步从一项可能耗时且易错的任务减少到几次点击按钮的操作。

当我们把更改从开发推送到测试时，我们知道他们测试的模式与我们开发的模式**完全**相同。如果其中一个人正在进行一个较长的开发周期，另一个人可以修复一些 bug，并在几分钟内将包含模式更改的新版本推送到测试机。

如果我们走了一个为期几天的死胡同，或者需要改变我们的方法，保存到源代码管理中的 SQL Compare 快照提供了一个有用的回滚机制。

我们在此概述的开发模型是经过实践检验的，我们希望它能够帮助您以高度高效和有效的方式使用 SQL Compare。然而，它只是 SQL Compare 可以轻松集成到的众多模型之一。