A typical Rails deployment involves configuring a number of services via configuration files. Common examples include httpd.conf, nginx.conf, memcached.conf, monitrc, my.cnf, haproxy.conf, et al. These little files are the laces that hold your app together; the tiniest mistake or misconfiguration will usually take your whole operation down. On top of this, if you’ve got multiple servers, you’ve got to make sure that every server is configured correctly.

So why don’t we put these under version control, and then use Capistrano to deploy configuration changes to one or more servers? Here’s one way to do it.

First, config files go in config/server.

In this example, the target servers are running Debian (Etch), and config/server/ corresponds to the root directory of the server—so we’ve got /var, /etc, and so on.

With this under version control along with the rest of the app, you can now roll back to earlier “known-good” configurations lickety-split.

As an added benefit, this increases transparency for your team, since developers can see how the deployment works without having to actually visit the servers.

And here’s where it gets even better—you can now use Capistrano to deploy configs!

Dig on this:

desc "Deploy server configurations" 
  task :config,:roles=>:app do
    # Export to a temp directory, to avoid uploading .svn directories.
    temp_dir = "/tmp/capistrano-#{Time.now.strftime("%Y%m%d%H%M%S")}" 
    system "svn export config/server #{temp_dir}" 
    system "scp -r #{temp_dir}/* #{user}@#{host}:/" 
    system "rm -rf #{temp_dir}" 
    sudo "chmod 700 /etc/monitrc" 
    sudo "chmod 600 /etc/mysql/my.cnf" 
    sudo "chmod -R a+wx /var/service/*" 
    sudo "chmod +x /home/deploy/backup_db" 
    deploy::reload_monit
    deploy::restart_mysql
    deploy::restart_mongrels
    deploy::restart_apache
  end

• This happens to be a subversion environment; if you’re on git you can probably just omit the exporting step.
• Make sure you completely understand how “scp” works—if this is new to you, bone up, because a mistake here can really ruin your day.

Please note that this code snippet will almost certainly not work for you as-is; you will have to adjust, rewrite, and optimize this for your unique situation.

One last tip: If you run into problems at first, make sure that permissions are reset correctly; these are idiosyncratic and tend to get wrecked in transition. It’s a simple/best practice to explicitly reset the permissions in your deployment.

You’ll thank yourself later—enjoy!