具有持续集成的 SQL Server 数据库管理

Question

假设我们有一个持续集成服务器。 当我签入时，后挂钩会拉取最新代码，运行测试，打包所有内容。 自动化数据库更改的最佳方法是什么？

理想情况下，我会构建一个安装程序，它可以从头开始构建数据库，也可以使用某种自动同步方法更新现有数据库。

Answer 1

我最近遇到了 一篇文章，可能有用。

作者解释了一些最佳的持续集成实践，包括测试、处理和自动化。

以下是一些关键要点：

• 在许多商店中，代码在提交时进行了单元测试。 对于数据库，最好立即针对 QA 数据库按顺序运行所有单元测试，而不是开发，作为测试步骤的一部分。
• 测试步骤是任何 CI/CD 过程的关键部分。 测试脚本（包括单元测试本身）也应该在源代码控制中进行版本控制，在构建步骤中提取并执行
• 从生产中提取数据作为一种快速权宜之计很有吸引力，但绝不是一个好主意
• 最好的方法是使用工具或脚本来快速、重复且可靠地为事务表创建综合测试数据
• 运行单元测试来生成供人类使用的手动摘要结果违背了自动化的目的。 我们需要机器可读的结果，可以允许自动化流程中止、分支和/或继续。
• 运行 CI 流程需要 100% 所有测试都通过，如果工作流管道被自动设置为在失败时停止（它应该如此），则类似于根本没有 CI。 为了穿针引线，测试应该内置阈值，这将根据测试失败的百分比或在某些情况下，如果某些高优先级测试失败而引发错误。
• 所有流程最终都应生成通过或失败的布尔结果，但某些非自动化流程可以轻松进入 CI 工作流程管道（例如单元测试）。 软件应该即插即用到任何工作流程管道中，接受已知的输入并产生预期的输出——例如通过、失败。
• CI/CD 过程应在失败时中止，并应立即发送通知电子邮件，而不是继续循环管道。
• 在修复上次构建中的任何错误之前，CI 过程不应再次循环。 一旦失败，整个团队都应该收到失败通知，包括尽可能多的失败原因的详细信息。
• 如果管道从开始到结束需要 1 小时才能完成（包括所有测试），则所有构建间隔应设置为不少于一小时，并且所有新提交应排队，并应用于下一个构建。
• 自动化脚本中不应存在纯文本密码

Answer 2

如果您有机会定义和控制整个数据库管理和数据库创建过程，请认真查看 DB Ghost - 它不仅仅是一个工具 - 它是一个过程。

如果您喜欢它并且能够实施它，您将获得丰厚的回报 - 但这有点像“全有或全无”的方法。 受到推崇的。

Answer 3

我会警告不要使用数据库备份作为开发工件，大多数 CI 最佳实践建议您将架构、过程、触发器和视图作为一流的开发工件来管理。 副作用是，您可以更进一步，并在需要时使用它们构建新的数据库，理想情况下您还有一些可以推送到数据库中的数据。

这里有一个悬崖笔记版本，可以让你入门，但是这个领域还有很多东西：
http://www.infoq.com/news/2008/02/versioning_databases_series

我也喜欢斯科特·安布勒（Scott Ambler）在这里提出的一些想法，该网站很好，但是这本书对于如此一组困难的问题却出人意料地深入。
http://www.agiledata.org/
http://www.amazon.com/exec/obidos/ASIN/0321293533/ambysoftinc< /a>

Answer 4

Red Gate 是一个非常强大的解决方案，并且开箱即用。
但最好的事情是您可以将其与持续集成流程集成。 我将它与 Msbuild 和 Hudson 一起使用。
快速解释它是如何工作的：
http://blog.vincentbrouillet.com/post /2011/02/10/Database-schema-synchronization-with-RedGate

如果您需要了解更多信息，请随时询问

Answer 5

使用 SQL 源代码管理和 SQL Compare Pro 命令行的 Red Gate 方法在此处详细介绍了代码示例：

Troy Hunt 在 Simple Talk 上写了一篇题为“SQL Server 数据库的持续集成”的文章：
http://www.simple-talk.com/content/article.aspx ？文章=1247

Answer 6

你看过FluentMigrator吗？ 默认下载包括可以轻松添加到 CI 中的 Nant 脚本。 免费、开源且易于使用。 适用于多种数据库。

Answer 7

DB Ghost 的最新版本（5.0）不会遇到“非 ASCII 字符”问题（它只是意味着文件是 UTF8 编码的），并且它应该能够完全满足您的需要。

此外，如果您愿意，这些工具实际上可以独立使用来执行各种功能（脚本编写、构建、比较、升级和打包），只是将它们一起使用可以提供完整的端到端流程，从而提高整体价值大于其各部分之和。

本质上，要更改模式，您需要更新单个对象创建脚本和每个表插入脚本（用于参考数据），这些脚本位于源代码控制之下，就像您开发“第一天”新建数据库一样。 DB Ghost 工具用于通过将这些脚本构建到全新的数据库中（如果需要，使用持续集成）然后比较和升级目标数据库（可以是生产数据库的副本）来实现整个过程。 此过程会生成一个增量脚本，可在上线期间在实际生产数据库上使用。

您甚至可以生成 Visual Studio 数据库项目并将其添加到您当前拥有的任何解决方案中。

马尔克

Answer 8

我知道这篇文章很旧，但我们有一个新的解决方案，采用以下方法：

1. 开发人员编写单独的 SQL 更改脚本并将其提交到源代码
   控制。
2. 我们的程序 (OneScript) 从
   源代码控制，对它们进行过滤和排序，并生成一个
   发布脚本文件。
3. 然后将该发布脚本文件应用于
   数据库做一个发布。

我们的主页此处更详细地解释了此过程，并提供了一个示例的链接，该示例自动执行这些步骤Subversion 挂钩。 因此，提交后不久，开发人员就会收到一封电子邮件，说明发布是否成功或有错误。 包含 PowerScript 代码。

免责声明 - 我在制作 OneScript 的公司工作。