How to ensure software transfer through SVN?

Question

Software delivery should be quick and easy. Otherwise, it is annoying to waste time collecting packages manually. Therefore, I would like to use SVN to send my rails project to a productive environment.

The idea is that the operational guys just have to check the source project by doing:

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

Then these guys can change the appropriate files for the configuration settings in this local SVN workspace.

If a new version of the software is available, we simply distribute (in addition to README) its new version number, for example version 1.0.1. To upgrade a production machine, the operating group simply switches to the appropriate workspace by doing:

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

(Of course, before performing the update, you need to stop the interruptions, and after the update you need to perform some migrations, etc.). I want to note that there is no need to deliver and retrieve the TAR balls and that the previous configuration settings are saved in place or will be merged with new configuration lines (well, this can lead to conflicts that need to be resolved).

Are there any (additional) flaws / traps? Do you have a better approach using SVN for software delivery?

Thanks in advance!

Answer 1

One of the drawbacks of this approach, which you have not yet managed to run, is that this approach will be tedious for operations when scaling an application on multiple servers. If you suddenly need 4 front-end servers and two database servers, your Ops team will have ssh for all four machines, configure them, and then configure the database machines.

If this interests you in the near future, I would consider using something like Capistrano , which allows you to deploy and configure applications on different computers at the same time.

The advantage of using Capistrano for your application even on one server is that you can extract from subversion, configure the application, and configure the database in a single script.

Answer 2

Do not save configuration files to repo. I usually rename database.yml to database-example.yml and put this in my repo.

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

Another option would be capistrano . You can simply click-expand when you want their server to pull updates instead of them.

Answer 3

Give up Capistrano to deploy your rail applications. Easily integrates with SVN. Automates all of this. I update my stable branch, issue a deploy command, and it was executed.

Answer 4

I agree with the comments of others about using Capistrano to automate your approach. It works very well. If you need a web interface for Capistrano, check out Webistrano . This is a Ruby on Rails application that centralizes Capistrano scripts and provides logging, accounting and access control. All through a good web interface.

We use it to deploy dozens of sites on multiple servers. The initial setup takes a little time, since you need to configure the way the Rails application starts (for example, through Passenger). Webistrano is very user friendly and works well. We deployed over 2,300 times.