Version Control

GuardIEn uses the concept of a 'deliverable' to define the configurable items. For Gen projects, this means high level object types like action blocks, procedure steps and entity types as well as external objects that can be versioned using XOS.

Each deliverable is individually versioned in GuardIEn. This enables the tracking of the versions that have been created for a deliverable, the release of the system they are included in, and their progress through the development life-cycle. Versions are automatically created by GuardIEn when changes are uploaded to the encyclopaedia using the integrated Upload Assistant.

The concept of versioning deliverables is key to the effective automation of configuration management, but it also requires the ability to explicitly and uniquely identify individual versions. Whilst Gen allows multiple versions to be stored, it does not allow them to be explicitly identified. GuardIEn complements Gen by enabling the explicit identification of versions. The data about the versions is stored in the GuardIEn database and linked to the underlying objects in the models.

GuardIEn can be setup to record each change made to an object, when it was changed and which userid applied the change.It can store the action diagram (PAD) statements for each change and produce a comparison between any two versions. This allows statement level tracking of changes to an action diagram without requiring separate models. To view the differences, you can select any two versions and press the Compare button to view the differences.

Since GuardIEn stores the data for the minor versions in its own database, it is able to provide statement by statement, property by property tracking of changes. This is not possible if you only rely on the Gen encyclopaedia since a Gen model only contains the latest version of an object.

Release Management

An important part of effective configuration management is a clear and well understood release management policy. This helps plan when changes are to be applied to the production system. It should cater for both the medium to long-term enhancements as well as short term fixes that may be required.

GuardIEn helps projects to define and plan release implementations by providing facilities to document the releases and their content. Multiple system releases can be defined as either independent releases, or linked as a hierarchy of releases which facilitates the tracking of changes between releases.

GuardIEn allows the parallel development of system releases. This enables the team to work on more than one release at the same time. The diagram below illustrates an example model architecture for parallel development.

One of the problems with parallel development is ensuring that any changes or fixes that are applied to a release are also applied to the subsequent release. This is illustrated in the diagram above by the blue double headed arrow linking the development models for releases 1 and 2.

GuardIEn contains special facilities for tracking changes in one release and detecting whether they can be safely migrated to the next release or not. It uses a concept called 'baselining' to detect whether the object has been changed in the subsequent release and thus whether it can be migrated or whether the change has to be manually applied to the next release to avoid losing any changes made in that release.