Understanding the Release Process.

In a nutshell the release process manages various lists relating to software components.

Definition of Terms

Environment

An environment is a list of software component names and versions which make up a particular build and/or run time environment. This can also be known as and Operating System or platform but may contain addition software components that are not deployed by default.

Release

A release is a list of software component names and versions that make up a release. These components must be consistent across the different build or run time environments.

Metapackage

A metapackage is a list of software component names that provide a specific function.

Patch

A patch is a list of software component names and versions which represent some delta to the release.

Relationships

A release is a set of software component name and versions that are consistent across different environments. The metapackage presents a view of the release. When resolved, the result is a list of software component names and versions per metapackage, per environment. The reason for this partitioning is to improve efficiency by maintaining a smaller set of lists which can be resolved into more lists rather than maintaining lists per metapackage, per environment. The patch is a delta which should be applied to the release and represents a change.

Pragmatism

In practice there will be situations that do not follow this approach. Examples include when for a few environments a software component that is in the release might be different or the release might be different for a metapackage. It should be possible to handle such exceptions, however, this abstraction may help in identifying in which list the components should be managed. If the execeptions become the norm, it might be more effective to maintain on list per metapackage, per environment and use tooling to apply bulk operations across all these lists.

The Release Process.

The list of environments should only need to be defined once. These will generally take the form of an Operation System/Platform plus some additional components and may be necessary to occasionally update them. The meta packages will generally only need to be specified once. The only exception is when a composition change is require to the metapackage. The release is the entity which requires a strict management process which in this case is driven by the patch.

Example

A patch is created which defines a specific list of software component names and versions that represent a delta to the existing release. The patch is include in the resolution process which results in an update list for the metapackage(s) per environment and this can be evaluated before being incorporated into the release. The exceptions are where the patch requires a change to the environment or metapackage. In either case a new list for the environment or node type needs to be created and evaluated before the originals are updated.

Implementation Using ETICS.

The release is defined by using a project configuration. The configuration name should include the update number and a new configuration created for each update. The sub configurations are used to select the version of the components which should be in the release. Currently this involves managing subsystem configurations which creates and extra layer of abstraction however it would be advantages if the components could be managed individually. The environment is generally specified per platform and usually refers to external components. These are set by specifying the .DEFAULT property for each platform in the project configuration. The metapackages are specified as a component in the project. The resolution to create a list of software component names and versions per platform per environment is achieved by building the metapackage.

To create a patch the project configuration should be cloned and named to identification the patch. This patch project configuration is then used to build the metapackage_ and hence the list software component names and versions per platform per environment is produced. If a change is required to the metapackage, it should be cloned, renamed and altered to reflect this change.