skills/magnus919_agent-skills
1
0
Fork 0
mirror of https://github.com/magnus919/agent-skills.git synced 2026-09-20 16:16:25 +03:00
Code Issues Packages Projects Releases Wiki Activity
Files
1cd5e19620feaecaf04b5bc524fd9cd415f9cdb2
magnus919_agent-skills/release-engineering/templates/release-plan.md
T
usernameandfactory-droid[bot] <138933559+factory-droid[bot]@users.noreply.github.com> 2b906565d4 fix(release-engineering): address review findings in DORA asset, cadence, link, metrics script 
- Correct the DORA 2024 thresholds table (Elite/High/Medium/Low) and the
  2025 caveat (seven archetypes, report rename; DRR added in 2024) in
  assets/dora-metrics-reference.md to match references/metrics-and-dora.md
- Fix Firefox cadence to the 2-week train and align GitLab's release day
  with the third-Thursday fact in references/release-process-models.md and
  references/release-operations-and-triage.md
- Fix the dead versioning-decision-table.md link in templates/release-plan.md
  to point at ../assets/versioning-decision-table.md
- Scope the deployment-frequency observation window to the selected
  environment, clamp negative change lead time at 0, and require a recovery
  deployment to start at or after the failed deployment finished in
  scripts/dora_metrics.py
- Make the metrics-and-dora.md worked example internally consistent
  (21 total deploys, DRR = 3/21 = 14.3%)
- Reword the version_bump.py docstring to describe the implemented
  pre-release behavior instead of unimplemented graduation
- Add tests for environment-scoped window, CLT clamp, and recovery
  candidate ordering (114 tests pass under pytest and unittest)

Co-authored-by: factory-droid[bot] <138933559+factory-droid[bot]@users.noreply.github.com>
2026-08-01 23:07:49 -04:00

