RELEASE QUALITY
Coding agent release checklist: from local build to verified production
Freeze the candidate
Record the exact artifact hash and the source state that produced it. Stop editing while that candidate is being verified.
Keep the previous known-good version as the rollback target. A rollback is useful only when its identity and restoration path are known before promotion.
Test the affected family
A shared component change expands the regression surface. Test every route, locale, device class and state that consumes it, not just the page where the defect was first noticed.
For web products, inspect desktop and a real narrow viewport, keyboard access, visible focus, overflow, loading and error recovery.
Verify production separately
After promotion, request the public origin rather than a preview. Confirm that the active version matches the candidate and exercise the important customer journey again.
Server-side truth should verify payments, entitlements, durable AI results and other business outcomes. Browser redirects alone are not proof.
Leave a usable handoff
Record what changed, what passed, what remains intentionally blocked and the direct link to the result. Include the rollback identity and any time-bound monitoring needed after release.
COMMON QUESTIONS
What builders ask next
Is a successful deployment the same as a successful release?
No. Deployment proves that an artifact was accepted by the platform. Release proof requires the exact public version and the changed customer journey to work.
Do I need to test every page?
Test every page or flow in the affected family. A local text-only change may need a narrow check; a shared layout, authentication or billing change needs broad regression.
What belongs in a rollback plan?
The previous known-good version, the exact command or control path, the conditions that trigger rollback and the checks that prove restoration.