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!
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.