Continuous delivery with Rational Team Concert and UrbanCode Deploy, Part 1

An out-of-the-box implementation


Content series:

This content is part # of # in the series: Continuous delivery with Rational Team Concert and UrbanCode Deploy, Part 1

Stay tuned for additional content in this series.

This content is part of the series:Continuous delivery with Rational Team Concert and UrbanCode Deploy, Part 1

Stay tuned for additional content in this series.

This series of articles presents two mechanisms for integrating IBM Rational Team Concert™ and IBM® UrbanCode Deploy to create a continuous delivery process. The first approach included in this article, Part 1, is a packaged out-of-the-box implementation that is easy to set up. The second approach, presented in Part 2 and Part 3, uses extensions to the Ant build.xml file.

Many organizations benefit from a continuous integration process that performs a complete build and unit test of software components after a user commits the updated source code to the source code repository. The immediate build of the complete system, and the running of unit tests, is an excellent validation that the changes committed by the developer are satisfactory and have not caused an integration error. However, the level of testing that can be performed at this stage is limited and does not serve to confirm that the application delivers the required functions correctly, nor does it allow for performance or security testing. The only way to carry out such operations is to deploy the application into a runtime environment and run the application in a production-like manner. The extension of the continuous integration process from build and unit test to a process that also deploys an application into a runtime environment is known as the continuous delivery process.

This first article in the series of three begins with a review of the elements of Rational Team Concert that deliver a continuous integration capability. If you are familiar with Rational Team Concert you might want to skip ahead to the Continuous delivery section.

Key concepts and terms

These are important concepts and terms for collaborative development using Rational Team Concert.

Streams serve as a collection point for changes. They contain the cumulative result of all development work. Users 'deliver' changes to a stream and in order to keep their workspace up to date they 'accept' changes from the stream that have been delivered by other users. The stream is similar in concept to a branch in many other version control systems.
Change set
When changes are made to files under version control within Rational Team Concert they need to be managed and tracked. Change sets are a mechanism for grouping file and directory changes together into sets that logically form a complete unit of work. This grouping task is performed as part of the check-in process of Rational Team Concert. In most scenarios, a change set is then associated with a work-item (such as a task or defect) which enables the context of the change set to be visible. Through change sets team members can view the changes performed make sure the requirements of the work item met.
Delivery is the transfer of file changes from a developers' isolated workspace to the stream that is currently associated with the workspace. The result of a delivery operation is that new files or new file versions are stored within the stream and are available for other developers associated with the stream. Other developers can be informed by the Rational Team Concert user interface of the presence of new content and they can choose the appropriate time to accept the changes.
Accept is the process of updating a users' workspace with new file content recently delivered by other users.
User workspace
Each user has a repository workspace that is connected to the stream into which they deliver their work. When a user makes a change to a file the edited copy is held in a client-side sandbox associated with the repository workspace. When the user completes the changes the file is checked in and is copied from the client to a server-based area of the repository. The file is collected into a 'change set' with other files that user has also changed. When the change set is complete the user delivers the change set to the stream.

Collaborative development with Rational Team Concert

Figure 1 shows the user interaction with the stream. User 1 checks-in file changes into the server side repository workspace and creates a new change set. The change set is then associated with a work item to give the change set context. The work item (and associated change set) is then delivered to the shared stream. Developer 2 accepts the changes which updates their repository workspace and copies the file changes to the local hard disk where their repository files are stored.

Figure 1. Stream check-in, delivery and accept
Developers checkin and the deliver their code
Developers checkin and the deliver their code

Continuous integration

Figure 2 is an outline of the interaction within the continuous integration process.

Figure 2. The process of developers and build automation sharing application code
Developers and a build process share a stream

In Figure 2, three developers share their work via a common development stream. For example, John completes a piece of work and delivers it to the development stream. Sue and Chris then have the option to accept that work into their workspace to enable them to integrate John's changes into their work. This process creates a collaborative environment in which the developers have the isolation they need within the workspace to do their work, but they also have a controlled integration process using the development stream. A special workspace exists that is connected to the build process. At periodic intervals, which could be as short as every minute, the build process is initiated and the build workspace looks for new changes delivered to the development stream. If the build process finds that there haven't been any changes since the last build then it simply stops the build. If the build process does find new changes that have been committed then a build is run and a result is generated containing any appropriate records of binary objects created and unit tests that have been exercised. Figure 3 shows an example of the build process in detail. John completed work on two change sets (associated with work items numbered 2012 and 2013). John delivers the changes to the shared stream, which results in an invite for Sue and Chris invited to accept the changes and update their workspaces. Chris then completes work on defect 1985 and delivers the work item and the associated change set. John and Sue then accept that change set into their workspaces.

Figure 3. An example of changes being delivered and collected into a build record
Developer changes are included in a build record
Developer changes are included in a build record

The scheduled build process starts after the users perform the delivery operations described in the Delivery key concepts and terms section. The resulting log files and binary objects are stored within the Rational Team Concert build record and a new snapshot is produced. The snapshot is associated with the build record. In most cases the production of the binary object such as a JAR file, WAR file, EAR file, EXE file or some other file format is the end of the build process. The ability to cleanly build the integrated application code and pass all automatically run unit tests is a measure of the quality of the work and a good sign that the project team are working towards a common goal. However many teams want to go further and extend the process to deploy the application to a run-time environment for further testing operations.

The Rational Team Concert build process

It is not possible, within the space available in this article to present detailed information on the Rational Team Concert build process or on build.xml files. Further information on how to create a Rational Team Concert build process is available in the product help pages and in many web-based articles:

If you want to see details of how the IBM development team builds the Rational Jazz product family using Rational Team Concert read "How we use CLM to build CLM."

Continuous delivery

