Howto provide software drops via SVN?

Delivering software should be fast and easy. Otherwise it's annoying to spend time in building packages manually. So I would like to use SVN to ship my rails project to a productive environment.

The idea is that operational guys just have to checkout the inital project by executing:

svn co https://my-server/vs/my-project/tags/1.0.0

Afterwards those guys can change the appropriate files for configuration settings in that local SVN workspace.

If a new software realease is available we just distribute (beside a README) its new version number, for instance version 1.0.1. To update the production machine the operational team just switches to the appropriate workspace by executing:

svn switch https://my-server/vs/my-project/tags/1.0.1

(Of course, before doing the update running severs have to be stopped and after the update some migrations have to be done, etc). I want to point out that there is no need in delivering and extracting TAR balls and that previous configuration settings are kept in place or will be merged with new configuration lines (ok, this could lead to conflicts which have to be resolved).

Are there any (further) drawbacks/traps? Do you have a better approach using SVN for shipping software?

Thanks in advance!

From stackoverflow

• One drawback to this approach, which you may not run into yet, is that this approach will be come tedious for operations as you scale your application to multiple servers. If you suddenly need 4 front end servers and two database servers, your Ops team will have to ssh to all four machines, configure them, then configure the database machines.

  If this is something you will be concerned about in the the near future I would look into using something like Capistrano, which lets you deploy and configure applications across many machines at a time.

  The advantage of adopting Capistrano for your app even on one server is that you can fetch from subversion, configure the app, and setup the database in one script.

• Don't keep the configuration files in the repo. I typically rename database.yml to database-example.yml and put that in my repo.

  Just make sure they don't add it into the repo, presumably by only giving them read access.

  Another option would be capistrano. You could just push-deploy when you wanted to their server instead of them pulling the updates.

• Check out Capistrano for deploying your rails apps. Easy to integrate with SVN. Automates the entire thing. I update my stable-branch, issue the "cap deploy"-command, and it's done.

• I agree with the others' comments, about using Capistrano to automate your approach. It works very well. If you want a web interface for Capistrano, have a look at Webistrano. It's a Ruby on Rails application that centralizes Capistrano scripts, and provides logging, accountability and some access control. All via a nice web interface.

  We use it to deploy dozens of websites to multiple servers. The initial setup takes a bit of work, since you'll need to setup a way to run the Rails application (for example via Passenger). Webistrano is quite user friendly though, and works well. We've deployed over 2300 times so far.