It must be bought into. But just what are organizations buying into?1
For me, the goal is to be able to answer “yes” to this question:
Can we confidently and reliably deploy and operate software at any time to meet the needs of the business?
Automation, and a lot of it. Automated unit tests are running on developers’ laptops and again when developers check their code in. Passing code is automatically deployed through a virtual pipeline to downstream environments that can be automatically provisioned on demand, with other automated tests to confirm that new code works as expected along with validating that no regressions have been introduced and that the various “Ilities” are in place such as security, performance, and scalability.
As you observe the situation, you realize something critically important: the dynamic has shifted. Teams are no longer testing quality in an application to confirm that one or more features are ready to be released to production. Instead, the application is continually proven to be in a production-ready state, and any change that breaks that high-quality state is caught and prevented from being propagated to production.
You also notice that developers seem to be spending more of their time coding instead of sitting in meetings talking and planning about impending code changes. You realize that they are continuously integrating their code, many times per day, which enables them to adapt and coordinate with other changes being introduced in real time. They are communicating in code. And somehow that seems, well, natural.
Back to reality. You aren’t even close to this. How and where do you start?
Model your current state – as unflattering as it might be – and then, as the saying goes, “begin with the end in mind.” If you are unable to confidently and reliably deploy and operate software at any time to meet the needs of the business today, what needs to be true to realize this goal? Exploring this question will most likely reveal a daunting – and sobering – backlog of work required to move you from your current state to this desired end state.
From there, it’s a question of prioritization. Where can you make the most impactful changes that will help your organization accelerate the generation of information that proves the quality of your application? It’s most likely going to be a combination of things. An initial backlog might look something like this:
- Migrate to trunk-based development, eliminating long-lived code branches
- Automated unit testing for new code
- Build automation that executes automated unit tests and performs code analysis
- Automated acceptance tests for new features
- Targeted automated regression suite to provide basic validation of the most-used and/or critical features
- Walking skeleton of an automated deployment process and provisioning of test environments
DevOps is an investment. It’s all about building a future that enables companies to continually and reliably adapt and respond to ever-increasing rates of business and technological change and competitive pressure.
Ready to stop dreaming about DevOps, and start putting it to work? Learn how we can make DevOps work for you!
1. My use of the term DevOps includes everything that encompasses Development and Operations in the spirit it was intended, without expanding the acronym to explicitly include Security, Business, etc. by using variants such as DevSecOps, BusDevSecOps and so on. I recognize that all of these things are required to succeed.