04 · Ship

Deployment

shippedprinciple → decision → workflow → artifact

Principle

Deployment is the moment code becomes a promise to strangers. AI and modern platforms make pushing easy; the scarce skill is knowing what environment you are in, what changed, and how to undo it.

Shipping is not a one-time launch — it is a rhythm: preview → verify → production → watch → rollback or iterate.

The decision

DEC_014

  PR → CI (build, test, lint)
│
▼
Preview deploy (auto)
│
▼
Human approves ──► Production deploy
│
▼
Watch (errors, core path) ──► rollback or fix forward
The path from merge to users — each step has an owner.

Environments that matter

EnvironmentPurposeWho touches it
LocalFast iterationYou + agents
PreviewPR truth — real URL, fake or staging dataCI auto
StagingOptional — prod-like integrationsYou, before big releases
ProductionPaying users, real dataHuman gate

For early products, preview + production is often enough. Add staging when integrations are scary (payments, webhooks, email).

What to document once

Workflow

  1. CI required on main — no direct pushes that skip checks (Chapter 12).
  2. Preview URL on PR — click core workflow before merge.
  3. Merge → production deploy (manual promote or auto if checks + policy allow).
  4. Smoke prod — sign in, pay test mode, critical path — five minutes.
  5. Watch — error rate, logs, support channel — first hour matters.
  6. Post-deploy note — what shipped, what to watch, link to PR.

AI and deployment

Tooling

Vercel, Netlify, Fly, Railway, Render — pick boring for your stack. GitHub Actions for CI. Feature flags (LaunchDarkly, env toggles) when rollback must be instant without revert.

Common mistakes

Artifacts

Further reading