release-coordinator

1. Release Planning: Coordinate releases across multiple components
2. Feature Flag Management: Strategy and implementation for feature toggles
3. Versioning: Semantic versioning and changelog generation
4. Deployment Strategies: Canary, blue-green, progressive rollouts
5. Rollback Planning: Procedures for safe rollbacks
6. Release Notes: Generate comprehensive release documentation
7. Approval Workflows: Coordinate stakeholder approvals
8. Post-Release Verification: Ensure successful deployment

Type 1: Hotfix Release

Definition: Emergency fix for critical production issue

Process:

```markdown

1. Create hotfix branch from main
2. Implement fix (bug-hunter)
3. Test on staging
4. Deploy to production (expedited approval)
5. Monitor for 1 hour
6. Merge to main

```

Timeline: < 4 hours

Approval: Technical Lead only

---

Type 2: Patch Release

Definition: Minor bug fixes and improvements

Process:

```markdown

1. Collect bug fixes from sprint
2. Create release branch
3. Run full test suite
4. Deploy to staging
5. Deploy to production (standard approval)
6. Generate changelog

```

Timeline: 1-2 days

Approval: Technical Lead + QA

---

Type 3: Minor Release

Definition: New features, backward-compatible

Process:

```markdown

1. Finalize features from sprint
2. Create release branch
3. Run full test suite + E2E
4. Deploy to staging
5. Stakeholder acceptance testing
6. Progressive rollout to production (10% → 50% → 100%)
7. Generate release notes

```

Timeline: 1 week

Approval: Product Manager + Technical Lead + QA

---

Type 4: Major Release

Definition: Breaking changes, major new features

Process:

```markdown

1. Finalize major features
2. Create release branch
3. Run full test suite + E2E + performance tests
4. Deploy to staging
5. Extended stakeholder testing (1 week)
6. Communication to users (breaking changes)
7. Phased rollout to production (1% → 10% → 50% → 100%)
8. Comprehensive release notes
9. Update documentation

```

Timeline: 2-4 weeks

Approval: Product Manager + Technical Lead + QA + Security + Executive Sponsor

---

Feature Flag Types

#### 1. Release Flags (Temporary)

Purpose: Hide incomplete features during development

Lifecycle:

```

Development → Staging (ON) → Production (OFF) → Enable Gradually → Remove Flag

```

Example:

```typescript

if (featureFlags.newCheckoutFlow) {

return ;

} else {

return ;

}

```

Cleanup: Remove flag after 100% rollout (< 2 weeks)

---

#### 2. Operational Flags (Long-lived)

Purpose: Control system behavior in production

Lifecycle:

```

Permanent (configurable via admin UI or environment variables)

```

Example:

```typescript

const maxRetries = config.get('MAX_API_RETRIES', 3);

```

Cleanup: Keep indefinitely

---

#### 3. Permission Flags (User-specific)

Purpose: Enable features for specific users/roles

Lifecycle:

```

User-based or role-based, permanent

```

Example:

```typescript

if (user.hasPermission('ADMIN_PANEL')) {

return ;

}

```

Cleanup: Keep indefinitely

---

#### 4. Experiment Flags (A/B Testing)

Purpose: Test variations for optimization

Lifecycle:

```

Experiment Start → Collect Data → Analyze → Choose Winner → Remove Flag

```

Example:

```typescript

const variant = abTest.getVariant('checkout-button-color');

return ;

```

Cleanup: Remove after experiment concludes (< 4 weeks)

---

Format: MAJOR.MINOR.PATCH

MAJOR (x.0.0): Breaking changes

• API contract changes
• Database schema breaking changes
• Removal of deprecated features

MINOR (0.x.0): New features, backward-compatible

• New API endpoints
• New database tables (additive only)
• Enhanced functionality

PATCH (0.0.x): Bug fixes, backward-compatible

• Bug fixes
• Performance improvements
• Security patches

Example:

```

v1.0.0 → Initial release

v1.1.0 → Add 2FA feature (backward-compatible)

v1.1.1 → Fix OTP validation bug

v2.0.0 → Remove old login endpoint (breaking change)

```

---

Strategy 1: Blue-Green Deployment

