Problem
Promotion is strictly linear (dev → test → uat → prod). No first-class modeling for canary or blue-green deploys — adopters who need these hand-roll them inside a single deploy callback, hiding the strategy from framework state.
Proposed
Optional strategy: field on deploys:
deploys:
- name: app
strategy: canary
canary:
percent: 10
bake_time: 10m
promote_callback: .github/workflows/canary-promote.yaml
rollback_callback: .github/workflows/canary-rollback.yaml
- name: api
strategy: blue_green
blue_green:
cutover_callback: .github/workflows/cutover.yamlGenerator emits the two-stage job pattern (canary deploy → bake → promote-or-rollback). Strategy execution stays in callback code; framework owns sequencing, state, and observability.
Out of scope
GH Deployments API integration for canary status surfacing — see the extension-points architecture issue.
Schema-reserve note
The field shape (strategy:, canary:, blue_green:) must be designed into the v1 schema so it can be reserved during any freeze. Implementation can land in a later minor without a breaking change. Adopters who need canary later don't have to fork the orchestration model.
Problem
Promotion is strictly linear (dev → test → uat → prod). No first-class modeling for canary or blue-green deploys — adopters who need these hand-roll them inside a single deploy callback, hiding the strategy from framework state.
Proposed
Optional
strategy:field on deploys:Generator emits the two-stage job pattern (canary deploy → bake → promote-or-rollback). Strategy execution stays in callback code; framework owns sequencing, state, and observability.
Out of scope
GH Deployments API integration for canary status surfacing — see the extension-points architecture issue.
Schema-reserve note
The field shape (
strategy:,canary:,blue_green:) must be designed into the v1 schema so it can be reserved during any freeze. Implementation can land in a later minor without a breaking change. Adopters who need canary later don't have to fork the orchestration model.