Release process

Spark ships in a fixed order so that nothing goes live before the pieces it depends on.

Order

1. Contracts (spark-contracts): new shared types first. Services compile against them.
2. Shared libraries (such as spark-storage), when they changed.
3. Data-producing services: services other services read from, such as spark_meta and spark_tiktok_snapchat (their read-only snapshot routes).
4. Backend: new proxy routes, permissions and their migration. The browser's only door must exist before the service behind it.
5. The new or changed internal service, such as spark_launch.
6. Frontend last, because its pages call the backend.

Rules

• Package from a merged, clean commit, never from a working tree with local changes. Record the exact commit in the release notes.
• Every step has a check (health, a read-only call, a smoke test) and a rollback. Stop at the first failed check and roll that step back.
• Changes to contracts and data are additive, so the previous version of a service keeps working while the next one rolls out.
• Database permission changes are done by the database owner only.
• Configuration values are set on the target only, compared by fingerprint, and never copied into notes, tickets or chat.
• Only one instance of a service that runs scheduled jobs (nightly checks, digests, retention) may run at a time.
• Features that are built but not yet released are marked Rolling out in this documentation.