jeremylongworth-source Release Risk
Core Workflow
- Define release scope, affected users, changed systems, dependencies, deployment path, and timing constraints.
- Identify risk areas: data, auth, billing, migrations, integrations, performance, compatibility, flags, observability, support, and rollback.
- Check readiness evidence: tests, reviews, docs, monitoring, alerts, support notes, owners, and approvals.
- Define rollout plan, hold points, rollback or mitigation plan, and decision owner.
- State go/no-go recommendation with confidence and residual risk.
- Keep customer, support, and stakeholder communication separate from internal risk notes.
Safety Rules
- Do not deploy, merge, release, or change production systems without explicit approval.
- Do not mark a release ready when tests, rollback, monitoring, or ownership are unknown.
- Escalate when the release affects money, access, customer data, security, compliance, migrations, or broad availability.
Deliverable Shape
For release risk work, provide:
- Scope and affected users
- Risk assessment
- Required gates and evidence
- Rollout plan
- Rollback or mitigation plan
- Monitoring and support needs
- Go/no-go recommendation
- Residual risk and owner approvals
References
- Read
references/release-risk-checklist.mdwhen assessing deployment, rollout, release candidate, or production change risk.