DevOps, if you look at it closely, is a dauntingly huge field. Since it attempts to cover large swaths of the value chain, there’s just a lot there. So many things to consider, so many moving parts.
For this reason, I’m not going to call this post something grandiose about “DevOps Transformation” or somesuch.
Rather, small steps in the right direction. If you keep this up for a year, you’ll be amazed at what you’ve accomplished. And maybe, in retrospect, you’ll decide it really was a transformations.
But let’s not get ahead of ourselves.
Both from a human or team perspective (how will you organise your collaboration?) to the technical (how will you organise your repository?) and tooling (TeamCity or Jenkins? And how to apply them?).
It’s certainly enough to make your head explode.
So… where to start?
Not by throwing tools at your team, that’s for sure.
I know, I know.
I’m a tinkerer like you, and I love to dive right in, install (say) Jenkins and take a crack at the problem right before me.
But there’s tremendous danger in this: chances are you haven’t yet thought through how to approach DevOps in your team or organisation. In fact, you might still be at the stage of having to understand the meaning of DevOps.
If you become too concrete at this early stage, you run a very real risk of creating facts prematurely, painting yourself in a corner. And what’s worse, you may turn your team off just as you start down the road of this transformation.
So you should first gain some clarity of your situation and your goals. The path to these goals will become clear to you once you’ve understood your situation.
Feedback loops everywhere
Remember, the real strength of DevOps lies in the many feedback loops it strives to create.
Fast, super-short loops, e.g. just trying to build the product.
High-volume short loops like automated unit testing which might take just a handful of seconds.
Long, powerful loops like acceptance tests, and monitoring in production, which lets you observe your product and your customers' interactions with it in vivo.
And of course everything in between.
Don’t forget that your development processes themselves should have feedback loops (say, a Scrum sprint retrospective), so you can continuously experiment and improve.
Don’t just do something! Stand there!
So the first step you should take, is – back. Take in the big picture.
Why do you even want to introduce DevOps? What value are you hoping for it to provide? Which problems to solve? Take the time time to dig in, use the five why method, or use other techniques to drill down.
Once you’ve identified an actual goal, I bet you have an idea of how to attack it. And I also wager that you’ll have mentally emancipated yourself from concrete tools to a degree. The tool doesn’t matter, the goal does. And since you know the goal, you’ll be able to find a way there, as long as a given tool isn’t a completely wrong fit.
You’ll have understood who needs to be included in this step, and you’ve made sure to gather their suggestions so there is a common understanding.
Now, take one step.
First, decide on a goal. Decide how you’re going to measure progress towards that goal. Figure out metrics, and think about how to judge them.
Remember that user opinions should also be collected as metrics. Maybe all you need is a vague an squishy metric, such as “how do you like it?” or “is this better than what we had before?”. But you can also be more concrete if you see a need to look at a specific aspect.
Defining metrics may feel like annoying bureaucracy, but it isn’t. It’s your way to determine the future direction to take. If you skip this step, you’ll regret it: you’ll keep blindly stumbling about.
Once you have this feedback plan in place, conduct your experiment: introduce a new technique. If you can, don’t commit to a tool yet – stay flexible. MVPs are also a thing for development teams! Before you install Jira, maybe pen-and-paper will do for a week or two, allowing you to nimbly tweak everything until it feels right. Then introduce software tools.
Then, see if that step works
Close this particular feedback loop. See if your newly introduced workflow feels right.
Of course, you’ll use your metrics for that. Metrics for technical things, but also metrics for the human side: how happy are developers, users, or other stakeholders? Do they use it willingly (because thEy realise it makes their lives easier), or do they grumble?
Take the feedback to heart, and tune your workflow until feels right.
Once this feedback loop is running, decide on the next thing to tackle
Keep an eye on your metrics, but move on to the next topic you’d like to improve.
Dare to be bold sometimes – DevOps is about continuous experimentation. If something doesn’t work out, it wasn’t a failure: you still gathered a valuable data point.
Lather, rinse, repeat.