0

A couple of the Rails projects on which I'm working appreciate frequent, incremental updates, which I think is great. Our current deployment strategy is manual but we're considering switching to an automated tool like Capistrano; however, it also occurred to me that it might be even better to just deploy a Subversion working copy instead.

Here are the benefits I can see, off the top of my head:

  1. No need to export/zip/copy/ssh/unzip to deploy code (just svn update).
  2. Easily rollback to any revision (e.g. svn update -r 123).
  3. Easily determine currently deployed revision (svn info / svn diff).

Of course, this strategy wouldn't be appropriate for large institutions that have environment controls and separation, but aside from that, what are some of the drawbacks to this strategy versus a formal automated deployment tool?

maerics
  • 203
  • 1
  • 2
  • 7

1 Answers1

0

What happens when someone commits a quick broken change or commits with debugging still left on?

You're better off tagging commits as "production" or something similar if you want a commit deployed. Then have a deploy script that periodically checks for a new production release, strips out any debug files/options, and puts the files in the right place.

Niall Donegan
  • 3,869
  • 20
  • 17