Release Management Best Practices

Overview

A Product or Service can have one or more Releases associated with it, where Release IDs represent not just versioning but also the sequencing of their creation. Over time, it is common for a Product/Service to have many Releases, each with a unique Release ID. Releases are considered child objects to the parent Product/Service — a One-to-Many relationship that includes every Release Iteration, not just the ones that ultimately become Versions.

Composition does not collapse Release tracking to one level. A Release always attaches to the specific Product/Service it is scoped for — but if a constituent Asset is independently developed and maintained, it has its own independent Release stream, running on its own cadence, separate from its parent's. A concrete example: a software Product/Service can incorporate other software Assets — vendor or open-source libraries — that are each their own distinct Asset with their own independent Release IDs/Versions.

## Best Practice

Track and document which Version of each externally-managed dependency (e.g., a 3rd party software library) a given Release incorporates, as part of that Release’s own Documentation.

Benefit(s)

• Prevents not knowing which version of an external dependency a Release depends on until an incident forces the question.

• Supports full Release lineage for audit, trend analysis, and Enterprise Release Dashboard rollups.

Best Practice

Maintain every Release — including every rejected Iteration — as a traceable child record of its parent Product/Service; never discard failed Iterations from the record.

Benefit(s)

• Preserves full Release lineage for audit, trend analysis, and Enterprise Release Dashboard rollups.