How To

How to use the IBM UrbanCode Release plug-in part 4: Get Release Environment step

Print

The IBM UrbanCode Release plug-in for IBM UrbanCode Deploy provides tools that integrate the two products more efficiently. Once installed, you can use the four plug-in steps in your IBM UrbanCode Deploy  process design workflows:

Step 1: Add Comment to Task
Add comments in IBM UrbanCode Deploy to  automated tasks started by IBM UrbanCode Release scheduled deployments.

Step 2: Update Application
Update the IBM UrbanCode Release inventory for applications deployed by IBM UrbanCode Deploy.

Step 3: Add Snapshot Status

  • Add a version statuses to snapshots during deployment processes.
  • Add comments and attachments to statuses.

Step 4: Get Release for Environment
Get the name of a release that is active for a specific environment, to facilitate auto progression for releases.

This article covers the Get Release for Environment step.  The other steps are described in the following articles:

Part 1:  Add Comment to Task step

Part 2: Update Application step

Part 3: Add Snapshot Status

Plug-in prerequisites:
Download the IBM UrbanCode Release plug-in from the IBM UrbanCode Deploy Plugin page, and then import the ucr_plugin-version.zip file (Home > Settings > Plugins  > Load Plugin).

Optional:
Define  authentication properties required by the plug-in as system properties. System properties are accessible from anywhere, and, when changed, are automatically updated across all process steps that use them.

Step : Get Release for Environment

The Get Release for Environment step facilitates auto progression for IBM UrbanCode Release releases. With IBM UrbanCode Release, you can create a recurring rule for a release that automatically promotes and deploys an application version from one phase of the lifecycle to the next.  As soon as an application acquires the required statuses and degree of readiness, it is automatically deployed to the next phase.

When you deploy an application version to a DEV environment, say, a snapshot is created of all component versions deployed in the environment. This snapshot automatically appears in the IBM UrbanCode Release inventory. As soon as the snapshot acquires the required statuses, the recurring rule creates a scheduled deployment of that version for the next phase. By using recurring rules, application versions can be automatically deployed to every phase in the lifecycle through to production.

The following diagram illustrates the process:


release-plugin-release-for-environment-autoprogression

Problem: Multiple releases
Applications often belong to more than one release. How does IBM UrbanCode Release know the target release for an application version?

Solution
Recurring rules can use patterns (simple naming patterns or regular expressions) to select versions automatically. By naming snapshots after releases, for example, a recurring rule can determine the intended release for a snapshot. For example, the following naming pattern can be used by a recurring rule:

Snapshot_[ReleaseName]

Using this simple pattern, a recurring rule can select only those versions that follow the pattern.

Problem: Shared environments
Environments can be shared across releases. How can IBM UrbanCode Deploy determine the active release for a given environment during a deployment process?

Solution
You can reserve an environment by using the IBM UrbanCode Release environment reservation feature. A release environment is reserved for a specific period of time. If a reservation already exists for an environment, a warning is displayed.  Once an environment is reserved, the Get Release for Environment step can identify the release that has a reservation for the current time. After the release is identified and its name retrieved, the value can be stored in an output property and passed to the next step in the process.

Example

This example demonstrates how to use the Get Release for Environment step in a process that creates a snapshot that can be used by a recurring rule for auto progression.  It uses a naming pattern to name a snapshot, and it assumes that the IBM UrbanCode Release reservation feature has been used.

Get Release for Environment step fields:

URL is the location of IBM UrbanCode Release server.
Output Property Name contains the name of the output property that is used to store the name of the active release.  In this example, the name is used with the naming pattern discussed above: Snapshot_for_[releaseName].
Environment Id contains the environment  ID. The default value ${p:environment.id} returns the current environment ID. The step assumes that the environment is reserved, and the reserving release is the target.

The following figure shows the settings for the Get Release for Environment step. In this instance, the Output Property Name property is named releaseName.


release-plugin-release-for-environment-step

The releaseName output property is passed to the next step in the workflow as ${p:GetReleaseForEnvironment/releaseName}, as shown in the following figure.  The Create For Environment step creates a snapshot using the naming pattern expected by the recurring rule:


release-plugin-release-for-environment-step2

When this sample process run, it captures the name of the release, as shown in the following figure:


release-plugin-release-for-environment-trace

The following figure shows the snapshot in the IBM UrbanCode inventory after running an integration:


release-plugin-release-for-environment-result2
The recurring rule configuration in IBM UrbanCode Release is shown in the following figure:


release-plugin-release-for-environment-recurring

Using dates in naming patterns

In addition to the simple naming pattern used above, other patterns can be used to generate snapshot names. For example, you can generate a date that can be used in snapshot names:

1) Create a shell step that displays the system date.
2) Use a post-processing script (described in Part 1 of this series) to read the output date and make it available to the following step by storing it in an output property. This figure shows a shell step that captures the system date:


release-plugin-tips-generate-date
 The following figure shows a post-processing script that stores the date in an output property named GeneratedDate:


release-plugin-tips-generate-date-post-script

The date can be accessed by the  following step this way:
Snapshot_${p:environment.name}_${p:GenerateDate/GeneratedDate}

The generated name will be similar to Snapshot_DEV_ 20142702.