How To

Using IBM UrbanCode Deploy applications in IBM UrbanCode Release


This post describes how IBM UrbanCode Release represents IBM UrbanCode Deploy applications, and how to run UrbanCode Deploy deployments with UrbanCode Release.  For more information about using UrbanCode Release, visit the Knowledge Center.

After you run an integration, IBM UrbanCode Deploy applications are organized into their constituent parts, which are described in this table:

IBM UrbanCode Release Object

Corresponding Deploy Object


Application environments

Application environments

Application environments must be mapped to release environments.

Automated deploy tasks

Application processes

Automatic tasks must be assigned to automated deployment tasks in the deployment plan.


Application snapshots

Snapshots are selected during the scheduling or running of deployments.



Component versions in the snapshots.

IBM UrbanCode Release and IBM UrbanCode Deploy application architecture


Using IBM UrbanCode Release to run a typical IBM UrbanCode Deploy deployment

To deploy the snapshot v1.1 snapshot for my_application to my_env by using my_release, you perform steps similar to the steps outlined here. Note that you perform most of these steps once.

  1. Run an integration with IBM UrbanCode Deploy. my_application along with its snapshots, environments and processes are imported into IBM UrbanCode Release.
  2. Assign my_application to the team that manages my_release.
  3. Add my_application to my_release. All applications assigned to the managing team are available to
  4. Map my_env to one of the release environments you intend to use with my_release.
  5. Add the release environment with my_env mapped to it to one of the my_release lifecycle phases, and reserve the release environment.
  6. In a deployment plan attached to my_release, create an automated deployment task and assign one of the my_application automatic tasks to it. Because you assigned my_applicaiton to my_release, all of the my_application application processes are available to the deployment.
  7. Schedule the deployment, selecting the previously configured phase, release environment, and deployment plan.

At this point, you’ve identified the application (by assigning it to the release), the application environment (by mapping it to the release environment), and automatic tasks (by defining automated deploy tasks in the deployment plan). The only thing left to identify is the version, snapshot v1.1. During scheduling, you can instruct IBM UrbanCode Release to use the most recent version passing gates. This means that the last deployed snapshot with all expected quality statuses is automatically used. This is a good option if you are sure that snapshot v1.1 is working as expected and already has the necessary quality statuses.

If during a previous deployment, you created an IBM UrbanCode Release version, you can select that during scheduling. An IBM UrbanCode Release version contains application versions that have all the expected quality statuses. It is similar to an IBM UrbanCode Deploy snapshot except that, because it can contain multiple versions (snapshots), it can be considered a snapshot of snapshots.

You can restrict the application versions available to a deployment by using the version filter on the Release Detail page. When you use a filter, only application versions that match your filter condition are available during a deployment. Use filters to ensure that versions that are not ready for deployment cannot be selected inadvertently.

Finally, you can delay selecting versions until you launch the deployment. You can manually select the version, such as snapshot v1.1, anytime after the deployment is scheduled and before it starts.

Application Environment Tags

Because IBM UrbanCode Deploy deployments represent one application deploying to a single environment, to represent that process in IBM UrbanCode Release, restrict environment mappings to one application environment per release environment.

However, it is not unusual for a single IBM UrbanCode Release deployment to contain multiple applications and multiple environments. You use tags to identify deployment targets when multiple application environments are mapped to a single release environment.

Continuing with the previous example, if you map my_env and my_environment2 to the same release environment, where will snapshot v1.1 be deployed? If you do not use tags, the answer is both environments. For some use cases, this is the desired result.

To ensure that snapshot v1.1 is deployed to my_env, create a tag and add it to my_env. Then, when you create the automated deployment task, select the tag as the application target. You can select multiple tags to deploy to some but not all application environments.