Release flow
Constellation cuts dated releases from develop into main. This page summarises the flow and leaves steps out: the authoritative checklist is the release skill, and undoing a release or hotfix follows the release rollback runbook.
Cutting a release
git fetch origin
git checkout -b release/YYYY-MM-DD origin/develop
# Review first: the forward-looking-claim advisory is only actionable before
# the fragments it names are consumed (INF-540).
npx tsx scripts/render-changelog.ts --dry-run
# Pass NO date. The script derives today's label with a collision check
# (second release of a day -> YYYY-MM-DDb), and an explicit date BYPASSES that
# check — so a bare date here would render a different, duplicate-heading
# version than the dry run above just previewed.
npx tsx scripts/render-changelog.ts --title "Headline summary"
git add CHANGELOG.md .changeset/
git commit -m "release: <derived version> - Headline summary"
Rehearsing the rollback, then applying migrations
Before a release applies any migration, the release runner starts the once-per-release staging rehearsal of the rollback runbook. Its first step checks schema parity between staging and production, its second is the staging apply, and the production apply comes only after the rehearsal. If the build production still serves fails on the new schema in staging, stop before the production apply: production would break the same way. The runner records the outcome, pass or fail, in rehearsed-runbooks.yml through a pull request to develop.
Migration gate
The Verify Release Migrations (main) check blocks release PRs if either staging or production is missing a migration that exists on the branch. It uses read-only credentials that only the Release Migrations environment holds, restricted to the default branch. Apply outstanding migrations to both before opening the release PR.
The gate is read-only — it never applies migrations. It refuses to let the merge through until the schema is caught up.
The gate holds database credentials, so it runs the checker from main (the PR's base commit) and reads the release's migration files as data; it never runs the release branch's own code (INF-219). Two things follow. A change to the checker takes effect one release after it ships, and the job warns when a release carries one. And a migrations directory that main's checker does not register fails the gate, so register a new module's directory on main before its first migration ships.
Opening the release PR
Once both databases hold the release's migrations, push the branch and open the PR:
git push -u origin release/YYYY-MM-DD
gh pr create --base main --title "Release YYYY-MM-DD: …"
Merge strategy: release PRs use merge commit, not squash, to preserve history and avoid spurious conflicts on subsequent releases.
Before the merge: snapshot the rollback targets
Merging to main is the production deploy. Just before a release or a hotfix merges, after its pre-deploy prerequisites, the runner records each Vercel zone's serving deployment and commit on the PR, as Before a merge to main describes. A rollback after the merge takes its targets from that snapshot.
After merging to main
Back-merge main into develop through a pull request, never a direct push: it is a normal develop-bound PR, so it goes through review, the gates and an approval before it merges (step 10 of the release skill). Its head is the release merge commit:
git fetch origin
git checkout -b chore/back-merge-YYYY-MM-DD origin/main
git push -u origin chore/back-merge-YYYY-MM-DD
gh pr create --base develop
Hotfixes
For urgent production issues:
git fetch origin
git checkout -b hotfix/description origin/main
# fix, then a PR to main; once it is ready, work the pre-deploy prerequisites,
# snapshot the rollback targets, and only then merge it with a merge commit
# then back-merge main into develop through a pull request
A hotfix has no staging rehearsal. Its migrations reach both databases before its PR, where the migration gate runs too, and its merge deploys production, so it owes the same pre-deploy prerequisites as a release and then takes the same pre-merge snapshot (release skill, Hotfixes). While a rollback recovery is open, from its first fence until its close-out, the only merge that may land is the correction itself: a hotfix branched from main that carries nothing else, which the recovery owner confirms by reviewing its full diff before the go-ahead. Until close-out, no other release or hotfix applies a migration to production either.
Rolling back
Rolling back a release or hotfix, code per Vercel zone and data through forward fixes or, as the last resort, a restore, follows the release rollback runbook. A named human decides and executes every production step; agents prepare the evidence and the decision brief. What an agent may do in each environment is in autonomy tiers and rollback.