Last year I was presented with an opportunity to work on the schema design of Rational Asset Manager (RAM) within a large organization. RAM is an Asset repository. With an Asset being a collection of artefacts and meta-data that collectively form a single logical unit. So if we take an EAR as an example then the Asset that represents this EAR could be composed of the following items:
- The EAR file
- A deployment guide for the EAR
- A deployment script for the EAR
- Informational fields describing the version, owner and source baseline of the EAR
- Relationships to other Assets (more on this later)
The types of Asset that can be maintained by RAM is limited only by your imagination. However, for our purposes we wanted to represent the artefacts that are created and deployed as part of the SDLC. And it was with this in mind that we set to work. Whatever shape the schema took it had to meet the following requirements:
- Store and describe a deployable unit, including its related artefacts
- Describe the release that the deployable unit belongs to
- Describe the deployment of the deployable unit
- Control access to the Assets
- Simple to maintain
- Easy to search
The initial design was quite large and cumbersome. However, it was really just a starting point. Over the next few weeks we managed to pair it down until it was lean and yet still able to represent even the most complex of release scenarios we could envisage. The final design had only three Asset types, as below:
A Release Asset is used to describe a release. It has the release note attached to it. It can also maintain other artefacts that are related to the release. It has relationships to the Components of the release (see below). It can also have relationships to other Release Assets. This allows release hierarchies of systems and sub-systems to be modelled.
A Component Asset is a generic container for a collection of artefacts that logically fit together. For instance a Component could contain deployables, deployment scripts, tests, etc. A Component has a relationship to one or more Releases. It can also have relationships to other Component Assets.
A Deployment History Asset is used to describe the deployment of either a Release or a Component. It does not have direct relationships to either Release or Component Assets. Instead it has attributes that describe the relationship. It also has attributes for deployment time, date, environment and status.
The combination of these three Asset types, and their relationships, allows us to construct quite complex release hierachies, as depicted in the following diagram.
In fact RAM is just one of the tools that we use within the Build Pipeline . And of course there are many other aspects to the RAM design. Perhaps that is something for another article.Tags: RAM, Rational
Categorised in: Uncategorized
This post was written by Des Drury