Problem
Application, MongoDB, API, worker, and Soroban changes can be deployed in incompatible combinations. A successful build does not prove a release is safe for live financial workflows.
Scope
- Define a release manifest covering app, workers, database schema, API version, contract hash, feature flags, and configuration fingerprint.
- Enforce expand-migrate-contract database changes with compatibility windows.
- Add pre-deploy checks for backups, migration dry-run, contract/network identity, and pending financial jobs.
- Route a bounded canary cohort through auth, funding, investment, repayment, payout, and reconciliation probes.
- Compare financial invariants and error/latency budgets before promotion.
- Automate rollback only when backward-compatible; otherwise execute a documented forward-fix/read-only mode.
- Prevent two deployments from running conflicting migrations.
Acceptance criteria
- Mixed-version compatibility is tested and declared in the manifest.
- Destructive schema contraction cannot precede the compatibility window.
- Canary failure stops promotion automatically.
- Rollback never replays or loses financial mutations.
- Release evidence links source commit, artifacts, migrations, approvals, and health results.
Required tests
Old app/new schema, new app/old schema, worker skew, migration interruption, canary failure, rollback after writes, lock contention, and contract/config mismatch.
Non-goals
Do not mandate a hosting vendor; implement portable release gates.
Problem
Application, MongoDB, API, worker, and Soroban changes can be deployed in incompatible combinations. A successful build does not prove a release is safe for live financial workflows.
Scope
Acceptance criteria
Required tests
Old app/new schema, new app/old schema, worker skew, migration interruption, canary failure, rollback after writes, lock contention, and contract/config mismatch.
Non-goals
Do not mandate a hosting vendor; implement portable release gates.