Roadmap relationship
Outcome
Give every deployable type one immutable release model with provenance, promotion between environments, health-gated activation, provider-aware zero-downtime strategies, and reliable rollback to a known artifact and configuration.
Current gap
Compute sites use atomic release directories, serverless uses S3 release snapshots, container work has separate task/image behavior, and advanced canary/blue-green abstractions are not integrated into the primary workflow. History, actor/trigger, config provenance, promotion, and rollback guarantees differ by mode.
User experience
- Deployment/release detail shows source SHA, artifact digest, config revision/diff, build provenance, actor/trigger, steps, health checks, domains, duration, and resulting resource versions.
- Promote an already-built immutable artifact from one environment to another after reviewing environment-specific config and approvals.
- Choose only supported strategies—rolling, atomic/symlink, blue-green, or canary—with an explanation of capacity/cost and rollback behavior.
- Rollback selects a release, previews config/data caveats, monitors activation health, and preserves the failed release for investigation.
Scope
- Define a common release record and artifact identity for static, compute, serverless zip/image, ECS/container, and Compose deploys.
- Store immutable manifests, resolved non-secret configuration hashes, artifact digests, and provenance/attestations.
- Implement promotion without rebuilding, environment approvals, and optional manual production gates.
- Add health-gated activation, drain/grace periods, automatic rollback policy, and strategy capability detection.
- Unify history, compare, redeploy, rollback, retention, and release pinning across CLI/API/dashboard.
Technical direction
- Separate build from release activation and make both durable jobs.
- Use content-addressed artifacts and verify digests before activation.
- Provider drivers implement strategy primitives and return structured traffic/health transitions.
- Keep database migrations/hooks explicit with forward/backward compatibility metadata; never imply data rollback.
Safety and operability
- Production promotion and rollback show exact target, artifact, config diff, health gates, and any irreversible hooks.
- Automatic rollback has bounded attempts and stops on ambiguous state.
- Artifacts and provenance are access-controlled and secrets remain write-only references.
- Retention never deletes active, pinned, or rollback-required artifacts.
Acceptance criteria
- The same tested artifact can be promoted from staging to production without rebuild.
- A failed health gate restores the prior active release for supported strategies and records every transition.
- History/compare/rollback behavior is consistent across at least static, compute, serverless, and container paths.
- Unsupported zero-downtime strategies are unavailable with an actionable explanation.
Verification
- Release state-machine, artifact digest, promotion, retention, health gate, drain, and rollback failure tests.
- Driver contract tests for strategy capability and transition reporting.
- End-to-end healthy promotion and failed canary/rolling activation with rollback.
Non-goals
- Rolling back database state automatically.
- Claiming zero downtime for workloads without health/readiness support.
- Rebuilding artifacts during promotion.