As companies focus on tuning their IT environment on rapid delivery of business value, more and more projects and initiatives within organizations are looking at the entire value chain of software production.
Whether under the trendy name 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 a (still) active developer whose day job involves studying, automating and improving deployment processes across the industry and developing a 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 deliberations turned into a presentation at Devopsdays in Boston earlier this year.
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 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 another time.
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,