Implement continuous delivery using IBM UrbanCode Deploy

Explore a DevOps solution on SoftLayer


DevOps is an enterprise capability for continuous software delivery that can enable organizations to seize market opportunities, respond more rapidly to customer feedback, and balance speed, cost, quality, and risk. By applying lean and agile principles across the software delivery lifecycle, DevOps helps organizations deliver a differentiated and engaging customer experience, achieve quicker time to value, and gain increased capacity to innovate. IBM offers several software products to support a DevOps implementation. In this article we describe how to implement a continuous delivery solution using IBM UrbanCode Deploy, from the aspects of design to the implementation details.

We based this article on our case study of the implementation of DevOps for Workload Automation as a Service project on SoftLayer.

Design your continuous delivery solution

The design phase is important for creating a continuous delivery solution. It's when you translate functional support and training requirements into preliminary and detailed design.

During this phase, you:

  • Identify the components.
  • Define the continuous delivery workflows.
  • Define the environments.

Identify the components

During the design phase of the solution lifecycle, you design an architecture showing the interrelationships of the components of the solution. The components are all the software components you'll include in the continuous delivery solution.

In our case study, we identified two main components in the Workload Automation as a Service (WAaaS) architecture: the Workload Automation Master and the Dynamic Workload Console.

For each of your identified components, design all the deployment, configuration, and operational processes that can be run on the specific component.

In our environment, we identified the following processes:

  • Workload Automation Master component processes
    • Deployment process to update the component
    • Operational process to move the workload from a primary Master component to the backup Master
    • Operational process to move the workload from a backup Master to the primary Master
    • Operational process to perform health checks after a deploy
  • Dynamic Workload Console component processes
    • Deployment process to update the component
    • Operational process to join the component to the cluster configuration
    • Operational process to disjoin the component to the cluster configuration
    • Operational process to perform health checks after a deploy

Design all the processes. Specify all the logical steps that compose each process.

Deployment processes

Start the deployment process design phase by choosing between native or an ad hoc deployment.

  • Native deployment uses the official product installation. This approach allows a fast and easy implementation. The disadvantages are that the deployment is time consuming and the artifact used is big in size. In a continuous delivery solution, usually, the update done on a component is based on little changes and do not require a complete upgrade of the product. We recommend this approach for a complex update process.
  • Ad hoc deployment implements all the steps need to deploy the changes on the component. This approach takes less is to deploy the changes than the native deployment. The artifacts used during this deployment are smaller than those used in native deployment. The processes that you build in UrbanCode Deploy give you much more control of the steps to execute. This approach requires a complex design and implementation.

To choose the correct approach, evaluate the pros and cons of the different aspects. You want to consider:

  • The availability of a native installation with respect to the development of a new process workflow in deploy.
  • The possibility to decompose the installation in smaller pieces that could require less time to build and deploy.
  • The size of the artifact to be installed. In our case, the image of our components had to be transferred over the internet to the SoftLayer cloud.

In the WAaaS project we analyzed the different approach for both Master (see Table 1) and Dynamic Workload Console (see Table 2).

Table 1. Comparison of installation methods for Workload Automation Master component
Workload Automation Master componentNative installationAd hoc deployment
Implementation time3 days30 days
Deployment time15 minutes10 minutes
Artifact size1.6 GB~800 MB
Table 2. Comparison of installation methods for the Dynamic Workload Console
Dynamic Workload ConsoleNative installationAd hoc deployment
Implementation time3 days5 days
Deployment time40 minutes10 minutes
Artifact size1.2 GB400 MB

Due to the number of steps and complexity involved in the installation process of the Workload Automation Master component, we considered the native installation more convenient. However, for Dynamic Workload Console deployment we chose the ad hoc approach.

After determining your installation methods, you must create the design of the logical processes, and identify all the steps that compose each.

We based the native installation of the Workload Automation Master component on IBM Installation Manager. The steps to update (deploy) are:

  1. Download the package (artifact).
  2. Stop the Workload Automation Master processes.
  3. Configure the response file.
  4. Run silent installation using the configured response file.