When constructing a continuous delivery process there are further tasks that need to be performed to actually install the binary object in a run-time environment. Rational Team Concert is responsible for the build and unit test aspects of the process (the continuous integration stage) and UrbanCode Deploy is responsible for the deployment. In simple terms the boundary between the two products is the binary file to be deployed. Rational Team Concert produces the binary file and UrbanCode Deploy uses that binary file and deploys it into an environment.

A team can perform more realistic functional, performance and security testing on an application that has been deployed to a run-time environment. This is one of the reasons why the deployment operation has such value. This process also makes deployment part of the standard operating procedure of the team and ensures that everyone has an awareness of the deployment environment, the requirements for deployment and the issues that result when deployments do not work smoothly. Over the many weeks of development work the development team performs hundreds, perhaps thousands of deployments of the application to development and QA environments. As a result, the application deployment process is tested, tuned and modified during the development phase to the point where there is a high level of confidence in the process for deployments to pre-production and production environments.

A simple continuous delivery process

You can create a simple continuous delivery process using entirely graphical mechanisms to connect the Rational Team Concert build process to the UrbanCode Deploy solution for automated deployments. A new post-build deploy option was added to the Rational Team Concert release 4.0.5 on includes a new-post-build deploy option which allows the build process to interact easily with UrbanCode Deploy. You can add the post build deploy feature to an existing build process by opening the build definition. Click on the words Build Definition at the top of the screen then select Configure. The Post-build Deploy option is available on the Post-build tab.

With this simple process you can upload newly built content into a new version of a single UrbanCode Deploy component. An option to invoke a deployment if necessary exists.

Figure 4. Add the post-build deploy option to an existing build
Dialogue box to enable the post-build deploy
Dialogue box to enable the post-build deploy

Configuring the post build deploy

The post build deploy process requires the user to fill out certain properties. The information required is:

  1. The URL of the UrbanCode Deploy server.
  2. The name of a user to use for the login process to UrbanCode Deploy.
  3. The password or an authentication token for the user identified in step 2.
  4. The name of the component into which the new component version should be stored.
  5. The version name to be given to the newly created component version. Generally the build identifier is used as at least a part of the name using the ${buildLabel} syntax.
  6. A base directory reference which identifies a section of the location upon which the built artifacts are stored. The content required to be stored in the new component version in UrbanCode Deploy is taken from this base location.
  7. The set of files to be included in the new component version. This is a pattern match for the files that are required. A pattern match of **/* will take all files.
  8. The set of files to exclude from the new component version.
  9. Any properties required to be copied to UrbanCode Deploy. Such name/value pair properties are added to the component version as new properties. These are accessed during deployment operations. The format for such properties is: : snapshotUUID=${team.scm.snapshotUUID}
  10. Any links to create on the UrbanCode Deploy component version such as a link back to the Rational Team Concert build record. The syntax of what to include in this link is obtained by loading any build record in a web browser and copying the appropriate section of the URL. An example of a complete build record link is:

The build result to add includes the entire URL up to, and including, the '=' sign. The remaining build result identifier is replaced with the parameter ${buildResultUUID}.
The repository address is also replaced with a parameter in listing 1.

Listing 1. Build result
Build Result=${repositoryAddress}web/projects/JKE%20Banking%20%28Change%20Management%29#${buildResultUUID}
  1. The final section of the post build deploy configuration includes a tick box to indicate whether a deployment is required to start after the new component version has loaded.
  2. If a deployment is required to start the user must identify:
    • UrbanCode Deploy application
    • Application environment in which the deployment should run
    • Application process to run.

Figures 5-7 show a completed post build deployment configuration.

Figure 5 shows the server connection, and the user credentials that are used to establish the connectivity to UrbanCode Deploy

Figure 5. Post build deploy – Server connection
UrbanCode Deploy server connection credentials
UrbanCode Deploy server connection credentials

Figure 6 shows the Publish Artifacts page in which you enter the name of the component that is to receive the new versioned deliverables. You can also specify the version identifier to be used by UrbanCode Deploy to name the new version. The example in Figure 6 shows the ${BuildLabel} syntax uses the date and time stamp build label recorded in the Rational Team Concert build record.

Figure 6. Post build deploy – Publish Artifacts
Artefacts to publish to UrbanCode Deploy
Artefacts to publish to UrbanCode Deploy

Figure 7 shows the process to run after publishing the new version of the component in UrbanCode Deploy. The invocation of a deploy process is optional as dictated by the state of the Deploy check box shown at the top of Figure 7. To run the deployment, type in the name of the application, environment and process to use.

Figure 7. Post build deploy – Process request form
UrbanCode Deploy process to run after publishing
UrbanCode Deploy process to run after publishing

Results of running a post build deploy

After successfully running a post build deploy operation the selected files from the build process are stored in a new version of the identified component in UrbanCode Deploy. That UrbanCode deploy component version contains a link that points back to the Rational Team Concert build record. The record opens in the web browser interface when selected from UrbanCode Deploy.

If requested, a deploy operation is invoked by the Rational Team Concert build process too. The result of that operation is contained within UrbanCode Deploy. There are no links from the UrbanCode Deploy application deploy result record to the Rational Team Concert build process. All links between the products are from the UrbanCode Deploy component version to the Rational Team Concert build record.


The continuous delivery solution presented in this article is simple to set up and operate. It will help teams push content to UrbanCode Deploy and invoke a deployment of that content. One of the key benefits of this approach is the fact that deployments can be run without a developer having to learn another tool to make that happen. All they need to work with is their existing source code management and build product.

Downloadable resources

Related topics


Sign in or register to add and subscribe to comments.

Zone=DevOps, Rational
ArticleTitle=Continuous delivery with Rational Team Concert and UrbanCode Deploy, Part 1: An out-of-the-box implementation