如何建立具有连续集成的Redgate SQL源代码控件

Question

我的问题是:在开发团队中管理SQL更改的最佳设置是什么？

我们的团队由4名开发人员组成，每个开发人员都有自己的数据库副本。当向我们的TFS服务器提交SQL/Application更改时，我们希望确保任何构建错误都不会传播给其他开发人员。因此，我们将实施持续的集成，以帮助这一点。

其思想是将1.SQL和应用程序代码更改提交给TFS。2.中央数据库获取SQL更新，然后构建应用程序。3.在构建服务器上执行单元测试。4.如果这些步骤中的任何一个失败，签入将被拒绝，数据库将回滚到提交之前的状态。

设置Redgate SQL源代码以实现这一点的最佳方法是什么？

Answer 1

如果您想使用SQL源代码管理，根据您的需求，这是一个需要考虑的可能设置。

每个开发人员机器的：

• 安装SQL源代码管理
• 将每个开发人员数据库链接到TFS存储库。采用专用数据库作为开发模型。
• 安装SQL提示符可以更容易地编写SQL
• 为编写Server单元测试配置SQL测试

构建服务器上的：

• 安装Redgate DLM自动化 (有简化设置的添加-国家统计局 )
• 配置一个验证构建任务，通过检查可以从头开始成功构建数据库来验证架构
• 配置测试构建任务以运行SQL测试
• 配置同步生成任务以使用SQL更新更新中央数据库
• 运行应用程序单元测试
• 如果测试失败，您可以运行一个自定义脚本来恢复上一次签入，再次使用同步生成任务回滚数据库更改并触发新的生成。您可以使用红门DLM自动化PowerShell cmdlet来完成它。

最后一步可能很棘手。老实说，我更喜欢并建议使用分支，而不是依赖单一的中央数据库。这样，每个开发人员都可以完全独立地工作，只有在每个分支上验证了工作之后，您才能合并主分支中的新更改。

如果您想更进一步并实现部署，您可以使用Redgate DLM自动化部署创建一个发布数据库包，并将您的数据库更改直接从您的构建服务器部署到生产中，或者使用像章鱼展开这样的发布工具。

最后，我还建议您查看一下红门ReadyRoll，特别是如果您正在考虑数据库更改的迁移优先方法。

正如您所看到的，使用Redgate工具来管理数据库更改有不同的方法，并且没有单一的最佳方法来设置它们。它总是取决于您需要解决的具体需求和问题。

希望这能有所帮助。

Answer 2

您可以使用数据库工程。它可以包含整个数据库模式和存储过程。在构建过程中，它将验证存储过程是否与架构匹配。

然后在构建定义中启用门控签入选项，只有当提交的更改合并并成功生成时，它才接受签入。

对于写入数据库的数据，它基于您的测试方法，您可以设置方法，以便在测试失败时删除数据，或者不应该写入真正的数据库。相反，您应该模拟数据库类。这样，您实际上不必连接和修改数据库，因此不需要进行清理。

有关更多信息，请参考以下文章：

• 如何与数据库进行单元测试交互
• Junit测试后的数据库清理

​

​