The steps to update (deploy) Dynamic Workload Console using the ad hoc approach are:

  1. Download the package.
  2. Stop the Dynamic Workload Console processes.
  3. Deploy the WARs files.
  4. Unzip payload.
  5. Start Dynamic Workload Console processes.

Operational processes

Operational processes are used to define operations to be performed before and after the deployment of the new version of the component. In our WAaaS project we identified several operational processes for both Workload Automation Master and Dynamic Workload Console.

The operational process design phase is when you define the steps for each identified process. For example, the operational process to move the workload from a primary Workload Automation Master node to the backup (secondary node) requires four steps:

  1. Identify primary node
  2. Move the workload from primary to secondary
  3. Stop process on primary node
  4. Start process on secondary node

Define the environment

During the design phase it is important to define all the environments that you will include in your continuous delivery solution.

In this phase, identify your test and production environments.

In our WAaaS project we identified three main environments:

  1. Quality assurance (QA) environment
  2. Staging environment
  3. Production environment

For each environment, identify which nodes are included and then which components should be deployed for each node.

You must identify the network for each node also.

In the WAaaS project:

  1. All nodes in the QA environment are in a IBM network
  2. All nodes in the staging environment are in the SoftLayer cloud and are associated with a staging account
  3. All nodes in the production environment are in the SoftLayer cloud network and are associated with a production account.

Though both the production and staging nodes are on the SoftLayer cloud they are located on different networks.

Define the continuous delivery workflows

Starting with the components and environments designed in the previous sections, design the worflows of your continuous delivery based on when and how the component should be deployed and configured on the different environment. Start from the overall workflow and define the relationship between the environments.

In the WAaaS project the overall workflow begins with development activities. After a build verification test (BVT) completes successfully, the build is copied into the build repository. As soon as a new build is available into the build repository, the QA environment update starts and the automated test cases are performed.

If the automated test cases complete successfully the build is certified as QA passed and the staging environment is automatically updated. After the staging automated tests complete successfully the build is ready for the production environment, which is also updated after an approval process.

After you define the overall workflow, you must define the workflow for each specific environment: the sequence to deploy the components in the environment, and the prerequisites and the preconditions.

For example, in the WAaaS project we defined the workflow for the QA environment as:

  • Update all the components in a parallel way
  • Run the test automation
  • Certify the version as QA passed

Implement your continuous delivery solution using Urbancode Deploy

After completing the design specifications, you can start the implementation phase. You must configure the environments and implement the identified components as UrbanCode Deploy components, the environments as UrbanCode Deploy application environments, and the workflow as application processes.

The steps required to implement your solution are:

  • Physical environment installation and configuration
  • Components implementation
  • Application implementation

For each UrbanCode Deploy object (resource, environment, component, application), you must specify the team who can read, modify, and use the specific object.

Within the team, you can define different roles. Each role can have specific permission, for example, read, modify, delete, and so on.

You can configure the security settings in Setting >Security.

Physical environment installation and configuration

First, set up the environment.

In the WAaaS DevOps solution we set up the environment as shown in Figure 1.

Figure 1. Workload Automation as a Service DevOps solution architecture
Continuous delivery solution architecture
Continuous delivery solution architecture

For the UrbanCode Deploy installation we used two virtual machines, hosted on vSphere servers, for the database and one for the UrbanCode Deploy server itself.

For the first implementation we opted for a simple solution with a Windows® machine with MSSQL server, and a Linux® RHEL 6 machine for the UrbanCode Deploy server.

During the installation of the RHEL machine, we defined separate logical volumes for /, /var, /usr, /home, /opt, and /tmp, disabled the firewall, and set the run level to 3.

The UrbanCode Deploy machine also mounts a share from an Network File System (NFS) server to use as repository for the installation image, which adds more flexibility in managing the disk space.

From the UrbanCode Deploy server we had to manage multiple independent environments, a staging and a production environment in the SoftLayer network, and possibly more remote environments.

The SoftLayer network can be reached using a VPN. But because a VPN was not an option from our lab, we used a different approach. Since we assigned a public IP address when we deployed the machine, we decided to leverage this interface to establish the communication between the server and the relay.

We installed UrbanCode Deploy relay agents on Linux RHEL 6 machines defined in the SoftLayer environments, one relay machine for environment; these machines have a private interface in the SoftLayer network, and a public interface.

