Are you (really) doing DevOps?
Would you like to know if you weren’t?
“Everyone’s doing it at the moment.”
“We have to do DevOps or else we’ll be left behind.”
“Our competitors will be doing it soon, if they aren’t already.”
These are common refrains I hear a lot lately.
First, let’s slow down and take a step back.
What DevOps Is Not
Many companies, in my experience, are not doing DevOps correctly, if at all, despite what they might think or try to suggest.
— Thinking a build process or pipeline equates to successful compilation.
— Thinking successful compilation equates to a release candidate.
— Thinking manual testing is acceptable.
— Thinking DevOps is just automating existing (bad) practices.
None of these are DevOps.
DevOps has as many definitions as it is an overused word. Every job advertisement at the moment includes the word “DevOps” even when the job description has scant content relating to what real DevOps can provide your organisation’s software development capability.
I am not about to offer another definition of DevOps. There are enough of them out there.
What Is DevOps?
I’ve briefly touched on examples of what DevOps isn’t. To consider what DevOps is, let’s consider the essential goal of DevOps.
The goal of DevOps, to my mind, is simply this: Constantly being able to deploy a quality, bug-free version of software to production without causing a “CNN Moment”.
To my way of thinking you can’t do DevOps unless you have the foundational capabilities of Continuous Integration (CI) and Continuous Deployment (CD) in place. Digging a little deeper, DevOps, in fact, sits atop enabling capabilities of which CI and CD are but two.
Being willing to constantly deploy to production requires a lot of confidence. Where does this confidence come from?
A very good question. Well, it isn’t rocket science. It comes from copious amounts of testing. It is therefore impossible to talk about DevOps without talking about testing. Testing is integral to DevOps.
A Build Process should have the following as a minimum:
— Check the code out from a source control system.
— Execute Static Code analysis.
— Execute Automated Unit Tests.
— Execute Automated Integration Tests.
— Execute Automated Functional (UAT) Tests with a tool like Selenium.
— Automated application of a label (or “tag”) back against the source control system if, and only if, all above tests have passed.
— Automated deployment of successfully tested artifacts to an artifact repository.
Having the capability necessary to do real DevOps is more involved than it may first appear. Paradoxically, it can also be easier than you first think, if you know how to go about it and remain focused on the goal of DevOps.
DevOps is definitely something you should be doing. If you are doing it right, the investment will pay you back in spades. If you aren’t you’ll be left wondering how your competitors got the jump on you…again.
DevOps isn’t witchcraft or even rocket science. Its engineering.
The DWS DevOps Practice can help you navigate the journey to ensure your business is realising the full promise that only real DevOps can provide.