Enter the “Platform Team”: a group of build & deploy experts that jumpstart your teams down the road to operational success while providing a safety net. And, no, I’m not referring to a System Administrator with a pager. Instead, I’m suggesting a three-ply construction of automation, containerization and monitoring.
In comparison to the total number of product categories in our database, Stylight supports a handful of “pretty URLs” – those understandable by a human being. With http://www.stylight.com/Sandals/Women/ you have a good idea what’s going to be on that page.
“Hey Dan, could you deploy the coolPics branch to test? Sorry for the bother :(”
“No problem, man. Tell me the SHA and I’ll deploy it.”
I had been having this conversation 4-5 times a day for a couple of weeks now. Being a huge fan of continuous integration, I wondered how to automate this. Why shouldn’t the developers be able to push whatever they wanted to test?
A colleague, overreading this back-and-forth in our HipChat room, told me to take a look at Hubot. It was custom made for automating rote tasks like webapp deployments. One weekend later, I was hooked. Here’s how I took the first step in transforming our abstract sense of team trust to tangible ownership.
The devs are all writing automated tests and some are even experimenting with TDD. Congrats! But what happens when the build server breaks? Who’s taking care that Continuous Integration is running smoothly? Seems to be an awful lot of red in there…
Unlike writing the first basic tests, CI is hard. Did the test fail due to an application bug or is it the environment? Once again, the dreaded chant of “it works locally” is taken up. What most people fail to understand is that the failing test is the first sign of a communication breakdown between developers and sysadmins.
In the last decade of my career, I’ve been extremely fortunate to have worked with some of the best people I’ve ever known. A big contributing factor to this is the tech-savvy, expatriate culture that exists here in Munich as well as the type of people you typically find abroad who have left their home countries to pursue their dreams. It’s a dynamic that provides an immediate and powerful bond: we have to learn an a lot of things in a short timeframe and sometimes we’re terribly homesick, but we’re not alone. When we combine our strengths and help each other, we achieve something great.
For as many teams as I’ve had the privilege of leading, I’ve often been asked how I did it? How did I take six or seven individuals from different countries and turn them into a team? The question always catches me a bit off-guard because I don’t consciously do this – and I think that’s key. You can’t force anyone to work together as a real team and the harder you try the faster you’ll push them apart. Plus, it’s currently a developers’ market. They can work wherever they want to and they know it! How do you walk this tight-rope and successfully lead a team of rockstar developers?
Test a developer’s software and you’ll find bugs.
Teach a developer to test and they can release their software.
A bit of a twist on the old fish and eating maxim, but the same idea: teaching a skill enables self-reliance and self-confidence. And, while it’s harder than quickly doing someone a big favor, teaching is scaleable in a way that quickly refutes another old adage: we have so many bugs because we don’t have enough testers!
“But our customers don’t want 10 new versions a year. The last release alone had over 600 bugs!” retorts the hotline manager.
“How about a small update with just a handful of bugs?”
Your big-bang release is scary. It’s full of issues and weird, new features that nobody understands. It requires documentation and training and who the hell has time for all that?
Monthly, bite-size updates will have fewer features requiring less support (pro-tip: less code == less bugs). Speeding up your release cycle also allows quicker response to customers’ feedback. You’ll finally feel your company moving in the right direction again.
Of course, it’s easy to say. But how can you actually achieve this positive flow? Follow these key points and you’ll be well on your way.
“What if you could upload them to the “Cloud” and mail just the link for viewing?”
“Great idea, and there are some really excellent web services that offer this already. Maybe we could just use one of them?”
“Nah, we could do it way better and I have a few more ideas. We know what our customers really need.”
A couple of years ago, I showed you how to Visualize Small Batch Sizes with Git by plotting day-to-day the amount of changed source code lines that hadn’t yet been released to production. While this graph gave immediate feedback about the “drift” of development from operations (live), it’s not something easily digested by upper management. What do these guys really care about? It’s all about the releases silly!