What is DevOps?

DevOps is a much used term, but it seems like everyone you talk to has a different definition of it. Here's my own interpretation:

DevOps is a series of processes designed to reduce the time between development and deployment. By reducing this lead time, development teams can gather feedback more quickly and iterate their solution, delivering value based on real data and customer feedback.

Viewed through this lens, DevOps is a key component in realizing the true value of Agile Development. As The Agile Manifesto states: "Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage."

So, reducing the time spent getting features out into the wild is key. In practice, that means less time spent in testing and deployment. To do that, the practice of DevOps has evolved a lot of tools that automate and simplify deployment:

• Identical development, staging, and prod environments;
• Version control based management and deployment for all production artifacts;
• Automated environment management;
• Automated tools for testing and analysing code;
• Proactive monitoring.

And lots of other things besides.

The transition that IT has made to virtualisation and Cloud technologies over the last decade facilitates a lot of this, and literally enables computing resources to be represented in code or configuration, which means that they can be version controlled; an absolutely key benefit.

There are fantastic tools available which facilitate a lot of this stuff - things like Ansible, Chef, and Puppet, or PaaS providers like Acquia who provide a lot of this functionality in a service based model - but the principles are what is important.

What does that look like in a digital development cycle?

There's not a lot of value to the customer in those middle steps, and they can easily suck up a lot of time and effort, crippling your organisation's ability to Get Things Done.

By reducing the time and effort in test, deploy, and support & scale, we can begin to get key data and feedback very quickly after code is written. Automating those tasks that are best automated significantly shortens the feedback loop. Over time, that practice lends itself well to smaller and more frequent releases, with each release influenced by feedback about the last.

When something has a lot of momentum, a small adjustment to its course can have a big impact. But if something is moving slowly, then no matter how hard you push you can't have a lot of effect on its trajectory.

That said, there can be a lot of value to the organisation in those middle steps, and ensuring they work well can improve velocity and efficacy, freeing up effort and time to concentrate on higher order tasks. There's a lot of work that needs to happen in that yellow box that helps the whole organisation remain functional. Ignoring "stability, security, scalability, manageability, operability, continuity, and all those other beautiful 'itties'" - non functional requirements - leads to technical debt. Too much technical debt, and your total time spent not delivering value climbs enormously as you begin to spend longer or longer working to undo what you've done. Don't shortcut your process to get features in front of your customers. Setting aside a little time for improvement is just as, if not more, important than achieving your work on any given day.

Show me the data

It's important to approach any fashionable term in IT with some healthy skepticism. You don't want to jump on a bandwagon whose wheels are about to fall off.

Consider this table from the appendix of Gene Kim's excellent The Phoenix Project, based on research from Puppet Labs.

The likes of Amazon, Google, and Facebook run at scales almost beyond comprehension, yet achieve incredible reliability and maintain a steady stream of new features and updates. By maintaining this velocity, they can be very responsive, and are building some of the most valuable companies in the world as a result. None of this would be achievable, and certainly not sustainable, without the kinds of robust processes, attitudes, and automation that DevOps encapsulates.

Puppet Labs runs a yearly report on the state of DevOps. Their 2014 report suggests "Companies with high-performing IT organizations are twice as likely to exceed their profitability, market share and productivity goals." You could argue that companies with functional IT departments are probably pretty functional in all areas - but isn't that kind of the point? IT and Digital are not departments - they are strategic capabilities. DevOps codifies and formalises a lot of the practices of high-performing teams in a framework that is accessible and approachable.

So in short - DevOps is real, and DevOps is good. In a follow up post I'll write about how these principles apply to a Drupal context.