Vincent Partington has more than 10 years of enterprise Java experience. He has written and presented on topics as diverse as performance, security, RIA, and persistence technologies. Vincent Partington is the Chief Technical Officer of XebiaLabs where he is responsible for their flagship deployment automation product Deployit. Vincent is a DZone MVB and is not an employee of DZone and has posted 25 posts at DZone. You can read more from them at their website. View Full User Profile

Deployment Automation vs. Build Automation

  • submit to reddit

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.



Published at DZone with permission of Vincent Partington, author and DZone MVB.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)


Derek Smith replied on Wed, 2010/10/13 - 6:52am

"In fact, anybody building serious software without automating their builds, their tests and without using continuous integration is not considered to be a professional." Really??? Wow!! thank goodness I can become a professional by buying your product..... "At XebiaLabs we have developed Deployit" Geez, this article is such a waste.

Cosmin Mutu replied on Thu, 2010/10/14 - 3:00am

"In fact, anybody building serious software without automating their builds, their tests and without using continuous integration is not considered to be a professional."

By whom definition? :) I think you should have said : "In my own oppinion ... "

"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!"

How about adding this to that list yourself? Instead of using "!" ... yes, exclamation points.

Vincent Partington replied on Thu, 2010/10/14 - 7:36am

@Derek Smith, @Cosmin Mutu: It is not just my opinion that builds and tests should be automated and that continuous integration is necessary. This is a very common practice in software development nowadays. See Maven, Fitnesse and Hudson for example.

The thing that is my opinion is that deployment automation is also an essential part of software development. And yeah, for that you should indeed buy our product ;-).

As for updating Wikipedia: I don't think the requirements for build systems should be extended to include deployment automation. My blog is trying to make clear that deployment automation is something different from build automation. And when the world agrees on that, I might want to update Wikipedia for that. But for now that is just my opinion.

Terence Mill replied on Sat, 2010/10/16 - 5:57am

Just use Hudson, it can deploy (local/remote) on mostly all plattforms, protocols and shells via plugins, eg. WAS, Jboss, Tomcat, Glassfish, start and stop Vmwares to deploy and run tests, sends files via FTP, SCP and execute remote scripts via, hudson slave and many more. If you have or gather some know-how in this technology you can just do it with opensource without the need to buy a product.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.