Why so many DevOps conversations focus on Deployment

2

Damon Edwards / April 8th, 2010

Other people’s initial reactions to new concepts or ideas always fascinate me. Sometimes the reactions are in line with what I expected. Sometimes they focus in on something I wasn’t expecting.

One of the more curious reactions I’ve received lately is: “Why does DevOps focus so much on deployment?”.

The subtext is “if bridging the gap between Dev and Ops is so fundamental to the success of the business, then isn’t it myopic to spend so much time on deployment issues and deployment automation?”

There is always the “well, we have to start somewhere” answer. But of course, the real answer runs deeper than that.

The first answer is that Deployment is the primary point at which Dev and Ops are forced to interact. It’s the one interaction in almost any size or type of organization where Dev and Ops can’t escape each other. Deployment sets the tone and expectations for all other interactions. 

Getting deployment right requires you to examine how you exchange information, artifacts, and responsibility as well as acknowledge that the road between Dev and Ops is a two-way street. Get that right and the solutions to the rest of your DevOps problems should be relatively straightforward.

The second answer is that deployment represents the largest opportunity for time savings. For illustrative purposes, let’s take a look at the following pie chart from a 2006 study of Microsoft’s Operations groups.

 

 

Explicit deployment activity is 31% of the overall time spent. If we use the well worn out statistic of 80% of all problem incidents being caused by self-inflicted changes (which usually comes from some sort of deployment activity), that gives us another 16% of overall time being tied up in deployment related activity. 

That means that at least 47% of Ops time is spent on deployment related activity. There are bound to be plenty of opportunities to trim considerable fat from that chunk of time. And that is just a starting point. I’m sure if we looked into some of those other categories, we’d find even more time that was lost due to the ripple effects of deployment activity.

 

Of course, this example doesn’t take into account the time sink that deployment related activities are for Dev. I don’t have hard data on this, but from a quick straw poll of my colleagues, we’d estimate that across our clients anywhere from 10% to 20% of developers time is spent on deployment related activity (including activities like trouble shooting, knowledge transfer, scripting, etc.)

DevOps is broader than deployment (here is a great post by John Alspaw on that topic). However, deployment is the right place to start looking to make improvements if you want to have the largest possible impact on your business.