Previously I have focused on build performance in posts like Speeding up the pipeline by slowing down builds and Rethinking personal builds, but there is a lot more to a continuous delivery pipeline than build times.  Once a build produces artifacts, you need to do something with them.  Often the next step is to install the product onto a machine for either testing or production use.  The installation is typically a process such as copying a zip to a machine and unzipping it or running an install program, but can sometimes be more complicated when special configuration is required.  Below I describe how we have started using IBM UrbanCode Deploy to allow builds to easily and automatically install, configure and invoke server applications onto machines in the cloud before an application installer has even been created.

Server applications can be rather complicated.  Looking at all the files that need to be installed in various places, it can seem like a random set of pieces with little rationale behind it.

But typically most of the numerous different pieces can each be grouped into one of a handful of groups.

Each of these groups is associated with a component in IBM UrbanCode Deploy and, as the build runs, it publishes each group of files as a new version of the component.  As soon as all of the components have been published, the build requests a deployment of the application.  The application deploy process looks something like:

Each step in the application process invokes a component process.  One nice feature in IBM UrbanCode Deploy is the ability to create component templates–defining things such as how to install and configure something like a particular type of web server only needs to be done once in a template and then any number of components can use that template to get the desired functionality.  This means that after getting things to work for one application, it is easy to scale up to multiple applications that follow the same general pattern.

We have the build publish a link to the deploy process log in a “uDeploy Links” section of the build result external links.  If for some reason the deploy fails, the build is marked red and using those links can help identify the cause of the problem.  In my experience, I have found IBM UrbanCode Deploy to be very stable and after the initial setup everything “just works,” but sometimes people make changes that break things.  The build also publishes Urls to the deployed servers (in our case we want both HTTP and HTTPS links).  The screenshot of the Awesome (build and server names have been changed) build result shows the links created for the deployed Nifty and Neato application servers.

Before integrating the build with IBM UrbanCode Deploy, we relied on manual or ad hoc mechanisms to install and run our server applications.  Now we are able to rapidly and reliably deploy server applications for every build to machines in the cloud in less time that it takes to even create an installer.  In my next post, I will share how these deployed servers have enabled us to improve and automate our system testing.

Nathan Bak
Software Engineer, Master Inventor
IBM Rational