We configured iptables to drop connections on any port in the public interface, except for SSH connections originating from IBM public addresses; SSH is set up to only accept public key authentication on the public address.

The UrbanCode Deploy server then sets up SSH connections to the remote relay servers, forwarding the server's ports to the relay, and the relay ports to the server on a 127.x.x.x interface.

For example, for the production environment we used the command:

ssh -f -n -N -x -R 8080:localhost:8080 -R 8443:localhost:8443 -R 7918:localhost:7918 -R 
1099:localhost:1099 -L -L -L -o 
StrictHostKeyChecking=yes -o ExitOnForwardFailure=yes -M -S 
/tmp/ssh-${remote_user}@${production_relay}:${ssh_port} -p ${ssh_port} -l ${remote_user} $

This command starts a background SSH process that forwards the relay ports to the loopback address, and the server ports to the relay. Using the ControlMaster and ControlPath options allows us to easily check if the connection is still working (with the OpenSSH -O option) and restart it as needed. We set up a periodic job that checks the connection every five minutes and restarts it if needed. Thus the UrbanCode Deploy server talks with every relay using the same ports on different loopback addresses, and allows us to support all the remote environments we need. That capability helped us manage the staging and production environments we created in two different cloud in SoftLayer.

To speed up the transfers with the SoftLayer environment, we also set up a remote repository on the remote side. We installed an Apache HTTP server on the relay, and exported a directory with the installation images. The agents access the images using standard tools like curl and wget, which minimizes the network traffic within our lab.

Component implementation

First you must define a new UrbanCode Deploy component for each component that you identified during the design phase.

To define a component:

  • Configure the source repository.
  • Specify the component properties.
  • Implement the component processes.

Configure the source repository

Each component requires the definition of a source repository, that will contain the different versions of the artifact. In the WaaaS DevOps project we used the versioned file system as the source repository. We configured UrbanCode Deploy to import the version automatically, as shown in Figure 2.

Figure 2. Component definition in UrbanCode Deploy
Component configuration panel
Component configuration panel

Each time a new version of the component is available, it is copied on the file system in the path /ucd_data/DEVOPS/WAaaS_Master/<version_id> and UrbanCode Deploy imports it.

You can select the Versions tab to monitor all the versions imported into the system, as shown in Figure 3.

Figure 3. List of component versions in UrbanCode Deploy
Component version tab
Component version tab

In System > Settings > Artifact Cleanup we defined a clean policy to save only the most recent four versions.

Figure 4. Cleanup policy definition in UrbanCode Deploy
Artifact cleanup policies
Artifact cleanup policies

Specify the component properties

You must use parameters with a default value defined at component level. For example, the installation path for a specific component can be defined as a property. Most likely this value will be customized for each environment and resource. However, defining a default value at the component level can be useful. You can define a new component property from Component > Configuration tab > Component Properties.

Implement the component processes

Component processes describe automated tasks that run on components. Component processes can deploy, install, uninstall, update, or run other tasks on a component. You can define a new component process from Component->Processes.

Figure 5. Component process creation in UrbanCode Deploy
Component process definition panel
Component process definition panel

There are different process types:

  • Deployment deploys a component version to the target resource and updates the inventory after a successful run.
  • Configuration deployment is a configuration-only deployment with no component version or artifacts. This setting applies the configuration (using properties, or configuration templates) to the target agent and updates the resource configuration inventory afterward.
  • Operational runs arbitrary steps given a component version and does not add or remove any artifacts or configuration.

A component process is composed by steps. Available steps are listed in the "Available Plugin Steps" list. UrbanCode Deploy provides several utility steps and plug-ins.

In our component processes, we used several types of utility steps and plug-ins. For example we used:

  • Download Artifacts to download the artifact from IBM UrbanCode Deploy repository to the agent.
  • Shell Scripts to run a shell script on the machine.
  • Unzip to unzip a ZIP file.
  • Set/Get Properties to retrieve the value of a IBM UrbanCode Deploy property (resource, component).
  • Add/Remove Status to version to add and remove status to the current component version.
  • Replace Token to replace a specific token into a list with values. The values can be specified directly in the steps or you can reference UrbanCode Deploy properties.
  • Run Component process to run another component process.
  • Run Generic process to run a generic process.

