多阶段部署建议？

Question

Web应用程序的多阶段部署的一些最佳实践和一般理论是什么？

我使用Git，Capistrano的，而客运应用部署的Rails特别感兴趣，我发现职位，讨论过程的螺母和螺栓：

• Capistrano: Multistage
• Introducing AutoTagger

对于每个阶段（测试，分期，生产）我应该考虑什么？这些阶段是否应该部署到不同的物理服务器？有关多阶段部署的任何提示或建议？我应该注意的任何障碍？

最好，

雅各

Answer 1

最好是有两个不同的服务器环境：分期和生产。我总是忽略测试环境。测试环境就像生产一样，但完成后回滚数据库。在同一台服务器上运行可能会对生产环境的性能和稳定性产生负面影响。升级在分段环境中测试的gem可能会对生产产生负面影响，并会降低停机时间。

您必须非常警惕，相同的gem版本在两台服务器上。如果应用程序的版本在分期中工作，但由于这种差异而无法投入生产，则可能会造成麻烦。

我总是会打开一个控制台窗口，准备好回滚最后一次部署以防出现问题。这个过程实际上并没有太多的东西。

为自己节省一些钱，购买最便宜的登台服务器即可。你是唯一一个会使用它的人，对吧？只要确保他们来自同一供应商。

Answer 2

我一直在刚刚创建的每个部署目标帽任务，并利用它们在命令行上：

# deploy.rb 
task :stage do 
    server 10.0.0.1 ... 
end 

> cap stage deploy 

您还可以定义自定义每个目标任务内的任务，比如，做清理的部署分期，但不在生产中。由于这些部署目标任务很少很大，我从来没有真正看到像多级安装帽扩展这样的点，但我想其他人的情况可能会有所不同。

我确实认为生产应该与其他环境分开，否则存在舞台上不合理的流程会影响生产性能的危险。

有时我为了便于分期而定义上限任务，比如爆炸数据库并从最近的生产转储中重新加载它。这些任务应该通过设置变量或类似的东西来检查他们的部署目标，并拒绝运行生产作为对付深夜错字的保险。

在你的deploy.rb中放置很多自定义行为是很诱人的，但我发现这往往会反弹，并且需要大量的维护工作，因为你的环境或cap api的改变。

我在大型环境中看到的另一种做法是拥有一个带有结帐的外壳帐户，该帐户可以跟踪专门设置为Capistrano控制点的稳定分支。你ssh进入并在那里运行cap命令而不是本地。这可以帮助避免在您的本地结帐的deploy.rb进行修改时发生的问题，这些修改尚未准备好用于部署到生产环境。这对于git vs svn来说并不是什么问题，但是仍然需要小心地考虑一下他们在运行cap命令时他们的本地deploy.rb是什么。

这几天Heroku真的让这个东西变得简单了，而EY和其他人并没有完全落后。

Answer 3

我们一直在非常成功地使用capistrano多级部署一年多。系统以与Rails环境文件几乎完全相同的方式很好地将每个阶段的部署文件分开。这很容易设置和管理。