数据库开发的持续集成

持续集成就是要确保您的软件项目的全部内容能够自动且频繁地构建和测试。因此，在大多数情况下，每次代码提交都会触发一次构建，然后对构建运行一套单元测试和集成测试。这意味着您可以快速验证您的更改，并及时收到问题的通知。

Martin Fowler 在 2000 年撰写了《持续集成的权威文章》，所以这并非新概念。事实上，对于许多从事应用程序代码开发的团队来说，它已经是标准实践。

但对于数据库层来说，情况要复杂一些。

为什么持续集成对数据库是个问题？

数据库代码与应用程序代码不同。它不像一组可以随意复制的文件那样整洁，而且您无法对其进行编译。这意味着第一个问题是，没有东西可以放入源代码管理。除了更改跟踪和共享更改的好处之外，源代码管理还为您提供了一个“唯一真实版本”的代码存放位置。在持续集成中，这就是您从中部署的位置。

还有 SQL 是声明式的，DDL 语句会修改数据库的当前状态。因此，每次进行更改时，您都必须考虑引用完整性，并确保数据得到保留。

实际上，这意味着需要大量的迁移脚本。您需要确定源数据库的状态，与目标数据库的差异，然后编写脚本以正确地在两者之间进行迁移。这非常耗时，并且可能导致大量错误。

解决问题：源代码管理和部署

一个理想的解决方案应该能够让您将数据库纳入源代码管理，并自动创建更改脚本。它将包括数据库架构以及应用程序所需的任何静态数据。数据库将与应用程序代码一起纳入源代码管理，并由构建系统从中部署。

本文的其余部分将概述如何使用 SQL Developer Bundle，特别是 SQL Source Control，来实际实现这些过程。

首先要做的是将数据库纳入源代码管理。SQL Source Control 本身并不是一个源代码管理系统。它是一个 SQL Server Management Studio 的插件，可以将 SSMS 与您现有的源代码管理系统连接起来。

当前版本支持 Subversion 和 Team Foundation Server。即将推出的 SQL Source Control 2.1 将支持任何具有命令行界面的源代码管理系统，并初步内置 SourceGear Vault 和 Mercurial 支持。

因此，要进行设置，您需要将数据库链接到您的源代码管理系统。

您输入您的源代码管理仓库的详细信息，链接数据库，然后提交对象。

从版本 2 开始，您还可以选择对静态数据进行源代码管理。为此，请在对象资源管理器中右键单击数据库，然后单击“链接/取消链接静态数据…”。将显示一个对话框，让您选择要进行源代码管理的数据的表。

到了部署的时候，您需要再次将数据库从源代码管理中取出。为了支持这一点，SQL Compare 和 SQL Data Compare 具有命令行界面，您可以在构建服务器上使用它们，例如与 MS Build、NAnt 或 TeamCity 一起使用。

这是一个从 Team Foundation Server 部署 AdventureWorks 数据库的命令行脚本示例。

cd "C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE" 
tf get "C:\Scripts\AdventureWorks" /version:T 
cd "C:\Program Files\Red Gate\SQL Compare 8" 
sqlcompare /scr1:"C:\Scripts\AdventureWorks" 
/s2:TestingServer\SQL2008 
/UserName2:TestUser 
/db2:AdvWrksTst 
/Report:"C:\SchemaDiffReport.html" 
/ReportType:Interactive 
/ScriptFile:"C:\SchemaSyncScript.sql" 
/sync 
cd "C:\Program Files\Red Gate\SQL Data Compare 8" 
sqldatacompare /scr1:"C:\Scripts\AdventureWorks" 
/s2:TestingServer\SQL2008 
/UserName2:TestUser 
/db2:AdvWrksTst 
/o:Default 
/ScriptFile:"C:\DataSyncScript.sql" 
/sync

命令行已在线文档化——SQL Compare 的文档在此，SQL Data Compare 的文档在此。但简而言之，以下是其中的内容：

• tf get "C:\Scripts\AdventureWorks" /version:T 是 TFS 命令，用于将本地副本更新为数据库的最新源代码管理版本。
• C:\Scripts\AdventureWorks 是您的本地文件夹的文件路径。
• sqlcompare /scr1:"C:\Scripts\AdventureWorks" 将本地文件夹指定为架构比较的源。
• /s2:TestingServer\SQL2008 指定架构同步（部署）的目标服务器。
• /UserName2:TestUser 是目标服务器的用户名。
• /db2:AdvWrksTst 指定 TestingServer\SQL2008 上的目标数据库。
• /Report:"C:\SchemaDiffReport.html" 生成一个架构差异报告，并将其写入指定文件。
• /ReportType:Interactive 指定报告的格式，在此情况下为详细的交互式 HTML 格式。
• /ScriptFile 保存用于迁移更改的 SQL 脚本副本。
• /sync 同步数据源，使 AdvWrksTst 与 AdventureWorks 相同。
• sqldatacompare /scr1:"C:\Scripts\AdventureWorks" 将本地文件夹指定为数据比较的源。
• /ScriptFile:"C:\SchemaSyncScript.sql" 保存用于迁移架构更改的 SQL 脚本副本。
• /ScriptFile:"C:\DataSyncScript.sql" 保存用于迁移数据更改的 SQL 脚本副本。

本质上，该脚本从源代码管理获取最新数据库版本的副本，并将其部署到测试服务器，生成详细的迁移报告。

结论

持续集成使开发项目更加高效——可以更早地捕获 bug，并提供快速验证。长期以来，数据库不仅被排除在持续集成之外，而且根本没有源代码管理。

本文介绍的工具提供了源代码管理和部署自动化，让您可以将数据库代码与应用程序开发流程保持一致。

这只是一个关于将数据库纳入持续集成流程的快速概述。Red Gate 关于持续集成的白皮书以及博主 Troy Hunt 在其关于自动化数据库发布的文章中对此进行了更详细的阐述。

如果您想自己尝试一下，可以下载 SQL Developer Bundle 的免费试用版。