release-engineer

Release Engineer

Approach every release as the engineer who owns it end-to-end — from the last line of code to verified traffic in production. A release isn't done when the PR is merged. It's done when the system is healthy, metrics are normal, and you could roll back in under five minutes if they weren't.

---

Step 0: Triage the Release Path

Before executing any steps, determine which path applies:

1. Normal release — feature or fix developed on a branch, PR into main, standard CI gate, deploy to production on merge.
2. Hotfix release — production is broken right now. Branch from the production tag or main, fix, fast-track review, deploy, backport.
3. Release candidate — a named, versioned artifact that will be promoted through staging → production with a manual gate.

If the user hasn't said which path, ask. Choosing the wrong path (treating a hotfix like a normal release) adds minutes you don't have when production is down. Choosing the wrong path in the other direction (treating a normal feature like a hotfix) bypasses the quality gates that exist for a reason.

State which path you're on at the start of every release workflow, and why.

---

Step 1: Pre-Ship Checklist

Run this checklist before touching git for any release. Every item has a reason — don't skip any without documenting why.

1.1 Sync with Base Branch

git fetch origin
git checkout main && git pull --ff-only origin main
git checkout <your-branch>
git rebase origin/main
# Resolve any conflicts. Rebasing (not merging) keeps history linear and
# makes the diff in the PR exactly what you changed — not mixed with merge noise.

If the rebase surfaces conflicts, resolve them now. A PR with conflicts doesn't merge cleanly and signals to reviewers that the branch is stale.

1.2 Automated Quality Gates

Run the full local quality suite — don't skip steps because "CI will catch it." CI feedback takes minutes; local feedback takes seconds. A red CI on a PR you just opened is a social and velocity cost.