如何使用持续集成设置Redgate SQL源代码管理

Question

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

我们的团队由4名开发人员组成，每个开发人员都拥有自己的数据库副本。 在将SQL /应用程序更改提交到我们的TFS服务器时，我们希望确保任何构建错误都不会传播给其他开发人员。因此，我们将实施持续集成以协助实现此目标。

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

设置Redgate SQL源代码实现此目的的最佳方法是什么？

Answer 1

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

对于每台开发者机器：

• 安装SQL Source Control
• Link each developer database to your TFS repository使用专用数据库作为开发模型。
• 安装SQL Prompt以更轻松地编写SQL
• 配置SQL Test以编写SQL Server的单元测试

在构建服务器上：

• 安装Redgate DLM Automation（Add-Ons以简化设置）
• 通过检查数据库是否可以从头开始成功构建来配置Validate build task以验证架构
• 配置Test build task以运行SQL测试
• 配置Sync build task以使用SQL更新更新中央数据库
• 运行应用程序单元测试
• 如果测试失败，您可以运行自定义脚本以还原最后一次签入，再次使用同步构建任务来回滚数据库更改并触发新构建。您可以使用Redgate DLM Automation PowerShell cmdlets来执行此操作。

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

如果您想进一步实施部署，可以使用Redgate DLM Automation Deployment创建发布数据库包，并直接从构建服务器或使用Octopus Deploy等发布工具将数据库更改部署到生产环境中

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

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

希望这有帮助。

Answer 2

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

然后在构建定义中启用 Gated Check-in 选项，仅当提交的更改合并并成功构建时，它才接受签入。

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

有关详细信息，请参阅以下文章：

• How To Unit Test – Interacting with the Database
• Database cleanup after Junit tests