我正在考虑按需实施Team City和Octopus Deploy for CI和Deployment。但是，数据库部署将变得棘手，因为许多旧的.net应用程序都带有凌乱的数据库。
Redgate似乎对Team City有一个不错的插件，但价格可能会遇到绊脚石
你用什么？我很高兴执行脚本，但这是比较方面（即已发生变化）我正在努力。
答案 0 :(得分：3)
我们使用一个名为RoundhousE的免费工具来处理我们项目的数据库更改，并且使用Octopus Deploy很容易使用它。
我们在我们的解决方案中创建了一个名为DatabaseMigration的新项目，包括项目中的RoundhousE exe，我们保留RoundhousE的db更改脚本的文件夹，然后利用Octopus如何在之前，期间和之前调用powershell脚本。部署之后（分别是PreDeploy.ps1，Deploy.ps1和PostDeploy.ps1）并将Deploy.ps1添加到项目中，其中包含以下内容：
$ roundhouse_exe_path =＆＃34;。\ rh.exe＆＃34;
$ scripts_dir =＆＃34;。\ Databases \ DatabaseName＆＃34;
$ roundhouse_output_dir =＆＃34;。\ output＆＃34;
if（$ OctopusParameters）{
$ env = $ OctopusParameters [＆＃34; RoundhousE.ENV＆＃34;]
$ db_server = $ OctopusParameters [＆＃34; SqlServerInstance＆＃34;]
$ db_name = $ OctopusParameters [＆＃34; DatabaseName＆＃34;]
}其他{
$ ENV =＆＃34; LOCAL＆＃34;
$ db_server =＆＃34;。\ SqlExpress＆＃34;
$ db_name =＆＃34; DatabaseName＆＃34; }
＆amp; $ roundhouse_exe_path -s $ db_server -d $ db_name -f $ scripts_dir --env $ env --silent -o＆gt; $ roundhouse_output_dir
在那里你可以看到我们在哪里检查八达通运行部署脚本时传入的任何章节变量（参数），否则我们使用了一些默认值，然后我们只需调用RoundhousE可执行文件。
然后你只需将该项目作为Octopus打包的一部分，然后在Octopus中添加一个步骤来部署该程序包，它将作为每个部署的一部分执行。
答案 1 :(得分：2)
我们已经看过RedGate解决方案并且几乎得出了相同的结论，不幸的是，这使得我们的成本偏离了这条路线。
我能想到的唯一事情是根据您现有的数据库生成受版本控制的数据库迁移脚本，然后在构建过程中执行这些脚本。如果您将来要查看.NET项目（不使用CMS），可能会考虑使用实体框架代码进行首次迁移。
答案 2 :(得分：2)
我记得有一段时间回顾这一点，对我来说，似乎有很多信任你必须投入这种过程，因为自动部署到开发或测试服务器不是这么糟糕，因为数据可能是可以替换的......但是自动更新UAT或生产服务器的想法可能会让运营团队的后台发送，他们可能负责数据库，或者至少可以恢复它这不太对。
话虽如此，我确实认为它的方式可行，因为它太容易被数据库部署脚本吓到了，而且当事情被遗忘或遗漏时。
我似乎记得使用Red Gate的SQL Compare和SQL Data Compare工具，因为（我认为）有一个命令行方式，它可以很好地处理脚本部署过程，如Team City，CruiseControl。网等等。
答案 3 :(得分：0)
使用关系数据库时，风险和复杂性会更多。在NoSQL数据库中，一切都是“文档”，我想连续部署并不是一个问题。某些对象将具有“旧”数据结构，直到通过新发布的代码更新它们。在这种情况下，您的代码可能需要能够支持不同的数据结构。缺失属性或具有不同类型的属性应该包含在编写良好，防御性编码的应用程序中。
我可以看到针对生产数据库运行脚本的风险，但CI和持续交付的重点是这些脚本将在其他环境中运行和测试，以消除任何“陷阱”： - ）
当您实际按下按钮进行部署时，这不会减少手指交叉和翘曲的数量！
答案 4 :(得分：0)
拥有数据库部署自动化是一项真正的挑战，特别是在尝试将多种方法部署到本机应用程序代码时执行构建时。
在构建一次部署许多之后，您编译代码并创建二进制文件，然后在环境中复制它们。从数据库的角度来看，相当于生成脚本一次并在所有环境中执行它们。这种方法不处理来自不同分支的合并，进程外更改（生产中的关键修复）等......
我所知道的database deployment automation（免责声明 - 我在DBmaestro工作）正如我从客户那里听到的那样，正在使用构建和按需部署方法。使用此方法，您可以构建数据库增量脚本，作为部署（执行）过程的一部分。使用基线感知分析，解决方案知道是否为更改生成部署脚本或保护目标，而不是将其还原或暂停，并允许您合并更改并解决冲突。
答案 5 :(得分：0)
考虑一下我们在此主题上成功尝试的一个简单解决方案 - How to continuously delivery SQL-based app?
免责声明 - 我在CloudMunch工作
答案 6 :(得分：0)
我们在visual studio解决方案中使用Octopus Deploy和数据库项目。
SqlPackage.exe实用程序为发布环境生成更新脚本，并将其作为工件添加到发布中。SQLCMD.exe实用程序在下一步中执行的先前创建的脚本。 创建和执行步骤的这种分离使我们有可能在两者之间进行手动步骤，以便有人在Live环境中执行脚本之前进行验证，更不用说，在发布中保存为工件的脚本始终可以在以后任何时候都可以参考。
是否有需求我会提供更多细节和步骤脚本。