使用SQL Server部署数据库更改的简单方法是什么?

您可以经历不同层次的复杂性:

• 如果您有手动创建的更新脚本,并且只是在寻找一种将这些脚本轻松应用到各种服务器的方法,请检查 SSW SQL Deploy 由SSW咨询公司提供。它可以很好地处理这种情况

• 如果您倾向于使用更多的数据库差异方法,那么Red Gate的 SQL Compare (已经提到)和 SQL Packager 做一个很棒的组合。您可以将数据库在新旧之间进行区分,然后将更改应用到一个漂亮的包中-作为一个exe或c项目

• 如果你想要一个真正的、端到端的、经过深思熟虑的方法(有点学习曲线),那就去看看。 Innovartis' DBGhost 方法。如何处理数据库开发和增量更新是一个完整的方法/技术。它非常强大,看起来很有前途——但它是一种“要么全部要么全部都不做”的方法:要么你买了它,然后端到端地使用它,要么你不买。

希望这有点帮助!

Redgate有一个工具 SQL Compare 比较数据库并生成要同步的脚本。我们曾经使用过它,但最近使用您描述的相同过程切换到手动脚本。使用手动的、细粒度的、具有唯一版本号的脚本已经很好地解决了问题。

我们将升级脚本集成到单元测试中,这样它们就可以作为连续集成的一部分与代码一起进行测试。我认为这是“一步建成”的重要组成部分。

看看这篇博文。我在几个项目中使用过任何数据库版本的这种单一更新脚本,它工作得非常好。

http://blogs.msdn.com/danhardan/archive/2007/03/30/database-change-scripts-mambo-style.aspx

您可能需要稍微调整工作流以适应您的工作流和/或更新template.sql文件,但总的来说,我发现这是一种非常可靠的DB部署方法。

编辑:只是想详细说明我是如何使用这种技术的。基本上,我的所有DB修订脚本都被放入源代码管理中。然后,作为构建框上的后期构建步骤,这个mambo工具在scripts目录下运行,将脚本滚动到事务所包含的单个脚本中,以便在出现任何问题时进行回滚。然后,安装程序足够智能,可以查找.sql脚本以针对现有数据库运行。

这样做的原因是,总成型的脚本检查以查看单个脚本的每个部分已经针对所需的数据库运行。因此,只运行最新的脚本。需要注意的是,一旦脚本签入源代码管理并被部署,就不能对其进行编辑,因为跟踪表已经认为脚本已经运行。对于我处理过的项目来说,这很好,因为我们只是在脚本文件夹中添加了另一个脚本。

希望我能很好地解释这个过程,以便理解。它并没有那么复杂,如果该方法适用于您的项目,它会非常有用。

第一个问题的答案是“现在我想知道,这是否意味着部署构建(以便客户可以更新其部署)?

我相信Joel测试2不是用于部署到Prod的移动,而是用于开发期间的连续集成。

至于prod中的数据库更改,它们都应该通过脚本完成,作为事务卷展栏的一部分,或者在数据库备份之后完成。如果卷展栏中出现故障,您总是希望能够向后导航。

将数据库开发为一组相互依赖的补丁。然后使用类似的工具 https://github.com/LuvDaSun/sqlpatch (由我)生成用于部署的SQL文件。

sqlpatch将按正确的顺序对修补程序进行排序,并确保每个修补程序都执行一次,即使同一脚本运行了两次。

此策略可用于在CI/CD环境中部署数据库。这使得部署和推到分支一样容易。

有一些应用程序可以同步数据库,但我认为你最好做你正在做的事情。编写脚本更新数据库使您能够处理错误并运行事务。这被认为是最佳实践。

微软自己介绍 Data-tier applications 在SQL 2012中,作为部署和升级数据库的免费选项。

我使用并喜欢这个工具,包括用于生产部署。