使用连续或自动部署时，如何部署数据库？

Question

我正在寻求实施Team City和Octopus Deploy以进行CI和按需部署。但是，数据库部署将变得非常棘手，因为很多旧的.net应用程序使用了混乱的数据库。

展鹏似乎有一个很好的插件，团队市，但价格可能会被绊脚石

你用什么？我很高兴执行脚本，但这是我努力的比较方面（即发生了什么变化）。

Answer 1

我们已经看过RedGate解决方案，几乎已经达到了相同的结论，但不幸的是，这使我们摆脱了这种路线。

我能想到的唯一事情就是根据您现有的数据库生成受版本控制的数据库迁移脚本，然后将其作为构建过程的一部分执行。如果您在将来查看.NET项目（不使用CMS），可能会考虑使用实体框架代码进行第一次迁移。

Answer 2

我记得一直在考虑这个问题，对我来说，似乎有很多信任你必须加入到这种过程中，因为自动部署到开发或测试服务器不是'因为数据可能是可替换的......但是自动更新UAT或生产服务器的想法可能会将这些威胁发送到可能负责数据库的操作团队的背后，或者至少恢复它如果不是很对。尽管如此，我认为它的走向，因为它太容易被数据库部署脚本所吓倒了，而这正是事情被遗忘或遗漏的时候。

我似乎记得使用Red Gate的SQL比较和SQL数据比较工具，因为（我认为）有一种命令行方式，它可以很好地用于脚本部署过程，比如Team City，CruiseControl .Net等

Answer 3

使用关系数据库时，风险和复杂性更多。在一切都是“文档”的NoSQL数据库中，我认为连续部署不是这样的问题。一些对象将具有“旧”数据结构，直到它们通过新发布的代码进行更新。在这种情况下，你的代码需要能够支持不同的数据结构。无论如何，遗漏的属性或者具有不同类型的属性都应该包含在写得很好的防御性编码应用程序中。

我可以看到对生产数据库运行脚本的风险，CI和持续交付的但问题是，这些脚本将运行在其他环境中测试第一，以消除任何“陷阱” :-)

当您实际按下按钮进行部署时，这并不会减少手指交叉和缩小的数量！

Answer 4

我们利用名为RoundhousE的免费工具来处理数据库更改与我们的项目，它是相当容易与Octopus部署使用它。

我们创造了我们的解决方案一个新的项目，称为DatabaseMigration，包括在项目中，我们保持DB变化脚本回旋的文件夹回旋exe文件，然后拿着八达通怎么能之前调用PowerShell脚本优势，期间，和部署后（PreDeploy.ps1，Deploy.ps1和PostDeploy.ps1分别），并增加了一个Deploy.ps1到项目以及在它下面。

$ roundhouse_exe_path =” \ RH。EXE “

$ scripts_dir =” \数据库\数据库名 “

$ roundhouse_output_dir =” \输出”

如果（$ OctopusParameters）{

$ ENV = $ OctopusParameters [ “RoundhousE.ENV”]

$ DB_SERVER = $ OctopusParameters [ “SqlServerInstance”]

$ DB_NAME = $ OctopusParameters [ “数据库名”]

}否则{

$ ENV = “LOCAL”

$ DB_SERVER = “\ SQLEXPRESS”

$ DB_NAME = “DatabaseName” }

& $ roundhouse_exe_pa日-s $ DB_SERVER -d $ DB_NAME -f $ scripts_dir --env $ ENV --silent -o> $ roundhouse_output_dir

在那里，你可以看到我们检查了传递任何章鱼变量（参数）在Octopus运行部署脚本时，否则我们会使用一些默认值，然后我们只需调用RoundhousE可执行文件。

然后，您只需将该项目作为Octopus打包的一部分，然后在Octopus中添加一个步骤来部署该软件包，并将其作为每个部署的一部分执行。

Answer 5

让数据库部署自动化是一个真正的挑战，特别是在尝试执行构建之后，部署许多方法与原生应用程序代码一样。

在构建中，一旦部署了很多，就编译代码并创建二进制文件，然后在环境中复制它们。从数据库角度来看，相当于一次生成脚本并在所有环境中执行它们。这种方法不处理从不同分支合并，进程外的变化（生产中的关键修复）等...

我知道的作品为database deployment automation（免责声明 - 我在DBmaestro工作），因为我听到这个我的客户正在使用构建和按需部署方法。通过这种方法，您可以将数据库增量脚本构建为部署（执行）过程的一部分。使用基线感知分析，解决方案知道是否为更改生成部署脚本或保护目标，不会恢复或暂停，并允许您合并更改并解决冲突。

Answer 6

考虑一个简单的解决方案，我们已经在这个线程成功尝试 - How to continuously delivery SQL-based app?

免责声明 - 我在CloudMunch

Answer 7

工作，我们使用八达通部署和数据库项目的Visual Studio解决方案。

1. 构建代理使用带有dacpac文件的octopack创建nuget包，并在里面发布配置文件并将其推送到NuGet服务器上。
2. 然后发布进程利用SqlPackage.exe实用程序为发布环境生成更新脚本，并将其作为工件添加到发行版中。
3. 以前创建的脚本在SQLCMD.exe实用程序的下一步中执行。

创建和执行步骤的这种分离使我们有可能在两者之间进行手动步骤，以便有人在Live环境上执行脚本之前进行验证，更不用说，该脚本作为工件保存在发布可以随时在任何时候引用。

会有需求我会提供更多的细节和步骤脚本。