Apr 082012
 

Stack Builders, the Ruby on Rails consultancy that I started, runs all of their projects under Continuous Integration (CI). While we’ve tried a bunch of different Continuous Integration servers and services, we’ve settled on Jenkins.  Just a few moments ago, I released the source code that we’re using to run our builds under Jenkins, so I wanted to share some of my thoughts behind writing Railblazer.

For a long time, I set up Rails builds under Jenkins by:

  1. Creating a database.yml for each project on the build server and
  2. setting up a script on the server for each project that copies the database.yml into Jenkins’ workspace

I realized after doing this for several months that each database.yml was essentially the same on any given machine, but that the database.sample.yml so often included with the source of Rails projects is usually not the correct match for local configuration. Generally speaking, database configuration is a machine specific, rather than a project specific thing, which makes the practice of providing a database.yml not really that useful.

In addition, there have been a bunch of cloud-based services recently that have pioneered the practice of automatically configuring a Rails app to connect to a database (e.g. Heroku and tddium).

I decided to see how far I could get towards writing something that auto-detects the database adapter necessary for a Rails application and generates a correct database.yml, based on adapter auto-detection and a local template. This would be the only missing piece to basically have a Rails app configure itself to run tests under Jenkins – as long as you follow best-practices and use RVM and bundler (by creating a Gemfile), it should be straight-forward to write a program to automatically generate a database.yml based on a local template file.

After setting up a new Jenkins server, and adding the first half-dozen project builds for current client projects, it seems that the tools that I have written and released as ‘railblazer’ really does help to configure applications and run builds with minimal intervention. It’s also potentially useful as a tool on a local workstation to generate database.yml files for apps by auto-detection and template rendering rather than by copying and modifying the database.sample.yml provided by others.

I hope it’s as useful for you as it has been for us at Stack Builders! If you have a chance, check it out and let me know what you think. The source code is available at github, and the gem can be installed with ‘gem install railblazer’.

  2 Responses to “Railblazer: how Stack Builders runs Rails apps under Continuous Integration”

  1. I’m working in a application (nothing special) using mysql database in EC2 and I have to deploy it in heroku. Q: I can use “auto_configure” to generate the database.yml for my?.

    I´m familiarized with jenkins(hudson) in java world so use it in ror is great for my. Do you have a private server or use a cloud based service?

    Thanks for this,

    • Hi racar. You’ve probably figured this out by yourself at this point, but in case anyone else comes along with the same question -

      Heroku should generate the database.yml for you I believe. You wouldn’t need a script like this to accomplish that.

 Leave a Reply

(required)

(required)

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>