Definition: Two identical environments (Blue = Current, Green = New)

Process:

```markdown

1. Deploy new version to Green environment
2. Run smoke tests on Green
3. Switch router from Blue to Green
4. Monitor Green for 30 minutes
5. If issues: Switch back to Blue (instant rollback)
6. If success: Keep Green, Blue becomes staging

```

Advantages:

• Instant rollback
• Zero downtime
• Full environment testing before switch

Disadvantages:

• Requires double infrastructure
• Database migrations tricky

---

Strategy 2: Canary Deployment

Definition: Gradual rollout to subset of users

Process:

```markdown

1. Deploy new version alongside old version
2. Route 5% of traffic to new version
3. Monitor error rates, latency for 1 hour
4. If metrics normal: Increase to 25%
5. If metrics normal: Increase to 50%
6. If metrics normal: Increase to 100%
7. Remove old version

```

Advantages:

• Limited blast radius
• Real user feedback
• Gradual confidence building

Disadvantages:

• Requires sophisticated routing
• Slower rollout

---

Strategy 3: Rolling Deployment

Definition: Update instances one by one

Process:

```markdown

1. Take instance 1 out of load balancer
2. Update instance 1
3. Run health checks
4. Add instance 1 back to load balancer
5. Repeat for instance 2, 3, etc.

```

Advantages:

• No downtime
• Resource efficient

Disadvantages:

• Mixed versions running simultaneously
• Slower than blue-green

---

```markdown

# Release Checklist: v1.2.0

Release Type: Minor

Release Date: 2025-11-20

Release Manager: [Name]

Coordinator: release-coordinator

Development

• [ ] All features completed
• [ ] Code review passed (code-reviewer)
• [ ] All tests passing (test-engineer)
• [ ] Test coverage ≥ 80% (quality-assurance)
• [ ] Performance benchmarks met (performance-optimizer)
• [ ] Security audit passed (security-auditor)
• [ ] Documentation updated (technical-writer)

Traceability

• [ ] All requirements traced to code (traceability-auditor)
• [ ] Constitutional compliance verified (constitution-enforcer)

Staging Deployment

• [ ] Deployed to staging (devops-engineer)
• [ ] Smoke tests passed
• [ ] E2E tests passed
• [ ] Load tests passed

Pre-Deployment

• [ ] Stakeholder approval obtained
• [ ] Release notes generated
• [ ] Rollback plan documented
• [ ] Support team notified

Deployment

• [ ] Database migrations applied (if any)
• [ ] Feature flags configured
• [ ] Deploy to production (devops-engineer)
• [ ] Canary deployment: 5% traffic
• [ ] Monitor for 1 hour (site-reliability-engineer)

Progressive Rollout

• [ ] 5% → No errors → Increase to 25%
• [ ] 25% → No errors → Increase to 50%
• [ ] 50% → No errors → Increase to 100%

Verification

• [ ] Health checks passing (site-reliability-engineer)
• [ ] SLOs met (site-reliability-engineer)
• [ ] No error spike in logs
• [ ] User feedback monitored

Communication

• [ ] Release notes published
• [ ] Changelog updated
• [ ] Users notified (if breaking changes)
• [ ] Documentation live

Cleanup

• [ ] Release branch merged to main
• [ ] Release tag created (v1.2.0)
• [ ] Feature flags removed (if temporary)
• [ ] Post-mortem scheduled (if issues)

Trigger rollback if:

• [ ] Error rate > 5% (vs < 1% baseline)
• [ ] Latency p95 > 500ms (vs < 200ms baseline)
• [ ] Customer complaints > 10 in 1 hour
• [ ] Critical bug discovered
• [ ] SLO breach detected

1. Set feature flag OFF (instant mitigation)
2. Revert traffic routing to previous version
3. Notify stakeholders
4. Investigate root cause (bug-hunter)
5. Fix and re-release

```

---

Automated Changelog from Git Commits

Convention: Use Conventional Commits

```bash

# Example commits

feat: Add two-factor authentication (REQ-003)

fix: Resolve OTP validation timeout (BUG-123)

docs: Update API documentation for 2FA

refactor: Extract OTP generation to service

perf: Optimize database query for user lookup

```

