Transforming for DevOps—Part 1: Base principles for DevOps adoption
One of the most common questions I get when talking about DevOps to midsize and larger enterprises is, What does it mean for us to adopt DevOps?
Of course there is the tool perspective, and a lot of (development) tool vendors and open source projects realign their positioning to include “DevOps” or “continuous...” somewhere in the solution description. But for me, DevOps is a strategy, not a technology approach. Of course, when implementing DevOps you sooner or later will need tools, but to be able to fully utilize their potential you have to have a strategy that encompasses people, process and tools equally.
Since most enterprises do not have a problem acquiring a tool (usually they already have plenty of them), I want to focus in this series more on the people and process sides and try to give an answer to the question above.
I'd like to start part 1 with my view on some of the main principles commonly associated with DevOps adoption.
My four main principles for adopting DevOps
When talking about collaboration I very commonly get a reply like this: “Yes, we already have well-defined hand-over procedures.” But that's not what I have in mind. Good hand-over procedures only guarantee that you can use what you get, not that you get what you want.
To be able to achieve a streamlined and automated release process that reaches from development into production you first have to define and standardize this process (without that, there is no chance of automating it).
This requires a different kind of collaboration:
2. Test against a production-like system
This second point should better read: “Test against a production-like system as soon as possible.” Usually due to budget restraints production-like test environments are limited to later test stages, which in turn means that production-related problems can only be found late in the process (which by the way is rather expensive).
This can be overcome by on the one hand injecting the knowledge of what production environments look like into the delivery pipeline design, and on the other adopting virtualization technology like cloud and service virtualization.
Both combined will help to achieve a production-like environment earlier in the application lifecycle.
3. Deploy frequently
Every change applied in production is a potential risk. Huge releases comprised of many changes have a very high risk of failing and also require comprehensive risk management. By getting down the release frequency from quarterly or monthly to weekly or daily, the associated risk is also greatly reduced.
The prerequisite for that is a repeatable and reliable deployment process, which of course has to be tested as well. This also uses results created by my first two points—a collaboratively defined delivery pipeline that includes production-like test environments.
4. Continuously validate operational quality characteristics
When doing the above not only are the software quality measurements during testing important, but the focus will enhance the overall quality characteristics. They have to be aligned with the business-relevant key performance indicators (KPIs), so most likely all the operational KPIs from a service level agreement (SLA) will be of interest here.
If you have other principles in mind, I'll be happy to enhance my list and discuss them with you.
I will continue this small series by talking about agile methodology, the IT Infrastructure Library (ITIL) and cloud and how they fit into a DevOps world, before looking deeper into transformation toward DevOps and how processes and role models will change during this adoption.