Perhaps the most difficult dimension of DevOps is that DevOps never ends. There is no guide to doing DevOps, and there is no final setup that means you have completed your DevOps journey.
If you treat your current DevOps practice as the final way you are going to ship applications, in a year or so, your environment is going to be Waterfall vNext, because it will not keep pace with the demands of your users, infrastructure, and deployment approaches. That is why you can’t have continuous delivery without continuous improvement.
Let me explain...
Getting better does not happen naturally
DevOps teams with a fully automated delivery chain can point to their success and claim constant improvement. But chances are, if they look back on how they got to the place where they are today, there was some catalyst, a new product, major organizational changes, etc. No matter the something that dictated change, it was not likely proactive. Under that structure, change will only happen if there is a trigger, and those triggers occur once every two years or so.
Continuous improvement is the opposite of this. It means there is a deliberate effort to improve. It is executed a little bit by culture (and a little bit of animosity) towards what you have already done. Even in the most advanced environments, there are weak spots. DevOps teams need to avoid putting their delivery chain on a pedestal. Always be skeptical of how good it is, and find the weak spots, no matter how small.
But culture, and maintained focus on improvement can be hard to carry out. You can’t really create objectives for how many changes a DevOps engineer will implement. You also can’t measure culture in terms of the improvement it instigates. Some environments fall victim to what looks like continuous improvement, but is really a playground approach, a huge detractor of techies playing with new toys that appear to make things better, but actually introduce a lot of additional problems.
There is a way to be highly tactical about continuous improvement, and it comes from being 100% focused on what your delivery chain is and is not.
Your pipeline is an application
Your pipeline should be treated like any application. The application you ship today has continuous improvement built in as a feature. There is a backlog, and your whole job is to add features and fix things—improvment. So if you treat your pipeline like an application, then voila! You have continuous improvement. In order to do this, EVERYTHING must be scripted, anything you do more than once is automated, and you have a backlog of things you want to do to your delivery chain to make it better. Pipeline applications will have features and bugs. And your customers are your developers, and your production environment. It’s amazing what can change when you see your pipeline through a slightly different lens.
The problem is that it implies there are dedicated team members responsible for development of the pipeline, and maintaining it in “production.” Organizations need to be prepared to invest in this.
Knowing you are on the right path is challenge number three. It all has to do with results and metrics. Just like metrics on your production environments, your pipeline has several key performance indicators (KPIs). Continuous improvement is the measure of the delta of those KPIs over some period of time. For example:
- How much faster are your releases since the beginning of the year?
- How many steps does it take? How many steps have you subtracted?
- How many applications were deployed 100% automatic? (There are some non-DevOps variables here.)
- How many more releases did you do this year compared to last?
Improvement is somewhat intuitive. Team members will have a general awareness of whether the pipeline has caused less stress and deployed more applications. But being deliberate about continuous improvement means that you must quantify your wins or losses, and report on them.
Continuous delivery, right now, is confined to the most advanced development environments. But even these environments will soon become “old” and stuck in their ways if they do not embrace continuous improvement. While continuous improvement sounds at first like fluff, a results-oriented and application focus is a tactical way to make sure you are DevOps today, and into the future.
About the Author
Chris Riley (@HoardingInfo) is a technologist who has spent 12 years helping organizations transition from traditional development practices to a modern set of culture, processes and tooling. In addition to being a research analyst, he is an O’Reilly author, regular speaker, and subject matter expert in the areas of DevOps strategy and culture. Chris believes the biggest challenges faced in the tech market are not tools, but rather people and planning.
We’re hiring! Check out the careers page for open positions in Amsterdam, London and San Francisco.
As usual, if you want to stay in the loop follow us on twitter @wercker or hop on our public slack channel. If it’s your first time using Wercker, be sure to tweet out your #greenbuilds, and we’ll send you some swag!