Release engineering is the discipline of taking code from main and getting it to production safely. The "code is on main" to "users can use it" gap involves real engineering: artifacts, signing, deployment strategies, rollback, validation.
This page covers the practices that distinguish good release engineering.
The output of CI: a deployable thing.
The artifact is what gets deployed. Same artifact through dev → staging → prod.
Artifacts tagged with:
Common: v1.2.3-build.456-abc1234
Artifacts in a registry: Docker Hub, ECR, Artifactory, GitHub Packages. Versioned; immutable; auditable.
For supply-chain security:
Cosign, Sigstore, or vendor-specific. The artifact has a signature proving it came from your CI.
Records of how the artifact was built: from what source; with what dependencies; on what infrastructure. SLSA (Supply-chain Levels for Software Artifacts) provides a framework.
For sensitive software, provenance is required. For others, it's emerging best practice.
Replace instances one at a time. Standard Kubernetes default.
Pros: simple; minimal extra resources. Cons: brief co-existence of versions; rollback is another rolling deploy.
Two identical environments. Switch traffic from blue (current) to green (new).
Pros: instant cutover; instant rollback. Cons: 2x resources during deploy; two environments to maintain.
Deploy to small subset; verify; expand.
Pros: limits blast radius; auto-rollback possible. Cons: more complex orchestration.
Deploy code disabled; toggle via flag.
Pros: total control over release timing; instant rollback via flag. Cons: requires flag infrastructure; code includes both paths.
For most modern deploys, canary + feature flags is the gold standard.
When deploys go wrong, rollback fast.
The same automation that deploys should rollback. Click button; previous version restored.
Don't require a forward fix during an incident. Rollback first; debug later.
Schema migrations need backwards compatibility. New code should work with old schema; old code should work with new schema (during transition).
The expand-and-contract pattern: add new schema columns (expand), deploy code that uses both, remove old usage (contract). Allows rollback at every step.
For minor issues: forward fix. For major issues: rollback first. The decision criterion: time to safety.
After deploy, run automated checks: critical endpoints respond; key dependencies reachable. If they fail, auto-rollback.
Compare canary metrics to baseline. If error rate or latency is worse on canary, auto-rollback.
Don't deploy schema changes with code changes. Deploy migrations first; verify; deploy code that uses them. Each step is reversible.
Same artifact through dev → staging → prod. No rebuilds between environments.
For high-risk changes, deploy during business hours when on-call is fully staffed. Don't deploy Friday afternoon.
For mature CD, this matters less; for systems with manual response, it matters a lot.
Continuous deployment from main. Engineers see their changes immediately.
Production-like environment for final verification. Should mirror production closely.
The actual user-facing environment. Deploy from artifacts that passed staging.
Every production release has notes: what changed, who approved, links to PRs/tickets. Useful when investigating issues.
For regulated environments: change requests, approval workflows, change windows. Heavy but required for compliance.
For unregulated: lighter weight; auto-deploy from main with audit trail.
DORA metrics: deploy frequency, lead time, change failure rate, MTTR. Track them; improve them.
Who's on call during this deploy? They should know what's deploying and have rollback access.