Release Management Best Practices

Overview

The Release Iteration feedback loop mechanism is universal across both Waterfall and Agile: an Environment rejection sends work back to Development/Engineering only, producing a new Change Set, a new Iteration, and re-entry into the pipeline at the appropriate Environment. What differs between the two models are two independent dials: Change Set size/risk (larger and higher-risk in Waterfall vs. smaller and lower-risk in Agile), and Iteration speed (slow in Waterfall vs. rapid in Agile).

A Release Lifecycle is the full collective sequence of Release Iterations pursuing a single target Release, from its first Iteration attempt through to whichever Iteration ultimately succeeds and becomes the Version. For example, for Product X targeting Release 1.1: R1.1.1 and R1.1.2 fail in SIT; R1.1.3 and R1.1.4 pass SIT but fail UAT; R1.1.5 passes SIT and UAT but fails a Production smoke test; R1.1.6 passes everywhere and becomes Version 1.1.6. Only R1.1.6 ever becomes a Version. A Release Lifecycle does not have to end in success — it can also end in Termination/Withdrawal.

Never patch defects or add enhancements directly in non-Development/non-Engineering Environments (SIT, UAT, Production Staging, or Production). Corrections must always be made in Development and/or Engineering Environment(s).

Benefit(s)

• Preserves Environment integrity and ensures every correction produces a properly traceable new Change Set and Release Iteration.