江苏龙网

  1. 主页 > 生活百科 > >

使用SQL Compare命令行来自动化数据库部署( 三 )

SQL Compare

这是目标的源代码管理脚本位置XML文件（SourceControlAddress v242.xml）：
<?xml version="1.0" encoding="utf-16" standalone="yes"?><ISOCCompareLocation version="1" type="TfsLocation"> <ServerUrl>http://tfs:8080/tfs/projects</ServerUrl> <SourceControlFolder>$/USCAPP/Branches/v242/Database/Schema</SourceControlFolder></ISOCCompareLocation>这是源代码之一（SourceControlAddress v243.xml）：
<?xml version="1.0" encoding="utf-16" standalone="yes"?><ISOCCompareLocation version="1" type="TfsLocation"> <ServerUrl>http://tfs:8080/tfs/projects</ServerUrl> <SourceControlFolder>$/USCAPP/Branches/v243/Database/Schema</SourceControlFolder></ISOCCompareLocation>再一次，我们仅使用Argfile的地址作为唯一参数来调用SQL Compare命令行：
“％programfiles（x86）％ Red GateSQL Compare 13sqlcompare” /Argfile:"shared.xml“在SQL Compare命令行完成其工作之后，在“Shared.sql” 文件中，我们有了可以在目标数据库上运行的升级脚本，以将其升级到最新的主要版本 。
进一步要求
在现实生活中，我们始终需要仔细检查自动生成的脚本，添加检查和控件，以确保例如以正确的顺序将所有必需的升级脚本应用到预期的数据库版本 。我们还需要对SQL Compare的自动生成的部署脚本进行少量添加和自定义，例如处理数据插入或向每个脚本添加标头信息（创建脚本时，版权信息，联系信息等） 。或在每个自动生成的脚本的末尾附加一些动态生成的SQL脚本，以识别客户 。
通过使用自定义迁移脚本修改SQL Compare部署，可以实现很多这样的目标，尽管实际上我们遇到了一些困难，例如它们减慢了SQL Source Control的运行速度或部署前和部署后脚本 。
对我们来说，另一个需要考虑的因素是，SQL Compare迁移和部署前或部署后脚本是静态的，而我们的要求是动态生成的脚本 。相反，我们在Visual Studio中构建了一个简单，轻便的工具，允许开发人员对SQL Compare脚本进行小的动态添加和自定义 。
我避免在这里进行深入研究的另一个复杂性是，对于我们的每个客户，我们的源代码管理干线将客户数据库的所有共享逻辑与包含该组织专有的定制代码的小型例程结合在一起 。在本文中，我演示了如何使用SQL Compare命令行来部署所有客户通用的数据库结构和代码 。尽管该过程与特定于客户的例程基本相同，但是需要进行一些小的调整，以确保始终将独有功能仅部署到该客户的生产数据库中，并且没有任何客户可以看到专门为另一位客户编写的逻辑 。我将在下一篇文章中描述我们如何实现这一目标！
结论
我们的经验是Redgate Source Control和SQL Compare可以协同工作，并且对我们自动化脚本生成过程起到了很大的作用 。SQL Compare允许对其从Git或TFS源代码控制中提取脚本的方式进行非常精细的控制，从而为我们节省了大量手动脚本编写 。我们将看到能够自动生成相应的回滚（降级）脚本以及升级脚本的更多可能性 。它只需要反转我们用于源和目标的变更集并启动SQL Compare命令行即可！它是一种多功能工具 。
 




推荐阅读


上一篇：5G_RAN SA架构介绍

下一篇：梦见很多蝴蝶飞向自己 做梦梦到好多蝴蝶往身上飞