【问题标题】:SQL Server Database Management with Continuous Integration具有持续集成的 SQL Server 数据库管理
【发布时间】:2009-01-01 17:26:44
【问题描述】:

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

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

【问题讨论】:

    标签: sql-server database continuous-integration


    【解决方案1】:

    我最近遇到了an article,可能有用。

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

    以下是一些关键要点:

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

    【讨论】:

      【解决方案2】:

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

      如果您喜欢它并且可以实施它,您将获得丰厚的回报 - 但它有点像“全有或全无”的方法。推荐。

      【讨论】:

      • 我们也使用 DB Ghost(带有 CC.NET)。唯一的抱怨是,如果您在存储过程脚本中有非 ASCII 字符(当您使用其 DB 项目时 Visual Studio 所做的事情),它就会出错。
      【解决方案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

      【讨论】:

        【解决方案4】:

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

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

        【讨论】:

          【解决方案5】:

          使用 SQL Source Control 和 SQL Compare Pro 命令行的 Red Gate 方法在此处通过代码示例进行了详细说明: http://downloads.red-gate.com/HelpPDF/ContinuousIntegrationForDatabasesUsingRedGateSQLTools.pdf

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

          【讨论】:

            【解决方案6】:

            您看过 FluentMigrator 吗?默认下载包括易于添加到 CI 中的 Nant 脚本。免费、开源且易于使用。适用于各种数据库。

            【讨论】:

              【解决方案7】:

              最新版本 (5.0) 的 DB Ghost 没有遇到“非 ASCII 字符”问题(它只是意味着文件是 UTF8 编码的),它应该能够完全满足您的需求。

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

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

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

              马尔克

              【讨论】:

                【解决方案8】:

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

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

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

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

                【讨论】:

                  猜你喜欢
                  • 1970-01-01
                  • 1970-01-01
                  • 1970-01-01
                  • 2018-05-19
                  • 1970-01-01
                  • 1970-01-01
                  • 2012-09-16
                  • 1970-01-01
                  • 1970-01-01
                  相关资源
                  最近更新 更多