Deployment is the new build (part 1)

Earlier this year, I was invited to present a talk at Devopsdays Boston about deployment as the new build: how deployments are carried out now, how they will need to adapt in a more virtualized, on-demand application landscape and what fundamental improvements will need to come before deployment matures into the invisible, it just works™ experience build is today.
In this first post, we’ll focus on some of the changes and trends across the industry that have brought such increased business attention to the area of release, deployment and management of applications.

As companies focus on tuning their IT environment on rapid delivery of business value, more and more projects and initiatives within organisations are looking at the entire value chain of software production.
Whether under the banner of Devops, via integrated project teams or as part of the introduction of new development methodologies like Agile¹ or infrastructure technologies such as cloud², there is a growing awareness of the need for automated, reliable and flexible deployment procedures.
Whilst it’s clear that the generation of customer features takes place within the development, testing and QA teams, the business value inherent in these features is only unlocked once the application is actually running in a target environment, accessible to users. And it’s not just the final release to production that requires a deployment: every UAT, performance or integration test generally needs an application running in a “real” environment, not a developer’s local machine. One test, one deployment.
Given the well-known costs and adverse effects of faulty software in production, the ability to raise quality, usability and performance through a greatly increased number of testing cycles represents significant added value in itself.
One of the consequences of this increased attention is that the importance of build, release and deployment professionals as deliverers of business value is being recognized more and more. The heightened focus also means, though, that many companies are realizing that the effectivity, simplicity and overhead of their release and deployment processes lag far behind that of build and continuous integration.
As my role at XebiaLabs involves studying, automating and improving deployment processes across the industry and helping developing our vision for deployment into the future, the question of why deployment is so different from build in today’s enterprises was bound to raise its head sooner or later. The resulting discussions and reflections formed the basis for this series.

What’s in a word?

One of the challenges surrounding the discussion of deployment in relation to build, release, provisioning and other tasks in the ALM space is the – decreasing, thankfully – lack of a clear shared definition for deployment. Without wanting to promulgate this as the correct definition, for the context of this discussion I’d like to treat deployment as the process that

takes the components that make up a release (typically a specific version of an application) and getting them correctly set up in an infrastructure environment so that the release is accessible to (end) users

This would differentiate it from build and release in that it assumes that the application components have already been created, and from provisioning and other infrastructure tasks in that the target infrastructure is already assumed to be present.
On-demand virtual or cloud environments, or virtual appliances, put a bit of a different spin on the issue, and will be a topic for a subsequent blog.

Blast from the past

Taking the above as our working definition, the sobering picture is that, with very few exceptions, deployment now is pretty much at the stage where build was in the days of the make guru: a black box put together and operated by a specialist that somehow works. With luck, this precious resource is still employed and around to fix or extend things when required, but if he or she is out to lunch you’re simply out of luck.
To be fair, there are quite a few places where there is least tooling or automation in place that tries to map out the sequence of steps or actions required to carry out a deployment, to at least bring some visibility and traceability and shine some light on the ‘magic’. But this is still a long way away from the push-button experience that build is nowadays. Laboriously visualizing and walking through a process step-by-step is still a sign ultimately of a lack of trust; a truly mature process doesn’t display its internals any more, it “just works”. Much like build today.

The road to “just works”

Of course, build didn’t start out as a “just works” process either, so what actually were the steps that made this transition possible? Looking at the evolution of Java build tooling over the past decade or so, there have been at least three main developments:

1. Reusable commands
2. Models
3. Conventions++

We’ll dive into the details of these three concepts in the next blog…