The future of SUMO development

Just this month, the SUMO development team completed our transition to our new platform, Kitsune. This small release represented the culmination of nearly a year of great work, and I couldn’t be prouder of the team.

At first, as the end of the tunnel approached, and we weren’t sure what we’d be doing next, I felt a little like Inigo Montoya: I’d been in the rewrite business so long, now that it’s over…

2010 was a year of investment in our code, and in our infrastructure, both hardware and software. We moved our code from svn to git; started using Hudson to run our comprehensive unit test suite; centralized our configuration to simplify deployment. Now it’s time to start taking advantage of that investment.

In that spirit, I want to issue a John Kennedy-style challenge: by this time next year, I want SUMO to deploy continuously.

There is a lot of work to do to get there.

• Pushing code to production needs to be automated, for all but the biggest, downtime-requiring changes.
• We need to expand automated test coverage to include our front-end and JavaScript code.
• Our code reviews and standards will need to be even higher.
• We’ll need to redefine the relationship between development and QA.
• When there are problems, we need the agility to respond quickly and the focus to learn from them and improve.
• We’ll need to be able to dark launch and flip on features, preferably with the flexibility to test with small groups.
• We’ll need to reevaluate our branch management and staging environments.
• We’ll need to rethink how we organize and prioritize work.

And unlike 2010, we’ll have to make these investments and improvements while maintaining a fast-paced development schedule.

This is not something the SUMOdev team can do alone: this is a challenge for us, for our ops team, and for QA as well. I look forward to working more closely with these teams as we chase this target.

Continuous deployment will bring a number of benefits—many of the requirements I just listed are benefits and solid goals by themselves—especially for contributors.

• Bugs are fixed for everyone as soon as they’re fixed for us.
• We can respond to issues faster.
• Code will be tested at production scale.
• Our processes will continually improve.
• We’ll reduce the load on individuals from IT and QA.

I call this a challenge because it will not be easy: it will be hard. It will push the bounds of our experience and our ingenuity. SUMO will be better, and we will be better.

How do we get there? Frankly, I don’t know yet. There are some clear, actionable items, like front-end testing and feature flags, and there is some brainstorming to do. There will be unanticipated hurdles to overcome and we will almost certainly make some missteps, and we will have to work around those.

In 2010, we pushed ourselves in terms of how much we could get do, and while we accomplished an incredible amount, that’s not a healthy pace to set for another year. In 2011, I want us to push ourselves in terms of what we can do, and how we do it.

2011 will be a great year for SUMOdev. And with this challenge, I just want to say: Game On.