Lifecycles and channels

Lifecycle

A lifecycle is an ordered list of phases a release moves through. A phase is one or more environments plus promotion options.

name: standard
phases:
  - name: dev
    environment_ids: [env_dev]
    auto_promote: true
  - name: staging
    environment_ids: [env_staging]
    auto_promote: true
    min_soak: 30m
  - name: production
    environment_ids: [env_prod_eu, env_prod_us]
    min_environments: 1          # 0 = all environments in the phase

Phase field	Meaning
environment_ids	The environments in the phase; they are deployed together
auto_promote	Promote to the next phase automatically when this one succeeds
min_soak	Minimum time the release must have been healthy here before it may be promoted
min_environments	How many of the phase’s environments must succeed before promotion is allowed (0 means all)
optional	The phase can be skipped

A release can only be deployed to environments in its lifecycle, and to a phase only after the preceding phases are complete (unless the phase is optional). That is what stops “straight to production” mistakes without anyone having to remember.

Channel

A channel maps releases to a lifecycle by version rule. Each rule has a kind (semver, glob or regex) and a pattern.

Channel	Rule	Lifecycle
stable	semver: >=1.0.0 <2.0.0	standard (dev, staging, production)
beta	glob: *-beta.*	dev only
hotfix	regex: ^\d+\.\d+\.\d+-hotfix	staging, production

Pass --channel when creating a release (slipway release create api 1.5.0-beta.1 --channel beta) or let the version rule choose.

Promotion

• Manual: slipway promote api --from staging --to production, or the Promote button.
• Automatic: auto_promote after success and min_soak.
• Protection rules still apply. A promotion into production waits for that environment’s approvals, windows and policies, exactly as a direct deployment would.

The release progress view (ReleaseService.GetReleaseProgress) shows, per release, which phases are done, in progress or blocked and why.

Release trains

Business and above. A release train groups releases of several services into one coordinated rollout through a shared lifecycle, so “the checkout release” can mean api, web and worker moving together.