Review and release

Merging deploys to production. Feature flags decide when customers can use what we built, and the work isn't done until it's working for them.

Review and merge

Every change is reviewed before it merges, no matter who wrote it.

• Product checks the behavior does what we intended.
• Another engineer reviews the code, including edge cases and gaps in the specification or tests.
• Design often reviews UI standards and consistency.

Before opening a pull request, engineers usually run a local AI review with a different agent from the one that helped write the code. AI review adds to human review; it never replaces it.

Once the required reviews are approved, the author merges into main, and the merge deploys to production automatically.

Deploying is not releasing

Deploying puts code in production. Releasing makes it available to customers. We usually keep unreleased work behind a feature flag, so the two can happen at different times.

# Illustrative: product decides when customers see it.
if feature_enabled?(:new_schedule_view, for: current_user)
  render "schedules/new_view"
end

Product and engineering agree on timing, and the product manager usually gives the go-ahead to enable a feature.

Check what you release

The engineer who releases a change checks it in production. The project lead stays accountable for the overall release. A release plan, when we write one, covers rollout, flags, production checks, and any monitoring or alerts needed.

Any engineer can pause, disable or roll back a release when something looks wrong. The change author or project lead then coordinates the follow-through.

Follow through

Releasing the last MVP milestone doesn't finish the project. The post-live milestone removes old flags, cleans up data and technical debt, and brings documentation up to date. Product prioritizes the follow-up; engineering identifies and carries out the cleanup. Smaller remaining items move to the ongoing 1-Offs project.