The other day in "Site Triage and You", I talked about the three types of site issues and how we're addressing them.  But that doesn't cover how we're deploying them..

The core of our deployment strategy boils down to two principles:

Repeatability and The Buddy System

First, all of our code is in Subversion.  Every developer has full access to every line of code.  While there are a few areas which were predominantly written by a single developer, we've had strong coding standards and discussion in place - thanks to Nola - since the beginning.  When you know that at least one other person will look at your code... well, peer pressure can be one of the best things in the world.

Second, deployment happens the same way every time by one person.  We don't copy files up one by one or apply any changes manually.  Too many things can go wrong and all it takes is for someone to forget one command or file just one time.  I stop the server, perform an svn up, run any migrations, and restart.  All scripted, no room for error.  Also, since only one person can do deployment, there's no question to who did what.

Finally, no code goes into production without a peer review.  Every change - no matter who does it or how trivial - is reviewed and blessed by another developer.  Yes, since we don't have anyone on staff fulltime, it can slow things down. Yes, it can be a little tedious to always have to wait.  But I wouldn't change it for the world.  According to our logs, exactly two errors have been deployed since launch... despite deploying new code each and every day.

Despite these rules, we can still improve the process...

First, we can expand our RSpec tests.  In the final days leading to launch, our coverage dropped significantly.  We have quite a few tests that fail.  This needs to change.. and soon.

Second, we can scrub the codebase.  We've found a number of Magic Numbers and duplication that should be eliminated.  Duplicate code means duplicate bugs, duplicate effort, and duplicate stress and requires Refactoring.  Magic Numbers are much nastier as the introduce invisible dependencies.  A Magic Number was the cause of one of our introduced errors.

Finally, we need to expand the team.  Bringing another mid-level and another junior-level or two would be handy.  Not only can we get more done, but the trivial things can be handled while our senior developers move into bigger areas and lead by example.  Now that we're launched and funding is coming into play, we'll have some more options...

And like everything else around here, if you have tips or suggestions, I'm happy to hear them...