Jake Scruggs

writes ruby/wears crazy shirts

Jun 7, 2009

Iteration Zero

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 capify.org "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"
end

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

desc "Restart the server"
task :restart, :roles => :app do
stop
start
end
end
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.

4 comments :

lazylester said...

I like to maintain a project "to do" list for feature requests, and also a bug list, right in the application. So start iteration zero with todos and bugs model/controller/views (with login authentication). I'm curious how others handle these management tasks.
Every app I've ever worked on has needed an admin area, so the whole authentication framework seems like an iteration zero function, no?

Rafael Rosa Fu said...

Just a quick note regarding Shoulda: did you try Remarkable (http://github.com/carlosbrando/remarkable/tree/master)? It runs over RSpec, adding shoulda macros to it and a lot of other functionalities. It's quite an interesting test tool and I can't think about writing, at least, model tests without it.

Cheers

milli said...

I see that you are using mongrel.
Have you given a try for Passenger?? Its really cool.

Jake Scruggs said...

Passenger is indeed very cool -- we'll probably move to it as needed. Right now one mongrel instance is all that's required for the Qa and Demo environments.