彩票走势图

SQL Compare是一款比较和同步SQL Server数据库结构的工具。现有超过150,000的数据库管理员、开发人员和测试人员在使用它。当测试本地数据库，暂存或激活远程服务器的数据库时，SQL Compare将分配数据库的过程自动化。

点击下载SQL Compare试用版

本文介绍了如何应对由于部署期间进行的各种检查和测试以及修复而导致的任何数据库漂移。

想象一下。Deb DBA刚在staging中签出了一个新版本的数据库。她突然发现该版本已“漂移”。从版本控制部署的是版本6.3.5，但是自那时以来，迁移脚本似乎有了一些微小但重要的更改。NVARCHAR数据类型必须增加大小以避免被截断。性能测试中存在一个愚蠢的故障，因为有人弄错了索引。安全团队还根据用户输入（未使用parameter）发现了一些已执行代码的问题。他们修复了存储过程，因为这样做比解释过程更容易。有一个讨厌的CHECK约束，它会触发非常好的数据。测试团队对此进行了处理。当发布通过管道时，他们依次更改迁移脚本。

DBA被告知要发布此版本，因为企业对其包含的新功能有很大的压力，并且所有参与管道开发的人员都同意，经过一个不稳定的开始之后，现在已经可以了。她是做什么的？这些更改已很好地记录在脚本中。他们应该处于源代码控制中。她不能直接访问源代码控制系统，只有开发中的Derek可以访问SQL Compare。

Deb的难题是这个。准备阶段的数据库是候选版本，并且其迁移脚本已准备就绪，经过测试并可以很好地签出，但该数据库不再是v6.3.5。在负责任地从登台发布到生产之前，她需要它成为源代码控制中的新版本6.3.6。

首先也是最重要的事情是创建一个表示临时版本的时间点构建脚本。SSMS可以做到这一点，并且默认设置很好。

从SSMS获取构建脚本

在SSMS的对象浏览器窗格上，单击服务器的“数据库”项，然后右键单击数据库的名称。您会看到一个上下文菜单。找到通向子菜单的“任务”项目。这有一个项目“Generate Scripts…”。单击此，您将到达脚本编制向导。在介绍性页面之后，您将看到此内容。

您会看到我输入了想要作为脚本目标的文件的名称和位置。有一个“高级”按钮，可让您精确指定脚本的使用方式。这有点像向一位过于热心的咖啡师点咖啡。幸运的是，您可以忽略该按钮，因为默认设置可以使我们满意。单击“下一步”，您将看到以下内容：

您，或者说Deb DBA，现在差不多完成了。Deb现在要做的就是给脚本加注解，以描述谁在哪里做过什么以及在哪里做（她在每个评论中都包含一个#，以便于查找。）然后，她将脚本发送给开发中的Derek。

更新源代码管理：将更改添加到对象源

下一步是将更改添加到源代码管理中，为此，我们将使用SQL Compare。

您，或者说Derek，应该创建一个目录并将构建脚本放入其中。该脚本应该是目录中的唯一文件。目标是本地GitHub目录中版本6.3.5的源代码目录。请注意：SQL Compare不正式支持使用SSMS构建脚本作为源。您将看到一些警告，指出“忽略了非模式语句”，但是请坚持并单击“继续，而不解决错误 ”，并且SQL Compare将在源中生成其通常的对象列表，这些对象与目标中的对象不同。

Derek现在可以将检测到的更改部署到本地GitHub目录，以更新对象级源，使其版本为6.3.6。他还可以节省6.3.5到6.3.6迁移脚本的初始剪切，该脚本将由SQL Compare强制生成。

在不同的情况下，目标可能是空的源目录，在这种情况下，Derek在开发系统上将具有有关Staging数据库当前版本的“参考构建”。

将更改的文件提交到GitHub

我们假设您使用的是Github或Git。尽管开发中的Derek可以以自己的名字来进行更改，但这并不安全，因为人们有一天会忘记这一插曲和怪罪Derek的全部细节。这里的目的是创建一个新版本，由从事Git列出工作的人员作为共同作者。为此，他们的电子邮件应位于配置设置中。

如果Derek知道谁做了什么，则可以作为更改发行版的人来提交。例如，Timothy Tester可能已添加索引。可以Timothy的名义进行这种更改。

Derek Developer现在对Deb进行了批准。现在，由于对迁移脚本的各种更改已在逐步显现之前已经在阶段中进行了有效的测试，因此Deb DBA在发布之前只有一项最终任务。她将迁移脚本中的版本号更改为6.3.6。

结论

可以很高兴地假设我们都一如既往地实践各种有关持续交付手册的方法。问题是在数据库应用程序的部署中必须检查许多因素。我们可以鼓励所有人“向左移动”，以确保发布候选版本是完美的，但有时我们必须对务实的决定做出反应。SQL Compare很灵活；它可以应对偶发性问题，否则这些问题可能会阻止部署停滞不前。

任何数据库驱动的应用程序中的协作都应涵盖整个发行链，包括质量保证和操作，以确保单个发行版的复杂性大大降低，发布频率更高。如果团队决定通过处理较小的问题而不是延迟发布来减少候选发布者的分类，那么作为团队成员，我们当然要确保团队流程能够足够灵活地做到这一点。

相关产品推荐：

SQL Prompt：SQL语法提示工具

SQL Toolbelt：Red Gate产品套包

SQL Monitor：SQL Server监控工具