Why use a Rails-like deployment mechanism over 'git pull' for releasing?
To release my centralized webapp, I COULD have a vhost pointed to some directory and then just do a ‘git pull’ when I want to release, updating the files. But Rails has a different deployment mechanism: it copies files to a subdirectory and then points a symlink (‘current’) to that new subdirectory.
I understand that it probably more acceptable to do a Rails-like deployment because the release is built in some directory, and then the symlink is pointed to that directory, so this is much faster, and it’s less likely that users would experience weird issues while a release is happening.
- Push to Other Branch Git
- Capistrano + Git : repository local to production server
- What is the cleanest and easiest way to share custom RSpec matchers across multiple ruby/rails projects?
- Put a Rails app in public git, keep private details private
- Rails 4: Heroku push rejected / Gemfile Issues / GIT Issues
- Elastic Beanstalk - Rails Deploy using Github Gems
Are there any other advantages to the Rails approach? Or, is a ‘git pull’ approach actually more widely accepted?
4 Solutions collect form web for “Why use a Rails-like deployment mechanism over 'git pull' for releasing?”
I’ll replace “the Rails approach” in your question with “the Capistrano approach.” There are a ton of advantages to using Capistrano. You can deploy from any machine over SSH. You can
cap:rollback to instantly undo a deploy should you find a mistake. You can run pending migrations on the production database before the deploy happens. You can instantly deploy to several machines if you have different machines in different roles. Once you have it installed, do
cap -T to see all of your options.
You are describing the behavior of Capistrano, which is common with Rails projects, but not part of Rails itself. One option with Capistrano involves pulling to your remote server with git, which greatly speeds up deployments over pushing tar balls.
One major advantage of using cap is that you can define hooks which perform tasks after deployment like sym linking to shared resources and generating your database config file. It’s also convenient to have the deployment details for your various environments in one place, rather than logging into each server and performing updates manually.
First let me clear up capistrano and SCM (such as git) are not mutually exclusive options. You should still use some sort of SCM even if you are deploying using capistrano ( or one of the other ruby deployment systems).
Having said that I would advocate using some sort of SCM system like git or mercurial for deployment, rather than cap if ONLY you ever have to deploy on anything other than Linux. Which I ran into. We have a requirement to deploy to Linux and to Windows so capistrano is not a good option, the newer version ( > 3) will not support windows, per official developer ( it’s on google groups). But that is the only downside of using capistrano versus doing it manually using git or hg or svn that I can think off right now. Essentially all capistrano and such systems do, is lighten your birden by letting you deploy an app in one/two command lines rather than 10. It’s especially useful if you have to deploy on multiple systems/machines.
You could also roll out your own script/solution if you needed to, which is what we will have to do to support windows.
Capistrano can also be configured to use git-based deployment — you still get the joys of “cap deploy:rollback”, but without all the extra release directories (and corresponding disk churn):