For each component process step it's possible to define:

  • Precondition

    A precondition is JavaScript that defines a condition that must exist before the step can run. The condition must resolve to true or false. In the WAaaS project we used the precondition to verify the value of a property before run the step properties.get("<properties_to_verify>") == "false". (<properties_to_verify> permitted values are true and false.)

  • Post-processing script

    Post-processing scripts run after a step finishes. Typically, post-processing scripts ensure that expected results occurred. In the WAaaS project we use the post-processing scripts to set the output of the step in a property that can be used from other steps.

    For example we defined the following post-processing script:

    properties.put("result", "default");
    if (properties.get("exitCode") != 0) {
               properties.put(new java.lang.String("Status"), new java.lang.String("Failure"));
       else {
           properties.put("Status", "Success");
        scanner.register("^Output", function(lineNumber, line) {
               var temp=line.split("=");
    var out=temp[1];

    This script sets a portion of the output of the current step as a value of a property called result.

    Using the method scanner.register("^Output", function(lineNumber, line) finds the row in the output that starts with the output string. Then the script identifies the string after the "=" and sets it as a property called result. For example, if the output of the step is Output=value1, the property result value will be value 1.

You can pass property values between steps. If you set a specific property in a step using the post-processing scripts, you can use this property in a different step using the syntax ${p:<stepName/PropertyName>}.

Component process flow

All component process steps must be combined to create the process flow. In the process flow you can use steps to join the previous steps, switch to create a conditional step, and so on.

It's possible to specify different flows based on a step's result (success, fail, both).

Figure 6. Component process design in UrbanCode Deploy
Sample of component process
Sample of component process

Because the component process flow can be complex, it may help to create subprocesses and use them in the process using the step Run component process.

Figure 7 shows an example of a component process implemented for the Update Master process.

Figure 7. Example of component process implemented for Update Master
Sample of complex Component process
Sample of complex Component process

Define the application

In the implementation of a continuous delivery solution, after the components creation and the agents installation, you must create an application.

The applications in UrbanCode Deploy bring together all the components that must be deployed together. They do so by defining the different versions of each component and defining the different environments that the components must go through on the way to production. The applications also map the constituent hosts and systems (called resources) that a component needs within every environment.

The applications also implement automated deployments, rollbacks, and similar tasks. These tasks are called processes. However, at the application level, processes are concerned only with the components and resources that are necessary for deployment and related tasks. By contrast, component processes are concerned with running commands and related tasks.

Figure 8. Application creation in UrbanCode Deploy
Application creation panel
Application creation panel

Define the environment on UrbanCode Deploy

Starting from the application you just created, create a new environment.

Figure 9. Application environment creation in UrbanCode Deploy
Environment creation panel
Environment creation panel

In the Resources tab, specify all the resources that compose your environment. You can structure your environment definition using subfolders.

After you add all the agents that compose the environment, associate the specific components for each agent.

Figure 10. Associate components to the resource in UrbanCode Deploy
Envioronment configuration
Envioronment configuration

Approval definition

If you need the approval on the environment, check the flag "Require Approvals" in the configuration tab of the environment. You can also define a list of exempt processes, a list of application processes that do not need approval to start on this environment.

Figure 11. Approval process definition in UrbanCode Deploy
Environment approval settings
Environment approval settings

Finally, define the specific approval process in the approval process tab.

Figure 12. Approval process definition in UrbanCode Deploy
Sample of an Approval process
Sample of an Approval process

Environment gates

In UrbanCode Deploy, you can specify the conditions that must be met before the application can be promoted to an environment by establishing gates. Gates are defined at the environment level; an environment can have a single gate and or conditionals. Gates provide a mechanism to ensure that:

  • Component versions cannot be deployed into environments unless they have the gate-specified status.
  • Applications reflect the agreed upon quality criteria for promotion.
  • Applications that advance have auditable sign-offs.

When you run an application process on an environment, each component version included in the process must be tagged with statuses specified in the environment gates.

In the WaaaS project we defined the following constraints:

  • A version to be installed on staging environment must be tagged as QA_OK (quality assurance OK).
  • A version to be installed on production environment must be tagged as STAGING_OK.

You can add the statuses to the version manually in the component tab Status or they can be added automatically by component processes using the step Add/Remove status to version.

Figure 13. Environment gates definition in UrbanCode Deploy
Environment gates definition
Environment gates definition

Advanced environment definition

To define dynamic environment read "Manage continuous delivery in the dynamic cloud environment using UrbanCode Deploy" (developerWorks, 2014).

To define remote repository on SoftLayer read "Managing remote repositories on a dynamic cloud network using UrbanCode Deploy" (developerWorks, 2014).

Associate components to the application

You must specify all the components to be used in the application processes in the application. Select your application, select the Components tab, and add all the components you require, as shown in Figure 14.

Figure 14. Definition of the components in the application in UrbanCode Deploy
Association between application and components
Association between application and components

Properties definition

We introduced the component properties in the previous section, but you can use a lot of different properties in the processes depending on the environments or the resources that compose it.

For example, the installation path where you want to install your component can be different due to the resources where you are installing. The process should be general and should be used on all the environments. Thus the installation path can be specified as a variable property. The property can be defined at different levels:

  • Component level is the default value of the property. So if it's not specified at the environment or resource levels, it is set with this value.
  • Environment level is defined under the component's or environment's Properties tab. While both use the same syntax, the latter is not associated with any specific component. Values are supplied on the associated environment or component. A value that is set on a component environment overrides one with the same name set directly on an environment property; and is referenced by ${p:environment/<property_name>}.
  • Resource level properties can include the built-in agent properties and any custom properties. Each of these properties has a tab on the resource and are referenced by ${p:resource/<property_name>}.

If the property is defined in multiple places, its value is determined by the property order of precedence. The following list defines the order of precedence from highest to lowest:

  • Process
  • Component version
  • Resource
  • Agent
  • Environment
  • Component
  • Application
  • System

Define the continuous delivery workflows on UrbanCode Deploy

After you define your environment you can begin defining the application processes. Application processes, like component processes, are created with the process editor. UrbanCode Deploy provides several common process steps. Otherwise, application processes are assembled from processes that are defined for their associated components.

It is possible to define different steps for each associated component, for example:

  • Install
  • Uninstall
  • Rollback
  • Run process for each version
  • Apply configuration

You can define each application process step to be run only on a resource with specific tag.

Figure 15. Limit the process execution to specific tagged resources
Limit process to Tag
Limit process to Tag

Figure 16 shows a sample of the application process for WAaaS QA environment.

Figure 16. Sample of an application process design
Sample of application process
Sample of application process

Run application processes

You can run an application process on demand or you can schedule it. To run a process go to Application > Environment tab and click on the run icon (the bold arrow) as shown in Figure 17.

Figure 17. Run process interface in UrbanCode Deploy
Sample of process run
Sample of process run

It's possible to also define that a specific application process run on an environment each time a new version of a component is created. Go to Component > Configuration and check "Run process after creating a new version" and select the application process and the application environment.

Business benefits

Continuous delivery is an emerging software development methodology that automates and improves software delivery. The objective is to implement the capability to rapidly, reliably, and repeatedly push out enhancements and bug fixes to the customer without compromising the quality.

Continuous delivery provides two significant business benefits:

  1. It enables you to bring your products to market sooner, which enables you to get real feedback from your target market. If your business plan is fundamentally flawed, you want to find that out as soon as possible, not when you've spent months or even years pouring money into implementing your project. Continuous delivery enables you to adapt to your customers' needs and be responsive to their requirements.
  2. Costs become more predictable as continuous delivery provides a process that massively lowers the risk of software delivery, especially when compared to traditional big bang releases at the end of a long project.


We've given you a simple guide to create a continuous delivery solution with an example based on our case study, the WAaaS DevOps project. In this project, UrbanCode Deploy allowed us to create the entire solution in just a few weeks.

Downloadable resources

Related topics


Sign in or register to add and subscribe to comments.

Zone=Cloud computing, DevOps
ArticleTitle=Implement continuous delivery using IBM UrbanCode Deploy