Release Coordinator

Multi-repo release orchestration, RC lifecycle management, and release strategy.

Release Dependency Management

Build-time dependencies

shared-lib: v2.0.0 └─ service-a: v3.1.0 (depends on shared-lib) └─ service-b: v2.5.0 (depends on shared-lib)

Runtime dependencies

auth-service: v1.8.0 └─ api-gateway: v2.0.0 (calls auth-service) └─ frontend: v3.2.0 (calls api-gateway)

Release Order Calculation:

Build dependency graph
Topological sort for correct order
Identify circular dependencies (error)
Generate release waves

Release Waves

Wave 1 (Foundations)

shared-lib: v2.0.0 → v3.0.0
database-migrations: v9 → v10

Wave 2 (Backend Services)

auth-service: v1.8.0 → v2.0.0 (depends: shared-lib v3.0.0)
user-service: v1.5.0 → v2.0.0 (depends: schema v10)

Wave 3 (API Layer)

api-gateway: v2.0.0 → v3.0.0 (depends: auth-service v2.0.0)

Wave 4 (Frontend)

web-app: v3.2.0 → v4.0.0 (depends: api-gateway v3.0.0)

Release Candidate (RC) Lifecycle

Pre-Release Tags

Alpha: 1.0.0-alpha.1 # Early development (unstable) Beta: 1.0.0-beta.1 # Feature complete (testing) RC: 1.0.0-rc.1 # Release candidate (near production) Final: 1.0.0 # Production release

RC Workflow

1. Create RC

git tag -a v2.0.0-rc.1 -m "Release candidate 1" npm version 2.0.0-rc.1

2. Deploy to staging

gh release create v2.0.0-rc.1 --prerelease

3. Testing phase (1-2 weeks)

Bug found → create v2.0.0-rc.2

4. Promote to final

git tag -a v2.0.0 -m "Production release" npm version 2.0.0 gh release create v2.0.0 # NOT prerelease

RC State Machine

DRAFT → TESTING → VALIDATED → PROMOTED ↓ ↓ FAILED HOTFIX → back to TESTING

Tag Cleanup

List RC tags

git tag -l "-rc." | sort -V

Delete old RC after promotion

git tag -d v2.0.0-rc.1 v2.0.0-rc.2 git push origin --delete v2.0.0-rc.1 v2.0.0-rc.2

Coordinated Release Strategies

Strategy When to Use

Lockstep Tight coupling, small team, shared breaking changes

Independent Loose coupling, autonomous teams, frequent releases

Umbrella Product milestones, services evolve at different rates

Lockstep (all repos share version)

Product: v3.0.0 Repositories:

frontend: v3.0.0
backend: v3.0.0
api: v3.0.0

Independent (each repo own version)

Repositories:

frontend: v4.2.0
backend: v2.8.0
api: v3.1.0

Umbrella (product + service versions)

Product: v5.0.0 (umbrella) ├─ frontend: v4.2.0 ├─ backend: v2.8.0 └─ api: v3.1.0

Brownfield Strategy Detection

Analyzes existing projects to detect release patterns:

Git: Version tags, release branches
CI/CD: GitHub Actions, GitLab CI, Jenkins
Package Managers: NPM, Python, Go
Monorepo Tools: Lerna, Nx, Turborepo
Release Automation: semantic-release, standard-version

Pre-Release Validation

1. Version Compatibility

✓ shared-lib v2.0.0 compatible with service-a v3.0.0 ✗ Database schema v10 required but only v9 deployed

2. CI/CD Status

✓ All tests passing ✗ Staging deployment failed

3. Documentation

✓ CHANGELOG.md updated ✗ Migration guide missing

Rollback Coordination

Rollback: v3.0.0 → v2.5.0 (Reverse wave order)

Wave 1 (Rollback Frontend First)

web-app: v4.0.0 → v3.2.0
mobile-app: v3.0.0 → v2.5.0

Wave 2 (Rollback API Layer)

api-gateway: v3.0.0 → v2.8.0

Wave 3 (Backend - Optional)

Keep backend if backward compatible

Living Documentation

Creates release-strategy.md:

Release Strategy: {Product Name}

Current Strategy

Type: Multi-repo / Monorepo / Microservices
Versioning: Semantic / Date-based
Alignment: Lockstep / Independent / Umbrella
RC Process: Pre-release tags / Channels

Release Checklist

Integration with SpecWeave

1. Plan release increment

/sw:increment "0025-product-v3-release"

2. Execute wave-by-wave

/sw:do

3. Complete release

/sw:done 0025

Best Practices

Understand dependencies before releasing
Execute wave-by-wave (never "big bang")
Always use RC for major versions
Have rollback plan ready
Monitor 1+ hour post-release
Clean up RC tags after promotion

Related Skills

version-aligner
Semver constraints, version conflict detection

release-coordinator

Safety Notice

Copy this and send it to your AI assistant to learn