DevOps Zone is brought to you in partnership with:

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. Server Provisioning

  • submit to reddit

In my two previous blogs I compared deployment automation to build automation and release management automation respectively. Build automation tools automate the building of software while deployment automation focuses on deploying the software after it has been built. In the other blog I explained that release management tools manage the release process of software but don't do the actual work. In this blog I will compare deployment automation to server provisioning automation and here the distinction is harder to make. So please bear with me!

Let's start by defining server provisioning. We can look at the ubiquitous Wikipedia definition or at the one from wordIQ. They tell a similar story; Server provisioning is about making a server ready for service. It usually involves activities such as:

  • Selecting a server from a physical server pool or selecting a hypervisor, whichever is applicable.
  • Selecting an image to install (for a physical server) or an image to run (for a virtual server).
  • Intalling and booting the image.
  • Assigning and configuring resources (IP address, disk space, etc.).
  • Installing and configuring middleware.
  • Installing and configuring applications.

There are a number of commercial products (such as CA Server Automation, HP Server Automation and IBM Tivoli Provisioning Manager for physical servers and IBM CloudBurst for virtual servers) and open source tools (like Chef and Puppet) that automate this process.

If we take a closer look at that list of activities, there is one that is of particular interest to us; The last step "Install and configure applications" is really about deploying an application! If we were to zoom in here, we'd see activities like the ones described in Robert van Loghem's blog So what is a deployment really?. One could say that deployment automation is a subset of server provisioning. But that is not the complete story because there are some things that are very specific to deployment automation.

First, while server provisioning is usually solely the responsibility of the operations department, deployment automation tends to be a shared responsibility of the development and operations departments. The developers deliver the applications to be deployed, the operators maintain the environments onto which those applications will be deployed. That means that a deployment automation tool should distinguish between the different ways the different groups use the tool and it should have security features in place to make sure that either group does not accidentily change the wrong bits.

Secondly, the lifecycle of servers is different from that of applications. For every server, there might be 10 applications deployed onto that server and each of those applications might be (re)deployed at least 10 times, which makes for applications being deployed a hundred times more often than servers being provisioned! And that means that deployment automation tools should be so easy to use so that everybody in the IT department, be they developers, testers or operators, can perform a deployment to keep up with the deluge of application deployment requests.

Of course, there are two current trends that blur the boundary between server provisioning and deployment automation. On the one hand, the Devops movement is about having a multidisciplinary team that is responsible for application development and deployment, and for infrastructure setup and configuration. But even then the lifecycle of servers will be different from the lifecycle of applications. On the other hand, cloud infrastructure means that (virtual) servers will be provisioned more often, maybe even just for the duration of a test. This causes the server lifecycle to become shorter and even become part of the application lifecycle. In fact, one can envision (virtual) server provisioning tools and deployment automation tools becoming ever more integrated as cloud infrastructure become more popular.

Apart from the high level differences described above, deployment automation tools also tend to have different standard functionality. To put it plainly, the most basic functionality of a Java EE application deployment automation product is to deploy an EAR file, while the most basic functionality for a Java EE server provisioning system is to install an application server. But talk about the creation of a datasource and the distinction becomes harder to make. Luckily the devops movement and cloud infrastructure may soon cause the distinction to disappear altogether! And then we will need tools that combine the features of the current server provisioning tools and the current deployment automation 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.)


Igor Laera replied on Tue, 2010/12/21 - 10:34am


If you have to test your application with three different appservers and three different database-backends, and potentially new installs and a "updated" version with data from existing customers, you end up a matrix with lots of combinations. Just add different OS and DB versions to the mix and the tests gets really crazy.

Without any deployment automation, this would be nearly impossible to manage. But deployment alone is not the problem. Some tests are hardware intensive, you can't run certain combinations of tests without annoying others or getting component timeouts. Sometimes your access to certain components like databases or special appliance is limited after the working hours. This adds the burden of resource planning to the mix.

If your projects allow it, most tests run automatically. If not, you have lots of manual tests (with test results) which you need to track continously. If a failed test results in a bug report, you might need a way to get the developer the right combination of os, application, components etc. so he can assess the bug. Not many developers are very well versed in complex deployment, os  and environments-setup. Even when they are, documentaiton of the machines is often "in flux". It might take hours to get "to the bug", instead they hunting down the matching scripts, passwords and what else.

Deployment automation available by "normal" users saves not only time and money, but also limits those unwanted "personal settings/changes" that make the quality of test results sometimes questionable.

The solution in my last project was self written quite complex, datadriven deployer. I don't think a good opensource solution exists in the same 'hemisphere' as build managers and repositories do today.

Comment viewing options

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