问多阶段部署建议？

EN

我总是为每个部署目标创建cap任务，并在命令行中使用它们：

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

> cap stage deploy

您还可以在每个目标任务中定义自定义任务，例如在暂存过程中进行清理但在生产中不进行清理的部署。

由于这些部署目标任务很少很大，我从来没有真正看到为多阶段安装上限扩展之类的东西的意义，但我想其他人的情况可能有所不同。

我确实认为生产应该与您的其他环境分开，否则会有一种危险，即在阶段中发生错误的过程或类似的行为可能会影响生产性能。

有时，为了便于进行准备，我定义了cap任务，例如从最近的生产转储中释放出数据库并重新加载它。这些任务应该通过一个set变量等来检查它们的部署目标，并拒绝为生产而运行，以防止出现深夜错误。

在您的deploy.rb中放置许多自定义行为是很有诱惑力的，但我发现随着您的环境或cap的更改，这往往会造成很大的困难，需要进行大量的维护工作。

我在更大的环境中看到的另一个实践是拥有一个shell帐户，它可以跟踪稳定的分支，专门设置为充当capistrano控制点。您可以在此输入并运行cap命令，而不是在本地运行。这可以帮助您避免本地签出的deploy.rb有您还没有准备好用于部署到生产的修改的问题。这并不是git与svn之间的问题，但在运行cap命令时，仍然必须仔细考虑他们的本地deploy.rb是什么。

现在，Heroku真的让这件事变得简单了，安永和其他人也就没那么多了。

最好有两个不同的服务器环境:分阶段和生产。我总是忽略测试环境。测试环境的作用类似于生产，但在完成时回滚数据库。在同一服务器上同时运行可能会对生产环境的性能和稳定性产生负面影响。升级gem以在暂存环境中进行测试可能会对生产产生不利影响，并会使您的停机时间减少。

您必须非常警惕，在这两台服务器上都有相同的gem版本。如果一个应用程序的版本在分阶段工作，但由于这种差异而在生产中不起作用，那么它可能会带来麻烦。

我总是有一个控制台窗口打开，准备回滚上一次部署，以防出问题。这个过程真的没有比这更多的东西了。

节省一些钱，买最便宜的分期服务器，你可以。你是唯一一个会用它的人，对吧？确保他们来自同一个提供者。

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