Just about everyone has heard of DevOps by now, right?
We have clients that talk to us because they want to “do DevOps”, but if you’re in this situation, how do you even begin to plot the correct journey for them?
In this article I’ll go through some of the thought processes I use to help guide clients along the path.
I’m not going to go chapter and verse on DevOps. Go look it up. Suffice to say that DevOps involves scripting your infrastructure provisioning and your software build and deployment processes.
Buying into the need for DevOps
I start by saying that DevOps isn’t something that you do once, tick a box, and then move onto something else. It’s a way of working. It’s a mindset and an approach.
I’m not a gardener, but I liken it to having a garden. In the early days you design your garden, put your turf down and your plants in. Then you tend to it regularly. You prune and weed, add a little, remove a little. Optimise. Nurture.
I then get clients to understand that manual processes undermine their ability to deliver. This is a biggy. If you do anything manually, no matter how well you document the steps, you always get different results. Eventually, always. Software quality depends on repeatability. Manual processes are not guaranteed repeatable. Manual processes are therefore the enemy of quality.
More than this. Manual processes don’t scale. If it takes me 20 hours this week to deploy something, it will take me 20 hours next week. If I need 10 deployments next week it will take 200 hours (or even more as everyone dies of boredom and demotivation). If I spend 40 hours this week scripting a deployment it may take me 10 minutes next week to kick off 10 deployments. Code scales, people do not.
Examine the underlying practices
DevOps doesn’t appear in a bubble. It should be a wrapper that encompasses other practices. If you’re doing the other practices well you should be able to build on top of them. If your dev practices are weak you need to address them first.
Look at your source control processes, your branching strategy and how you come to release code. Is this rock solid? You can’t build quality software until you get your source management right. Fix it. Get the right tools and learn how to use them.
Look at your build processes. Make sure you’re automating your builds with every new commit. Are you ensuring that bad builds are rejected? Does your build process test quality? How? Does it run unit tests? Does it set code coverage thresholds? Do you block merges to your master branch if the quality measures aren’t met?
Look at your testing strategy. What’s the reliance on unit testing versus integration testing? (This is a big subject, with no single answer). If you make a change, how confident are you that you haven’t broken anything? Are you able to automate a test run and get a report on your quality? How do you manage integration with systems developed by other teams or vendors?
How do you provision infrastructure? Do you procure physical tin? Are you virtualized? Are you able to provision a new environment, or scale your production environment, by running scripts?
Examine and understand all of the practices that underpin your delivery. Methodology is for selling books and consultants. Practices are the key to good development. Practices and a commitment to excellence.
Examine your processes
Your processes will vary depending on whether you’re shipping packaged software (and how you’re distributing it), selling hosted software or running line of business systems.
The best processes are the simplest. The fewest branches. The smallest number of active deployments. The shortest time from commit to release.
Look at what you’re doing, and examine it critically to see if it’s adding value and contributing to quality.
Look at each process and understand what happens at each stage. In detail.
Plan for end to end
Once I’ve been over the practices and processes I then start working with clients on a plan to get the end to end DevOps in place.
You need to look at where your pain points are and then plan to eliminate them one by one.
Where are your pain points? Look where you’re burning resource that isn’t adding value. The only true measure of value is working software (Agile Manifesto). Anyone that isn’t contributing to the building of working software is a symptom of waste and bad quality. Script waste out of your project. Build solidly scripted sub-processes. Tend to them. Improve and optimise them often.
Building your DevOps is like building links in a chain. Model your process, script each step. Encourage continuous improvement via evolution; dissuade stagnation. Aim to go from a commit, through testing, to deployment solely by running scripts. Once you have achieved this, think about how you can join the links to create your release pipeline.
In summary
DevOps is like many other things in software. There were people who were doing DevOps before it was even a thing. That’s because of their commitment to excellence and they devised good practices to support what they were doing.
My advice would be to focus on building the foundations right. Before you know it you’ll be “doing DevOps” because the components will all be there.
After that, keep tending it.