blocks|key|902998|text|最好有两个不同的服务器环境:分阶段和生产。我总是忽略测试环境。测试环境的作用类似于生产，但在完成时回滚数据库。在同一服务器上同时运行可能会对生产环境的性能和稳定性产生负面影响。升级gem以在暂存环境中进行测试可能会对生产产生不利影响，并会使您的停机时间减少。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|902999|您必须非常警惕，在这两台服务器上都有相同的gem版本。如果一个应用程序的版本在分阶段工作，但由于这种差异而在生产中不起作用，那么它可能会带来麻烦。|903000|我总是有一个控制台窗口打开，准备回滚上一次部署，以防出问题。这个过程真的没有比这更多的东西了。|903001|节省一些钱，买最便宜的分期服务器，你可以。你是唯一一个会用它的人，对吧？确保他们来自同一个提供者。|903002|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|J|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|K|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|L|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|M|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|I|$]]

It is better to have two different server environments: staging and production. I always ignore the test environment. The test environment acts like production, but rolls back the database when done. Running both on the same server may negatively affect the performance and stability of the production environment. Upgrading a gem to test in the staging environment may affect production negatively and cost you downtime.

You must be very vigilant that the same gem versions are on both servers. It can spell trouble if a version of an app works in staging but doesn't in production because of this sort of discrepancy.

I would always have a console window open that is ready to roll back the last deployment in case something goes wrong. There really isn't much more to the process than that.

Save yourself some money and buy the cheapest staging server you can. You're the only one that will be using it, right? Just make sure they are from the same provider.

blocks|key|2267090|text|我总是为每个部署目标创建cap任务，并在命令行中使用它们：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2267091|#+deploy.rb
task+:stage+do
++server+10.0.0.1+...
end

>+cap+stage+deploy|code-block|syntax|javascript|2267092|您还可以在每个目标任务中定义自定义任务，例如在暂存过程中进行清理但在生产中不进行清理的部署。|2267093|由于这些部署目标任务很少很大，我从来没有真正看到为多阶段安装上限扩展之类的东西的意义，但我想其他人的情况可能有所不同。|2267094|我确实认为生产应该与您的其他环境分开，否则会有一种危险，即在阶段中发生错误的过程或类似的行为可能会影响生产性能。|2267095|有时，为了便于进行准备，我定义了cap任务，例如从最近的生产转储中释放出数据库并重新加载它。这些任务应该通过一个set变量等来检查它们的部署目标，并拒绝为生产而运行，以防止出现深夜错误。|2267096|在您的deploy.rb中放置许多自定义行为是很有诱惑力的，但我发现随着您的环境或cap的更改，这往往会造成很大的困难，需要进行大量的维护工作。|2267097|我在更大的环境中看到的另一个实践是拥有一个shell帐户，它可以跟踪稳定的分支，专门设置为充当capistrano控制点。您可以在此输入并运行cap命令，而不是在本地运行。这可以帮助您避免本地签出的deploy.rb有您还没有准备好用于部署到生产的修改的问题。这并不是git与svn之间的问题，但在运行cap命令时，仍然必须仔细考虑他们的本地deploy.rb是什么。|2267098|现在，Heroku真的让这件事变得简单了，安永和其他人也就没那么多了。|2267099|entityMap^0|0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|W|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|X|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|Y|8|@]|9|@]|A|$]]|$1|I|3|J|5|6|7|Z|8|@]|9|@]|A|$]]|$1|K|3|L|5|6|7|10|8|@]|9|@]|A|$]]|$1|M|3|N|5|6|7|11|8|@]|9|@]|A|$]]|$1|O|3|P|5|6|7|12|8|@]|9|@]|A|$]]|$1|Q|3|R|5|6|7|13|8|@]|9|@]|A|$]]|$1|S|3|T|5|6|7|14|8|@]|9|@]|A|$]]|$1|U|3|-4|5|6|7|15|8|@]|9|@]|A|$]]]|V|$]]

I've always just created cap tasks for each deploy target and used them on the command line:

<pre><code># deploy.rb
task :stage do
 server 10.0.0.1 ...
end

&gt; cap stage deploy
</code></pre>

You can also define customize tasks inside each target task, such as a deploy that does cleanup in staging, but doesn't in production.

Since these deploy target tasks are rarely very big, I never really saw the point of something like installing the cap extensions for multi-stage, but I suppose other's situations may be different.

I do think production should be separate from your other environments, otherwise there's a danger that misbehaving processes in staging or the like could affect production performance.

Sometimes I define cap tasks for convenience in staging, such as blasting out the database and reloading it from the most recent production dump. These tasks should check their deploy target via a set variable or the like and refuse to run for production as insurance against a late night typo.

It's tempting to put lots of custom behavior in your deploy.rb, but I've found this tends to bite back and require a lot of maintenance effort as your environment or the cap api's change.

Another practice I've seen with larger environments is to have a shell account with a checkout that tracks the stable branch specifically set up to act as the capistrano control point. You ssh in and run cap commands there instead of locally. This can help avoid issues where your local checkout's deploy.rb has modifications that you aren't ready to use with deploying to production. This is less of an issue with git vs svn, but still one must be careful to think about what their local deploy.rb is at the moment they're running cap commands.

Heroku is really making this stuff easy these days, and EY and others aren't exactly far behind.

blocks|key|742183|text|一年多来，我们一直非常成功地使用capistrano多级部署。该系统以与Rails环境文件几乎相同的方式很好地分离了每个阶段的部署文件。它非常容易设置和管理。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|742184|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

We have been using the capistrano multistage deployment very successfully for over a year. The system nicely separates the deployment files for each stage in an almost identical way to the Rails environment files. It was very easy to setup and manage.

What are some best practices and general theory of multi-stage deployment for web apps?

I'm particularly interested in deploying Rails apps using Git, Capistrano, and Passenger, and I've found posts that discuss the nuts and bolts of the process:

<ul>
<li><a href="http://weblog.jamisbuck.org/2007/7/23/capistrano-multistage" rel="nofollow noreferrer">Capistrano: Multistage</a></li>
<li><a href="http://pivotallabs.com/users/jdean/blog/articles/757-introducing-autotagger-easy-multi-stage-deployment-tagging-with-git" rel="nofollow noreferrer">Introducing AutoTagger</a></li>
</ul>

What considerations should I take with regard to each stage (testing, staging, production)? Should the stages be deployed to different physical servers? Any tips or advice about multi-stage deployment? Any snags I should look out for?

best,

Jacob

Multi-stage deployment advice?

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

什么是web应用程序多阶段部署的最佳实践和一般理论？我特别感兴趣的是使用Git、Capistrano和客运部署Rails应用程序，我还找到了一些文章，讨论了这个过程的具体内容：对于每个阶段(测试、阶段、生产)，我应该考虑什么？应该将这些阶段部署到不同的物理服务器上吗？有关于多阶段部署的建议或建议吗？有什么我该注意的障碍...

问多阶段部署建议？
EN

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问多阶段部署建议？EN