/release-init

description: Initialize or analyze release strategy for the project. For new projects, recommends optimal release approach based on architecture, team size, and deployment frequency. For brownfield projects, detects existing release patterns from git history, CI/CD configs, and package managers, then documents the strategy. Creates release-strategy.md in living docs with comprehensive release process documentation.

sw-release:init - Initialize Release Strategy

Initialize or analyze the release strategy for your project.

What This Command Does

**For New Projects (Greenfield)**: 1. Analyzes project architecture (single-repo, multi-repo, monorepo) 2. Asks about team size, deployment frequency, coupling between services 3. Recommends optimal release strategy (lockstep, independent, umbrella) 4. Creates `.specweave/docs/internal/delivery/release-strategy.md` 5. Suggests CI/CD automation opportunities

**For Existing Projects (Brownfield)**: 1. Scans git history for version tags and patterns 2. Analyzes CI/CD configurations (.github/workflows/, .gitlab-ci.yml, etc.) 3. Checks package manager files (package.json, setup.py, pom.xml, etc.) 4. Detects monorepo tools (Lerna, Nx, Turborepo, Changesets) 5. Documents existing strategy in living docs 6. Suggests improvements and best practices

Usage

# Interactive analysis and recommendation
sw-release:init

# Force re-analysis (overwrite existing strategy)
sw-release:init --force

# Quick analysis (no interactive prompts, use defaults)
sw-release:init --quick

Workflow

Greenfield Projects

1. Project Structure Analysis
   → Detect repositories (scan for .git/)
   → Count services/packages
   → Identify architecture pattern

2. Interactive Questionnaire
   ? How many repositories? [1 / 2-5 / 5+]
   ? Team structure? [One team / Per-service teams / Mixed]
   ? Deployment frequency? [Daily / Weekly / Monthly / Ad-hoc]
   ? Coupling between services? [Tight / Moderate / Loose]
   ? Planning to use RC workflow? [Yes / No / For major versions only]

3. Strategy Recommendation
   Based on your answers:
   → Recommended: Umbrella Versioning
   → Rationale: Medium-sized team, weekly releases, moderate coupling
   → RC workflow: For major versions (breaking changes)

4. Documentation Creation
   → Create: .specweave/docs/internal/delivery/release-strategy.md
   → Include: Versioning approach, RC workflow, CI/CD integration
   → Add: Release checklist, rollback procedures

5. Next Steps Guidance
   → Set up CI/CD automation (GitHub Actions template provided)
   → Configure semantic-release or Changesets
   → Define release waves (dependency order)
   → Create first release increment: sw:increment "0001-v1-release"

Brownfield Projects

1. Git History Scan
   → Analyzing tags: git tag --list
   → Found: 45 tags (v1.0.0, v1.1.0, ..., v3.2.0)
   → Pattern: Semantic versioning ✓
   → RC usage: Detected for major versions (v2.0.0-rc.1, v3.0.0-rc.1)
   → Cadence: ~1 release per week

2. CI/CD Detection
   → Found: .github/workflows/release.yml
   → Tool: semantic-release ✓
   → Triggers: Push to main with version tags
   → Actions: Build → Test → Publish to NPM → Create GitHub Release

3. Package Manager Analysis
   → Found: package.json (NPM project)
   → Current version: 3.2.0 (matches git tag ✓)
   → Scripts: npm version, npm publish ✓
   → Dependencies: 25 packages

4. Monorepo Detection (if applicable)
   → Found: lerna.json
   → Mode: independent (packages version separately)
   → Packages: 12
   → Tool: Lerna v7.4.0

5. Strategy Classification
   Current Strategy:
   → Type: Monorepo with independent versioning
   → Tool: Lerna + semantic-release
   → RC: For major versions only
   → Frequency: Weekly
   → Automation: High (GitHub Actions)

6. Documentation Creation
   → Create: .specweave/docs/internal/delivery/release-strategy.md
   → Document: Existing process, tools, patterns
   → Add: Version matrix (for umbrella releases if applicable)

7. Improvement Suggestions
   Recommendations:
   ✓ Current strategy is solid
   → Consider: Changesets for better changelog management
   → Consider: Umbrella versioning for product milestones
   → Add: Version matrix documentation (.specweave/docs/internal/delivery/version-matrix.md)
   → Enhance: RC workflow with canary deployments

What Gets Created

**File**: `.specweave/docs/internal/delivery/release-strategy.md`

**Structure**:

# Release Strategy: {Project Name}

## Overview
- Repository Type: Single-repo / Multi-repo / Monorepo
- Versioning Strategy: Lockstep / Independent / Umbrella
- RC Workflow: Yes / No / Major versions only
- Release Frequency: Daily / Weekly / Monthly
- Automation Level: Manual / Semi-automated / Fully automated

## Repositories
| Repo | Purpose | Current Version | Frequency |
|------|---------|----------------|-----------|
| frontend | User interface | v5.2.0 | Weekly |
| backend | API server | v3.8.0 | Bi-weekly |
| shared-lib | Shared utilities | v2.1.0 | Monthly |

## Version Alignment
- **Major versions**: Coordinated (breaking changes affect all)
- **Minor versions**: Independent (services evolve separately)
- **Patch versions**: Independent (bug fixes as needed)

## Release Candidate Workflow
1. Create RC tag: v{major}.{minor}.{patch}-rc.1
2. Deploy to staging environment
3. Run validation tests (unit + integration + E2E + performance)
4. Testing phase: 1-2 weeks
5. Bug fixes → Iterate to rc.2, rc.3, ...
6. All tests pass → Promote to production: v{major}.{minor}.{patch}
7. Gradual rollout: 10% → 25% → 50% → 100%

## CI/CD Integration
- **Tool**: GitHub Actions / GitLab CI / Jenkins / CircleCI
- **Trigger**: Push tags matching v*.*.* pattern
- **Workflow**:
  1. Build: Compile, bundle, create artifacts
  2. Test: Run all automated tests
  3. Publish: NPM / PyPI / Docker Registry / Maven Central
  4. Release: Create GitHub/GitLab release with changelog
  5. Deploy: Push to staging/production (Kub