Build · Create · Engineering
Deploy runbook with rollback
An ordered, role-assigned deploy runbook with preflight checks, deploy steps, verification, and a rollback path that every failure step routes to.
You receive: A structured runbook (JSON) that passes the section, step-shape, role, ordering, and rollback-routing checks.
Part of Keep App Running
Example
A sample of what this play produces. Your result is generated for your inputs.
Service
stud.com
Environment
prod
Preflight Checks
| Order | Role | Action | Expected Result |
|---|---|---|---|
| 1 | release-engineer | Run the full local gate from platform/ (npm run gate:local): judge tiers, voice lint, vitest, eslint, token lints, typecheck, schema drift, next build. | Every gate step green; the run matches the CI gate 1:1, so the PR's required checks will pass. |
| 2 | release-engineer | If the change touches platform/src/db/schema.ts, confirm a generated drizzle migration file is committed alongside it (check platform/drizzle/ in the diff). | Schema edit and migration ship together; the gate's schema-drift guard reports no drift. |
| 3 | release-engineer | Confirm the PR to main is green on the required gate checks (judge and platform) and is not in a conflicted state. | Both required checks show success and the PR is mergeable. |
| 4 | on-call | Note the current production deployment SHA from the GitHub deployments API as the rollback baseline. | The last state:success production SHA is recorded in the release notes. |
Deploy Steps
| Order | Role | Action | Expected Result | On Failure |
|---|---|---|---|---|
| 1 | release-engineer | Squash-merge the PR into main; the push to main triggers the Vercel production build for stud.com. | A new production deployment starts for the merge commit SHA. | 1 |
| 2 | release-engineer | Watch the Vercel build: the deploy-migrate step (drizzle-kit migrate, then catalog seed and sync) runs before the app build serves. | The build log shows migrations applied and the catalog sync completed with no errors. | 1 |
| 3 | on-call | Wait for the deployment to reach the ready state and take production traffic. | The GitHub deployments API shows state success for the new SHA. | 1 |
Verification Steps
| Order | Role | Action | Expected Result | On Failure |
|---|---|---|---|---|
| 1 | on-call | curl https://stud.com/ and confirm the landing page returns HTTP 200 with the STUD landing content. | HTTP 200 within normal latency; no 500 or blank response. | 1 |
| 2 | on-call | Open one play detail page and confirm it renders with its intake and sample deliverable. | The play page loads with intake fields and the Example artifact visible. | 1 |
| 3 | release-engineer | Confirm any play added in this release resolves live (the deploy-time catalog sync seeds it automatically). | The new play's URL returns its detail page, not a 404. | 2 |
| 4 | on-call | Scan the Vercel runtime logs for the first 15 minutes after cutover for new 5xx errors or migration warnings. | No new 5xx pattern versus the pre-deploy baseline. | continue |
Rollback Steps
| Order | Role | Action | Expected Result |
|---|---|---|---|
| 1 | release-engineer | Revert the merge commit on main (git revert -m 1 <merge SHA>) and push; the revert triggers a fresh production build of the prior code. | A new production deployment of the reverted tree reaches state success and stud.com serves the previous behavior. |
| 2 | on-call | If only the new catalog content is defective, keep the code live and re-run the catalog sync from the corrected seed on the next deploy; verify the affected play pages recover. | Affected pages render correctly; no further 5xx from the defective content. |
| 3 | on-call | Record the failure, the rollback taken, and the baseline SHA in the release notes, and file a follow-up issue linked to the release PR. | The incident trail exists: what failed, what was rolled back, and the tracked follow-up. |
Opens soon
STUD opens runs for everyone soon, on every play at once.
Scope of the check
What's verified: STUD verifies the submitted runbook (JSON) is structurally complete: it has preflight, deploy, verification, and rollback sections meeting your minimums, every step is ordered and carries a role from your allowed set with an action and expected result, orders are unique and ascending per section, and every deploy or verify step routes on failure either to 'continue' or to a real rollback step. STUD does NOT run the commands or verify they work; it checks the runbook's completeness and internal consistency.
Get early access to STUD the day it goes live.