Generated Changelog:

```markdown

# Changelog

Added

• Two-factor authentication for enhanced security (REQ-003)
• OTP email delivery with retry logic

Fixed

• Resolved OTP validation timeout issue (BUG-123)
• Fixed session cookie expiration on mobile

Changed

• Optimized database query for user lookup (30% faster)
• Updated API documentation for 2FA endpoints

Deprecated

• Old /login endpoint (will be removed in v2.0.0)

Security

• Implemented OWASP-recommended OTP expiration (5 minutes)

```

---

```markdown

# Release Notes: v1.2.0

Release Date: November 20, 2025

Release Type: Minor Release

Two-Factor Authentication

We've added an optional two-factor authentication (2FA) feature to enhance account security.

How to enable:

1. Go to Settings → Security
2. Click "Enable 2FA"
3. Enter your email to receive a one-time password
4. Verify OTP and save

Performance Improvements

• 30% faster user profile loading
• Reduced API response time from 250ms to 180ms (p95)

• Fixed session timeout issue on mobile devices
• Resolved OTP email delivery delays
• Corrected timezone handling in user dashboard

• Updated API documentation with 2FA endpoints
• Added migration guide for upgrading from v1.1.x
• New tutorial: Setting up two-factor authentication

None. This release is fully backward-compatible.

• Biometric authentication for mobile apps
• Single sign-on (SSO) support
• Enhanced admin dashboard

If you encounter any issues, please contact support@example.com or visit our [Help Center](https://help.example.com).

```

---

• Before:

- devops-engineer creates deployment pipelines

- test-engineer validates all tests pass

- quality-assurance approves quality gates

• After:

- site-reliability-engineer monitors production

- technical-writer publishes release notes

- project-manager updates sprint closure

• Uses:

- Change logs from version control

- Test reports from test-engineer

- Approval from constitution-enforcer

---

Phase 1: Release Planning

1. Identify features/fixes for release
2. Determine release type (hotfix/patch/minor/major)
3. Set release date and timeline
4. Assign release manager

Phase 2: Pre-Release Validation

1. Run traceability-auditor (ensure 100% coverage)
2. Run constitution-enforcer (ensure governance compliance)
3. Review test coverage (quality-assurance)
4. Security audit (security-auditor)

Phase 3: Release Preparation

1. Create release branch
2. Generate changelog from commits
3. Write release notes
4. Prepare rollback plan
5. Configure feature flags

Phase 4: Stakeholder Approval

1. Present release package to stakeholders
2. Demonstrate on staging
3. Obtain approvals (PM, Tech Lead, QA, Security)

Phase 5: Deployment

1. Deploy to production (devops-engineer)
2. Execute deployment strategy (canary/blue-green/rolling)
3. Monitor metrics (site-reliability-engineer)
4. Progressive rollout (5% → 25% → 50% → 100%)

Phase 6: 段階的ポストリリース

CRITICAL: コンテキスト長オーバーフロー防止

出力方式の原则:

• ✅ 1タスクずつ順番に実行・報告
• ✅ 各タスク後に進捗を報告
• ✅ エラー発生時も部分的な成果物が残る

```

🤖 確認ありがとうございます。ポストリリースタスクを順番に実行します。

【実行予定のタスク】

1. ヘルスチェックSLO検証
2. リリースノート公開
3. ユーザー通知
4. クリーンアップ(ブランチマージ、フィーチャーフラグ削除)
5. 振り返り会議スケジュール

合計: 5タスク

重要: 段階的実行方式

各タスクを1つずつ実行・報告し、進捗を報告します。

これにより、途中経過が見え、エラーが発生しても部分的な成果物が残ります。

実行を開始してよろしいですか?

👤 ユーザー: [回答待ち]

```

ユーザーが承認後、各タスクを順番に実行:

Step 1: ヘルスチェック検証

```

🤖 [1/5] ヘルスチェックとSLOを検証しています...

✅ 検証完了: すべてのヘルスチェックが成功

✅ SLO: 99.95% (Target: 99.9%)

[1/5] 完了。次のタスクに進みます。

```

Step 2: リリースノート公開

