# Release Progression with Lifecycles

Source: https://www.jawsdeploy.net/guides/release-progression-with-lifecycles

A lifecycle is a small state machine over environments. Dev -> Staging -> Production is just one possible shape.

A lifecycle is an ordered set of phases. Each phase contains one or more environments. A release in a project pinned to a lifecycle can only be deployed to a phase once all previous phases have succeeded - unless a phase is marked optional, or a channel overrides the path.

## What a lifecycle looks like

The default lifecycle has three phases: Dev, Staging, Production. Each phase has a single environment. A release enters Dev, then becomes eligible for Staging once Dev succeeds, then becomes eligible for Production once Staging succeeds.

## Beyond the default

Lifecycles can encode more than the canonical three-stage path.

**Multiple environments in one phase**

A `Pre-prod` phase containing both `Staging` and `UAT`. The release must succeed in *both* before Production becomes eligible.

**Skippable when needed**

A `Smoke` phase that's optional. Standard releases use it. Hotfix releases skip it - recorded as skipped, not as a gap in history.

## Channels

A channel attaches a lifecycle to a project. The default channel uses the standard lifecycle. A hotfix channel can attach a shorter lifecycle that skips Dev. Releases pick which channel they're created under - same project, two paths.

> **// Approvals on phase boundaries - A phase can require manual approval before a deployment runs.**
> 
> Useful for the Staging -> Production boundary. The platform records who approved, when, and which release. The deployment doesn't start until approval is granted.