Releasing & Rollback

Merging to main and releasing are two different acts. A merge puts code on main. A deploy runs that code on a server. And with a feature flag, the code can be live and the feature still off. Keeping these separate is what lets us ship often and turn features on calmly.

Deploying

Deploys are deliberate, not automatic. A merge does not ship itself; you trigger the deploy when the change is ready to run. It is a GitHub Actions workflow dispatch that checks out the current main and pushes it to the staging VM:

gh workflow run main.yml -f target=website --ref main

target picks what ships: website, glide, lore, or all. Watch the run to completion (gh run watch, or the Actions tab) rather than assuming it succeeded, then smoke-check the live surface for the thing you changed. A 200 is not verification; look for your actual change.

Deploying the app is separate from publishing the versioned packages, which the changesets release workflow handles on its own.

Releasing the feature

If the change went out behind a flag, the code is now running but invisible. The release is a second, smaller act: move the flag from off, to internal, to a rollout percentage, to everyone, watching as you go. See Feature Flags for the lifecycle. Comms and the release note are part of Launch.

Rollback

When something breaks, reach for the most reversible lever first. This is the payoff for shipping behind flags and in small commits.

Lever	Use when	How
Flip the flag off	A flagged feature misbehaves	Toggle it off in the flag platform. Instant, no deploy, no code change.
Revert the merge	The code itself is bad, flag or not	`git revert <sha>`, merge the revert, redeploy.

A flag flip is seconds and needs nobody. A revert is clean precisely because commits are small and green, so reverting one lifts out one change and nothing else. Decide by reversibility, and prefer the door you can walk back through. The changes worth pausing for before they ship are the one-way doors in Code Review.