There is no way that we could have maintained this pace if we were taking down the test system for 10 minutes with each deploy. We needed to be able to continuously test the system throughout. This to me is one of the unsung values of zero-downtime deployment. Everyone normally focuses on the benefit of your users not seeing a fail whale page if they hit your site during a deploy. But let’s face it: unless you’re practicing continuous deployment, you’re deploying to test much more often than you are deploying to production. And the frequency with which we can cycle through and get feedback on changes in the test environment is one of the primary limiting factors determining how frequently we can release the software.

While many people that I’ve talked with like the idea of zero-downtime deployment, they have little access, control or influence over the production environment. So my advice is to start with the environments that you own, like test. Get it set up and running solidly there first. This greatly lowers the barrier to then rolling it out to production. And, as I describe above, the benefits of having zero-downtime in test are substantial.

In my next post, I’ll try to provide some more technical details about our zero-downtime set up.

A candidate’s application is treated as an issue in Jira, and the pipeline is loosely modeled as a workflow. We track phone screens and interview notes as comments against the candidate/issue. The issue can be assigned to whoever is responsible for interviewing or following up with the candidate. We receive emails about the status of the candidate through Jira’s notification scheme. The main debate was whether to treat candidates as “Bugs”, “Tasks”, “Improvements” or “New Features”. We settled on “New Features” :).

Using Jira certainly beats managing this information through Word docs, spreadsheets or closed HR systems. The main weakness is that scheduling is not that well supported – you can kind of give a candidate a due date, but it’s not that natural. But for now, it is just light enough for our needs.

I started the morning by attending Alexey’s JRuby overview. It was interesting to get some insight into the problems the JRuby team has faced mapping between Ruby types and Java types. This certainly seems to be better addressed by the .NET DLR which should simplify matters for dynamic language implementations in .NET.

I also spent some time chatting some guys working on Rubinius. They had some pretty strong opinions about ZenTest and AutoTest over Test::Unit and CruiseControl.rb respectively. Of course, they were slightly biased, but it deserves a closer look.

I talked with Marc Mayo about Git, distributed teams and his company Joyent. He ran an insightful session on the trials and tribulations of hosting high traffic Rails applications.

The last two sessions that I attended were one on Merb (an alternative web framework to Rails) and Scott Patten’s Rubyize This!