131 lines
7.1 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
# Release Plan — [RELEASE NAME] v[VERSION]
> Fill in every `[PLACEHOLDER]` and delete the italic guidance notes before publishing. Keep this file in the release branch and link it from the release ticket so the audit chain ([change-governance-record.md](change-governance-record.md)) can reference it.
## Metadata
| Field | Value |
|-------|-------|
| Release name | [e.g., Aurora — a short, memorable label for the release train] |
| Version | [e.g., 2.4.0 — must match version-control tags and artifact names] |
| Target date (GA) | [YYYY-MM-DD] |
| Release manager (DRI) | [name — exactly one accountable owner] |
| Status | Draft / Frozen / In Flight / Shipped / Rolled Back |
| Changelog / commit source | [link to CHANGELOG.md or the commit range, e.g., main...release/2.4] |
## 1. Overview and Scope
### Objective
[One or two sentences: the user/business outcome this release delivers and how success is measured. Make it verifiable — "reduce checkout p95 latency by 20%", "GA the billing API v2", "remediate the CVE-2026-XXXX dependency".]
### In Scope
| ID | Item | Type (feat/fix/chore/security) | Source (PR/commit) |
|----|------|--------------------------------|--------------------|
| S-1 | [item] | feat | [#1234] |
| S-2 | [item] | fix | [abc1234] |
> Pull scope from the changelog or `git log --oneline <from>..<to>`; every item should trace to a merged PR or commit. The `release_plan_scaffold.py` script generates this table from a git range.
### Out of Scope
- [item — and why it is excluded: next release, blocked, product decision]
- [item]
## 2. Versioning and Artifacts
| Field | Value |
|-------|-------|
| Version scheme | SemVer / CalVer (see [versioning-decision-table.md](../assets/versioning-decision-table.md)) |
| Primary artifact(s) | [e.g., image registry.example.com/api:2.4.0, dist/api-2.4.0.tar.gz] |
| Artifact digest(s) | [sha256:... — of the exact artifact promoted to production] |
| SBOM / provenance | [link to SBOM (CycloneDX/SPDX) and SLSA provenance attestation] |
| Promotion policy | [build once, promote the same immutable artifact dev → staging → prod] |
## 3. Timeline and Milestones
| Milestone | Date | Owner | Exit Criteria |
|-----------|------|-------|---------------|
| Branch cut | [YYYY-MM-DD] | [name] | release/[version] branch created from main; CI green on branch |
| Code freeze | [YYYY-MM-DD] | [name] | only blockers merge; freeze announced in release channel |
| Release candidate build | [YYYY-MM-DD] | [name] | RC artifact built once, signed, digest recorded |
| Full test pass / UAT | [YYYY-MM-DD] | [name] | acceptance tests + UAT sign-off on the RC artifact |
| Staging deploy | [YYYY-MM-DD] | [name] | staging parity confirmed; readiness checklist run |
| GA / go-live | [YYYY-MM-DD] | [name] | go/no-go passed; rollout started |
| End of rollout | [YYYY-MM-DD] | [name] | 100% of target population on new version |
| Monitoring window closes | [YYYY-MM-DD + 48–72 h] | [name] | post-release monitoring done; release ticket closed |
> Freeze dates are a commitment: any change after branch cut needs the release manager's explicit sign-off and a re-run of the affected gates.
## 4. Owners and RACI
| Activity | R (Responsible) | A (Accountable) | C (Consulted) | I (Informed) |
|----------|-----------------|-----------------|---------------|--------------|
| Scope definition | [eng lead] | [PM] | [eng team] | [stakeholders] |
| Build & test | [CI owner] | [eng lead] | [QA] | [release manager] |
| Deploy | [deployer] | [release manager] | [SRE] | [eng team] |
| Rollback decision | [release manager] | [on-call lead] | [SRE, eng lead] | [all] |
| Comms | [comms owner] | [release manager] | [PM] | [customers] |
| Post-release monitoring | [SRE] | [SRE lead] | [eng lead] | [release manager] |
> Every row needs exactly one Accountable. The approver must never equal the deployer (separation of duties — see [change-governance-record.md](change-governance-record.md)).
## 5. Risks and Mitigations
| ID | Risk | Probability (H/M/L) | Impact (H/M/L) | Mitigation | Owner |
|----|------|---------------------|----------------|------------|-------|
| R-1 | [e.g., new dependency unavailable in prod registry] | M | H | [e.g., pre-push artifact to prod registry during staging] | [name] |
| R-2 | [e.g., schema migration locks the payments table] | M | H | [e.g., expand/contract migration; backfill in background; see rollback-runbook.md] | [name] |
| R-3 | [e.g., third-party API rate limit during launch] | L | M | [e.g., staged rollout + circuit breaker] | [name] |
## 6. Rollout Plan
| Strategy | [Canary / blue-green / rolling / ring / feature-flag — see deployment-strategy-matrix.md] |
|----------|--------------------------------------------------------------------------------------------|
| Staged progression | [e.g., canary 5% (4 h) → 25% (24 h) → 50% (24 h) → 100%; or ring: internal → beta → 10% → 100%] |
| Gate between stages | [SLI thresholds that must hold before the next stage, e.g., error rate < X%, p95 latency < Y ms] |
| Feature flags | [list flags toggled as part of this release and who flips them] |
| Auto-rollback trigger | [e.g., canary error rate > 2× baseline for 10 min → automatic rollback of canary] |
| Go/no-go authority | [who decides to pause or abort the rollout] |
## 7. Rollback Contingency
- Decision path, commands, and verification steps: see [rollback-runbook.md](rollback-runbook.md).
- Decision authority: [name] (on-call lead) — decision time-boxed to [X] minutes after a confirmed signal.
- Known-good artifact: [e.g., registry.example.com/api:2.3.1 with digest sha256:...]
- Special cases: [list anything unusual — irreversible migrations, client-side changes that cannot be recalled, data changes]
## 8. Communication Plan
| Audience | When | Channel | Message Owner |
|----------|------|---------|---------------|
| Internal engineering | [branch cut / RC / GA] | [#releases] | [release manager] |
| Support / on-call | [before GA] | [#support-handoff] | [comms owner] |
| Customers / status page | [GA + during rollout] | [status page, release notes] | [PM] |
| Executives | [GA] | [email / weekly] | [release manager] |
## 9. Post-Release Monitoring
| What | Where | Window | Alert Threshold |
|------|-------|--------|-----------------|
| [e.g., deployment frequency & change failure rate] | [DORA dashboard] | [48–72 h] | [n/a — trend] |
| [e.g., checkout p95 latency] | [Grafana] | [72 h] | [> 300 ms for 15 min] |
| [e.g., payment error rate] | [Sentry / Datadog] | [72 h] | [> 0.5% for 10 min] |
| [e.g., support tickets mentioning new feature] | [ticketing] | [1 week] | [n/a — triage] |
## 10. Sign-offs
| Role | Name | Date | Decision |
|------|------|------|----------|
| Engineering lead (quality) | | | Approved / Not approved |
| SRE / operations (rollback + monitoring ready) | | | Approved / Not approved |
| Product owner (scope + comms) | | | Approved / Not approved |
| Release manager (final) | | | GO / NO-GO / GO WITH CONDITIONS |
> GO WITH CONDITIONS requires named conditions, owners, and deadlines in the table below.
| Condition | Owner | Deadline | Status |
|-----------|-------|----------|--------|
| [condition] | [name] | [date] | Open / Done |
Reference in New Issue View Git Blame Copy Permalink