Run releases as a documented sequence, not a heroic sprint.
Release operations in Gvner are meant to be repeatable: confirm readiness, review risk, generate bundles, and promote with enough evidence to explain the decision later.
Who this is for
Release managers, operations leads, and tenant admins coordinating cutovers and post-release monitoring.
When to use it
Use this before any meaningful rollout, especially when tenant impact, new integrations, or elevated deny trends are involved.
Required setup
Required setup: tenant configured in console, integrations already evaluated, evidence available for export, and any required admin approval path understood before promotion begins.
How to use
1. Run readiness checks
Use the deployment and health surfaces to confirm startup, readiness, and known issues are stable before discussing promotion.
2. Review integrations and risk
Check evaluate outcomes, deny trends, and any unresolved policy conflicts that could make the rollout unsafe.
3. Generate supporting artifacts
Build exports and reports so the release decision can be reviewed with concrete evidence instead of memory or screenshots.
4. Promote deliberately
Move forward only when the release packet is coherent and the responsible approvers agree that risk is acceptable.
5. Monitor after promotion
Keep watching health, incidents, and evidence flow so you can detect regressions early and explain the timeline later.
What success looks like
Related console surfaces
/docs/ops/deployment/ - deployment and rollout reference/admin/reports?tenant_id=<tenant> - release bundle generation