```

🤖 [2/5] リリースノートを公開しています...

📝 docs/releases/v1.2.0.md

✅ 公開完了

[2/5] 完了。次のタスクに進みます。

```

大きなリリースドキュメント(>300行)の場合:

```

🤖 包括的なリリースドキュメントを生成しています...

⚠️ リリースノートが詳細で400行になるため、2パートに分割して生成します。

📝 Part 1/2: docs/releases/v2.0.0.md (新機能 & 破壊的変更)

✅ 保存が完了しました (250行)

📝 Part 2/2: docs/releases/v2.0.0.md (バグ修正 & 移行ガイド)

✅ 保存が完了しました (180行)

✅ リリースノート生成完了: docs/releases/v2.0.0.md (430行)

💡 ユーザー向け、開発者向けの両方の情報を含みます

```

Final: ポストリリース完了サマリー

```

🤖 ✨ ポストリリースタスクが完了しました！

• リリースバージョン: v1.2.0
• デプロイ成功率: 100%
• SLO達成率: 99.95%

1. ✅ ヘルスチェック検証
2. ✅ リリースノート公開 (docs/releases/v1.2.0.md)
3. ✅ ユーザー通知送信
4. ✅ クリーンアップ(ブランチマージ、フィーチャーフラグ削除)
5. ✅ 振り返り会議スケジュール (2025-11-27)

```

1. Verify health checks and SLOs
2. Publish release notes
3. Notify users
4. Cleanup: Merge branches, remove temporary feature flags
5. Schedule retrospective

---

1. Automate Changelog: Use Conventional Commits for auto-generation
2. Feature Flags: Always use flags for large features
3. Progressive Rollout: Never deploy 100% immediately
4. Rollback Readiness: Always have rollback procedure ready
5. Communication: Over-communicate with stakeholders
6. Monitoring: Watch metrics closely during rollout

---

```markdown

# Release Plan: v1.2.0

Release Type: Minor

Release Date: 2025-11-20

Release Manager: [Name]

Coordinator: release-coordinator

Features

• [ ] Two-factor authentication (REQ-003)
• [ ] User profile enhancements (REQ-015)

Bug Fixes

• [ ] OTP validation timeout (BUG-123)
• [ ] Session cookie expiration (BUG-145)

| Date | Milestone | Owner |

| --------- | --------------------- | ------------------- |

| Nov 13 | Code freeze | Dev Team |

| Nov 14 | Deploy to staging | devops-engineer |

| Nov 15-17 | QA testing | quality-assurance |

| Nov 18 | Stakeholder approval | PM/Tech Lead |

| Nov 20 | Production deployment | release-coordinator |

Type: Canary Deployment

Phases:

1. 5% (1 hour monitoring)
2. 25% (2 hours monitoring)
3. 50% (4 hours monitoring)
4. 100% (24 hours monitoring)

| Flag | Type | Default | Cleanup Date |

| ---------------- | ------- | ------- | ------------ |

| ENABLE_2FA | Release | OFF | Dec 4, 2025 |

| NEW_PROFILE_UI | Release | OFF | Dec 10, 2025 |

Triggers: Error rate > 5%, Latency > 500ms, Critical bug

Procedure:

1. Set feature flags OFF
2. Revert traffic to old version
3. Notify stakeholders
4. Investigate and fix

• [ ] Product Manager
• [ ] Technical Lead
• [ ] QA Manager
• [ ] Security Team
• [ ] Release Coordinator

• [ ] Publish release notes
• [ ] Update documentation
• [ ] Notify users
• [ ] Cleanup feature flags (2 weeks post-release)
• [ ] Schedule retrospective

```

---

ALWAYS check steering files before starting:

• steering/structure.md - Understand component organization
• steering/tech.md - Identify deployment tools (Docker, K8s, etc.)
• steering/product.md - Understand business impact and user base

---

Before finishing:

• [ ] Release type determined
• [ ] Release timeline defined
• [ ] Deployment strategy selected
• [ ] Feature flags configured
• [ ] Changelog generated
• [ ] Release notes written
• [ ] Rollback plan documented
• [ ] Stakeholder approvals obtained
• [ ] Release checklist created
• [ ] Saved to storage/releases/v[X.Y.Z]/release-plan.md