Since make was introduced in 1977 to automatically build software, more areas of the software construction and release process have been automated. In fact, anybody building serious software without automating their builds, their tests and without using continuous integration is not considered to be a professional. A hot topic within the application lifecycle management (ALM) space is deployment automation. This is driven by middleware environments getting bigger and more complex, by the increasing number of application releases demanded by modern businesses, and by the fact that application deployment needs to happen reliably to not disrupt online services and businesses. Add to that the fact that cloud infrastructure is becoming more mainstream by the day, you can bet there is a lot happening in this space.

At XebiaLabs we have developed Deployit and that has given us a lot of insight into the deployment automation domain. This is the first blog in a series that will explore that domain by comparing deployment automation with a number of related topics.


In this first blog, I will compare deployment automation to the most well known form of automation in the software development process: build automation. The simplest form of build automation is a shell script that invokes the compiler, but build automation systems have matured way beyond that point. Starting with the previously mentioned Make, and then on to Ant and Maven, build automation tools have provided more abstract ways for the user to specify his build details. For example, most projects can be built using Maven without requiring any scripting. A project descriptor file (a.k.a. the Project Object Model file) tells Maven about the components of the project and Maven's plugins have the knowledge to build the project from that. And as we speak new build automation tools such as Gradle are being introduced that provide even more flexibility. To summarize build automation tools convert source code into executable code.

But can we use these tools to automate deployments? As my colleague Robert van Loghem has discussed previously, deployment is a complicated process that includes steps such as installing EAR files, configuring datasources and restarting servers. Although the definition of "build automation" on Wikipedia mentions "deployment to production systems" as one of the activities in build automation, build automation tools have no built-in knowledge of concepts such as deployment packages (the stuff to deploy), target environments (test, acceptance, production, etc.), or customizations (e.g. what password to use in which environment). Build automation systems also have few built-in integrations with middleware systems on which to deploy and certainly never have built-in deployment scenarios. In fact, all that build automation tools offer in this area is a scripting platform that is well known to the developers and that by default stores its scripts together with the source code it wants to install. This has led to large body of custom written scripts that automate deployments.

All of this is not surprising when one studies requirements of a build automation system as listed on Wikipedia. Deployment is not even mentioned in that list! While a build automation system is about producing executable code, a good deployment automation system is about deploying that executable code to an environment:

As such a deployment automation tool needs to satisfy an entirely different set of requirements:

• Support for concepts central to deployment: packages, environments, bindings, etc.
• Out-of-the-box support for common middleware systems with the possibility to extend the support.
• Out-of-the-box support for common deployment scenarios with the possibility to customize those scenarios.
• Support for different roles: developers deliver software, one group of administrators sets up environments, another group deploys applications, etc.
• Scalable to large environments with many applications and many users.
• Cross-platform support: complex middleware environments can span multiple operating systems and versions.

Existing build automation tools do not address these requirements and extending a build automation tool to support these requirements, leads to an unfocused product that suits neither set of requirements well. And that is why deployment automation tools are emerging as a separate category of products that have outgrown their custom scripting ancestors.

Please don't get me wrong here: deployment automation tools will not replace build automation tools. In fact, they both have their place in the software delivery landscape. Build automation tools produce executable code, deployment automation tools make this code available to users!

In the next blog in this series, I will explain how deployment automation are different from server configuration tools.

From http://blog.xebia.com/2010/10/12/deployment-automation-vs-build-automation/