[Reading time: 2 minutes 49 seconds]
“But Luca, where should we start?” is the common theme in all my conversations with organisations wanting to introduce DevOps.
Perfectly understandable: DevOps can seem like this vast, bewildering, vague thing.
And you’ve probably got a lot of infrastructure you’re running, a lot of code in production, written over many years. And none of it is in quite the state you’d like it to be. Test coverage not what you’d like (if you even have automated tests). Deployments full of manual steps. Whatever automation there is was cobbled together by a bunch of coworkers over the years, half of whom have since left.
Sound familiar? I bet it does – I’ve never seen otherwise. But that’s OK. There’s just so much to do, yet so little time. Inevitably, things things start to look a bit ragged. But now might be a good time to start cleaning stuff up!
So… what’s a good first step?
Let’s zoom out a bit and reach into the DevOps canon: if you read up on DevOps, you’ll inevitably come across Gene Kim’s Three Ways.
The First Way, Gene Kim says, is called Systems Thinking – ensure that you’re not considering just a single snippet of your value creation chain, but all of it. From code to running product in front of your customer.
Sounds lofty, but its application is really down-to-earth: get to wrangling your system.
My preferred way of getting a handle on an existing system is automating the delivery pipeline: set up a system which takes your source code, and carries it across all the different preparation steps (e.g. compiling and linking) all the way to automated deployment. Not necessarily deployment into production, but at least onto some target system.
You don’t even need to set up a proper Continuous Integration system (e.g. Jenkins) yet – we’re not at this point. If you’re eager to start, go for it. But don’t feel like you have to. I’m happy with a good, complete Makefile.
Similarly, don’t worry about visualising or reporting test results yet. Just kicking off the test runs is all we’re after at this stage. No feedback loops yet (of course if you build some that’s awesome), just moving in the forward direction really solidly.
I promise you, it’ll be hard enough work even if you stick to the basics: you get to visit all the skeletons in all the closets. But that’s exactly what we want. Get acquainted with all the skeletons, lose your fear of them, find ways to deal with them.
But once you’ve done this work, just imagine: You’ve potentially automated many manual tasks. This means many good things:
- more speed
- visibility through expressing tasks in code
- more reliability
- no more dependencies on single persons or departments
- ample chance to optimise – because everything is out in the open, and ready to be tinkered with
Finally, your entire delivery pipeline is out in the open, visible in front of you. This isn’t the end of your DevOps journey yet; far from it. But it’s the foundation we can build everything else on.