Rational Asset Manager

Using RAM to Record Deployment Histories

November 14th, 2011 by Des Drury Leave a comment

Since designing the Rational Asset Manager (RAM) schema to support Release Mangement we have been extensively using the Release and Component Assets. However, the use of the Deployment History Assets never really gained much traction. I think the reason for this was that we had not figured out how to make using these Assets simple. It was easy enough the create them, recording the deployment of a Component or Release. However, it was not really obvious how we would use them to do reporting. It was difficult to understand the state of an environment, or the history of Components deployed as part of a particular Release.

The solution we wanted to implement had to fulfill the following requirements:

1. Report on the current state of Components within environment X.
2. Report on the deployment of Components belonging to Release Y.

Within a project the deployment of Release Components occurs over a period of time. Also, a new Release will usually only have a few Components that are really new, with the rest remaining the same as in the previous Release. Therefore the deployment environments are potentially composed of Components that come from many Releases. This is demonstrated in the following two diagrams.

Diagram 1 - Version 1.0 of Release X

Diagram 2 - Version 2.0 of Release X

We use Rational Build Forge (RBF) to automate the deployment of Components. The last step of the deployment project creates a new Deployment History within RAM to describe the outcome of the deployment. This Deployment History is linked to the Component that was deployed. The process is shown in the following diagram.

The Deployment History can also be used to store files, as depicted in the above diagram. These files could be automated test reports, screen captures, stdout captures, etc.

An important point to note is that the link between the Deployment History and the Component is not a RAM relationship. Instead it is a set of attributes within the Deployment History that describe the Component that was deployed, I.e. Name and version. The reason for this “soft” link is to do with the complexities of managing relationships when new versions of an Asset are created. A description of these complexities, with regards to the use of Release Assets, is provided in my previous blog.

For each Component and environment there is a single Deployment History Asset. And each time the Component is deployed to the environment a new version of the Deployment History Asset is created. In the following example Component A, version 1.0, is deployed to System Test twice. Probably because the first attempt failed.

The next diagram shows more clearly how different versions of a Deployment History describe the deployment of different versions of a Component. Component B, version 2.0, is deployed twice as the first attempt failed.

By recording deployments of a Component in this way it becomes easy to see what the most recent version of a Component within an environment is. You just look at the most recent version of the Deployment History. And to see the entire history of deployments for a Component within an environment you just look through all the versions of the Deployment History. This behaviour allows us to fulfill the first requirement, report on the current state of Components within environment X. By looking for the most recent version of the Deployment History linked to each of the Release Components within a particular environment we are able to produce the following report.

Not only does this report tell us what the current Component versions are within an environment, it also checks that all of the Components are part of the same Release. The highest Release reported for UAT is ReleaseX, version 2.0. However, if you look closely you’ll see that ComponentA was deployed as part of ReleaseX, version 1.0. In fact ComponentA did not change in ReleaseX, version 2.0, as depicted in diagram 2 above. The report is clever enough to know this and therefore reports that all Components deployed into UAT are part of ReleaseX, version 2.0. This is only possible due to the expressive power of RAM relationships.

To fulfill the second requirement, report on the deployment of Components belonging to Release Y, we also create a Deployment History for the Release. Each time a Component related to the Release is deployed we not only create a new version of the Deployment History for the Component but we also create a new version of the Deployment History for the Release. However, as there is only one set of attributes in a Deployment History Asset, and we want to use them to link to the Release, we make use of the description field instead. The Deployment History for ReleaseX, version 1.0 looks like the following.

Finally, it may be that some Components of a Release have not been automated and are instead deployed manually. In this case a simple command is executed at the conclusion of the deployment by the deployment team. This command creates the Deployment History for the manually deployed Component and allows reporting to include these Components as well.