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.

Are there any other advantages to the Rails approach? Or, is a ‘git pull’ approach actually more widely accepted?

  • How to avoid tons of commits when debugging Heroku app
  • Is it a good idea to put db/schema.rb to .gitignore list ??
  • Is the server running on host “localhost” (::1) and accepting TCP/IP connections on port 5432?
  • Sync local test server with local git repository
  • Heroku releases - how to roll forward after rolling back?
  • Git workflow for a small team of developers and designers
  • Capistrano deploy fails with “Cannot read username”
  • “The program 'rails' is currently not installed” after git clone
  • 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):


    Git Baby is a git and github fan, let's start git clone.