Walking the DevOps walk

Three years ago, Hymans Robertson created a forum in which developers and operations personnel collaborate to smooth the path of new software features out to production. We’re aiming to drive down the time-to-value without sacrificing the reliability of the deployment process or, indeed, the reliability of the software released. So far, so predictably “DevOpsy”!

Anyone who has been involved in software optimisation will be familiar with the process of identifying a bottleneck, addressing that bottleneck, and then finding that some piece of code that was not implicated in the initial investigation now sits at the top of the list of modules whose performance is constraining the system. The process then repeats.

Stepping out of the world of intangible data structures and algorithms, and into the world of people and processes, we see the same iterative pattern of identifying a bottleneck, resolving it, then moving on to the next. Once we’d optimised away some of the tasks that teams needed to perform to deploy their changes into production – raising tickets for ops support, scheduling deployment slots for the coming week, and so forth – the spotlight then moved to all of the other steps that stand in the way of a slick flow of features out to perpetually delighted users of our apps and APIs.

For example, if it takes hours to build and run automated tests on a system, then this is your new bottleneck. If there are business processes – sign-off, reviews, comms – around each deployment that take hours or even days, then this is your new bottleneck.

It’s tempting, as a technologist, to assume that any problem around software development is best solved with more software. It’s tempting to cast around for newer automated testing frameworks or shiny infrastructure-as-code domain specific languages, or some other deployment-related esoterica, that will deliver the desired ease and speed of releases.

However, the greater scrutiny that has come about with our desire to optimise our deployments has made it clear to me that I’m quick to over-estimate the value of technological solutions and under-estimate the importance of changes around expectations that must accompany the technological changes.

At the most abstract level, the shift in thinking is from “batched” to “flow”. Instead of aggregating the features we want to deploy into a sizable batch, we want to move to flowing features into production as they become ready. Again, this idea has been current amongst DevOps proponents for some years, but this seemingly simple shift has profound implications for the way all team members, including those who might perceive themselves to be quite distant from software development, organise their work.

As with all non-trivial changes to software development processes, this change needs to happen along various dimensions simultaneously. In the coming blog posts, I’ll drill down into the behavioural changes that are easy to overlook when the focus is ostensibly on delivery of technology. Technology will not be ignored, however, which is just as well as Hymans Robertson has recently welcomed Paul Hammant to the team. Paul has written extensively on techniques for improving the flow of features to production and is a man whose ideas I will be shamelessly plundering for future posts!