How the Systems Development Lifecycle (SDLC) Relates to Releases, Release Iterations, and Deployments

This chapter defines and distinguishes Releases, Release Iterations, and Deployments and explains how Releases traverse approved SDLC Paths, use IT Operating Environments, accumulate evidence, update authoritative records, stabilize in Production, and close within Operations & Maintenance.

Canonical Definitions

How the Concepts Relate

The Release defines the governed package of change. Release Iterations progressively create and validate that change. Deployments move or activate some or all of the change in target Environments.

One Release may contain many iterations and many Deployments. A Deployment may occur in RES, DEV, ENG, SIT, UAT, TRN/EDU, PSTG, or PROD and does not automatically make content available to end users.

Release Paths, Risk, and Evidence

A Release should identify all affected Assets, Products, Services, Systems, Applications, Solutions, configurations, data, integrations, suppliers, and operating processes. It should be linked to an approved Path and Utilization Profile.

Rigor should reflect consequence of failure, criticality, data sensitivity, architecture breadth, dependencies, reversibility, outage risk, supplier coordination, regulatory implications, and recovery difficulty—not only code volume or schedule duration. Readiness gates rely on traceable requirements, design, test, security, supplier, migration, operational, training, rollback, and risk evidence.

Production, Stabilization, and Release Closure

Production Deployment is followed by verification and stabilization, which may include smoke testing, data reconciliation, interface validation, monitoring confirmation, access verification, early-life support, incident observation, and rollback decisions.

Release Post-Mortem and Closing occurs within OPS. It closes the bounded Release or Release Iteration, captures outcomes and lessons, and transfers unresolved items into accountable operational, risk, supplier, technical-debt, or future-Release records. It does not close the underlying Product, Service, System, Application, Asset, or Solution lifecycle.

Example

A customer-portal Release contains four Sprints and two Release Iterations. The first iteration delivers account registration and is deployed to SIT and UAT. The second adds claims status and is deployed through SIT, UAT, and PSTG before the combined Release is authorized for PROD. Each deployment moves a specific configuration into an environment; it does not close the Release. The Release remains open through production stabilization, operational acceptance, documentation and inventory updates, post-mortem activities, and transfer of unresolved work into governed future Releases.

Connections to Related IF4IT Practices and Inventories

Apply IT Operating Environments Best Practices to govern environment purpose, progression, segregation, readiness, promotion, and evidence, and use the Software Technologies Inventory and Attributes to identify the deployed technology baseline.

Connect this practice to Release Management guidance, IT Operating Environments Best Practices, and Agile, Waterfall, or Hybrid: An IF4IT Framework for Choosing Delivery Methodology, which together govern Release scope, environment progression, deployment evidence, cutover, rollback, and closure.