Iteration Zero

08 Jun 2009

I spent the week doing an iteration zero for new project. The idea behind iteration zero is to get the development environment as automated as possible so developers can spend their time coding when the real development begins.

So here’s what we did:

1. Set up new git repository

We use GitHub so that only took a few minutes.

2. Make new Rails app

Again, just a few minutes

3. Set up geminstaller and basic gems (HAML etc.)

Geminstaller installs gems needed by the project and makes sure they are there before starting the app. This functionality has been pulled into modern versions of Rails now, but I’ve found it a little wonky and I’m working with a former Pivotal Labs guy who just loves the Pivotal stuff (don’t even get him started on Tracker vs Mingle).

4. Set up developer tests.

We looked into Shoulda, but ultimately went with RSpec (although we may use the Shoulda macros to test ActiveRecord) because most of the criticisms of RSpec are that it’s too heavy. To that I say: “Give Shoulda some time and success and then see if it’s still light.” Feel free to flame my comments section.

5. Set up Selenium (Integration) Tests.

We used Polonium. We could have gone with WebRat, but no one on the project had ever used WebRat and one guy had extensive experience with Polonium. Our build now fires up a browser and clicks through the app (we will be taking pains to keep this suite short – just a smoke test really).

6. Set up Continuous Integration

We went with CruiseControl.rb. Note: Use the ThoughtWorks version on GitHub. If you go to the main CruiseControl.rb page it will direct you to an old version that doesn’t support Git.

7. Set up scripted deploy

Looked into Vlad the Deployer, but it’s lack of documentation did it in. I know it’s supposed to be much simpler than Capistrano, but we couldn’t get it to work. Capistrano is fine, but it’s basic documentation starts talking about spinners and spawners at some point. Wasn’t that like 4 years ago? Here’s my advice: Follow the “from the beginning tutorial” but skip the spinners and spawners stuff and just put this in your capfile:

namespace :deploy do
desc “Start the server”
task :start, :roles => :app do
run “mongrel_rails start -e production -c #{current_path} -d -p 3000”

desc “Stop the server”
task :stop, :roles => :app do
run “mongrel_rails stop -c #{current_path}”

desc “Restart the server”
task :restart, :roles => :app do

That’s good enough to get you going. Basically you overwrite the stop, start, and restart tasks that cap uses under the covers. I should point out that I’m using Capistrano version 2.5.5 because all the doc for cap I find on the web never mentions the version they are talking about and it drives me crazy. Cap has changed A LOT over the years and something that was perfectly good in 2006-7 may not be so relevant now. Also, we’re using capistrano-ext version 1.2.1 so we can deploy to multiple environments.

8. Set up Demo and QA environments

After the previous task, this was easy. All we have to do is ‘cap demo deploy:setup’ and ‘cap demo deploy’ to get the demo environment up and running. QA was the same except for, uh, using the letters ‘qa’ instead of ‘demo.’ Now we can deploy with one command – w00t.

9. Set up NewRelic

NewRelic lets you profile your Rails app with ease. I’ve used it before on apps I’ve written and have found it immensely useful in tracking down slow parts of the project.

10. Make Cruise Control run a Metrics Build every 24 hours.

Yep, I really do use metric_fu on my projects. I like installing it from the get-go so we can keep an eye on things and track changes to the app.

Well, that ended up being about a week for a pair of developers (with some interruptions for meetings and other stuff) and a pretty good iteration zero if I do say so myself.