I’ve recently finished The Phoenix Project: A Novel about IT, DevOps, and Helping Your Business Win — a rather good use for a long lonely train trip.
I got lots of ideas and déjà-vu on the situations depicted, so I am posting thoughts on top of what I read.
The return on DevOps is subtle. That may be the harder thing to grasp on this discipline.
Bringing theory of constraints practices that started in the industry to the IT world changes the mindset and the way things get done. A few distinctive aspects of DevOps:
- Work becomes visible throughout the whole chain
- Constraints can be identified and dealt with
- Everything moves faster – including detecting and working out anything wrong
It’s useful to start with proper context. This picture helps.
The Three Ways
The Three Ways are principles from where you can generate DevOps patterns. The first way is the way of the Flow. It means one knows (for you Heinlein fans the right word would be groks) the way value flows from the business to the customer.
The second way is the way of Feedback, adding communication between Ops and Dev.
The third way is the way of Continual Experimentation and Learning. One can improve because now we have feedback from every small experiment to validate ideas fast.
You can read a well written description of The Three Ways by Tim Hunter here.
The Deployment pipeline
A core concept for DevOps is the Deployment pipeline, industrializing and removing all technical risks from the whole development to production cycle.
“A deployment pipeline is a single path to production for all changes to a given system., whether to code, infrastructure and environments, database schemas and reference data, or configuration. The deployment pipeline models your process for building, testing, and deploying your systems and is thus a manifestation of the part of your value stream from check-in to release. Using the deployment pipeline, each change to any system is validated to see if it is fit for release, passing through a comprehensive series of automated tests. If it is successful, it becomes available for push-button deployment (with approvals, if required) to testing, staging, and production environments.”
— Why Enterprises Must Adopt Devops to Enable Continuous Delivery by Jezz Humble and Joanne Molesky
Deployments become natural, regular and safe. It allows for inverting the wait. That is, IT waiting for the business. So business gets the chance to see working software sooner and within shorter decision windows.
The role of automation
Automation is key for DevOps because it allows for faster time to market. And this changes the way people work and collaborate. For instance, having the same environment from development right up to live production eliminates errors and rework due to disparate environments. This is so obvious that it hurts to think there are still organizations that don’t do it.
Of course there are no free lunches. For the example above one first need to have all configurations under control (not just code, also the environments themselves), otherwise it’s impossible to automate this.
Now think on the impact this approach has for testing. Maybe you don’t catch all errors but you certainly will significantly reduce errors from the Development to Production process itself which cause delays and unproductivity.
When the release cycle reduces to days or even hours you reap another benefit. Introducing new features is fast. Testing scenarios (even with part of your customer base, using A/B testing) is simple.
A neat side effect of automation for the deployment pipeline is that it makes non-authorized changes really hard to sneak in.
And it forces Ops and Dev guys talking each other frequently – probably the biggest benefit of all.