Release Management & Deployment Strategies

Purpose: Decision guides, versioning rules, deployment strategy selection, and release checklists. For full YAML examples and runbook templates, see the references/ directory.

When to Use This Skill

• •Planning release pipelines and strategies
• •Choosing deployment strategies (blue-green, canary, rolling)
• •Implementing automated release workflows
• •Designing rollback procedures
• •Setting up versioning with SemVer or CalVer

Prerequisites

• •CI/CD pipeline infrastructure
• •Version control system (Git)

Quick-Start: Deployment Strategy Selection

Pick your strategy first — everything else follows from this choice.

Decision tree:

Need zero-downtime?
├─ No  → Recreate (dev/test only)
└─ Yes
   ├─ Need instant rollback?
   │  ├─ Yes → Blue-Green  (if budget allows 2× infra)
   │  └─ Yes → Feature Flags (if code-level control preferred)
   └─ Need gradual risk reduction?
      ├─ Yes, by traffic %  → Canary
      └─ Default / simplest → Rolling

Full YAML examples for each strategy: references/deployment-strategy-examples.md

Table of Contents

1. •Deployment Strategy Selection
2. •Versioning Strategies
3. •Deployment Strategies — Concepts
4. •Rollback Procedures
5. •Release Pipeline Architecture
6. •Release Automation
7. •Release Checklist
8. •Best Practices
9. •Related Skills & Resources

Versioning Strategies

Choosing a Versioning Scheme

Is your release cadence time-based (monthly/quarterly)?
├─ Yes → CalVer  (YYYY.MM.DD)
└─ No
   ├─ Do you expose a public API or library?
   │  └─ Yes → SemVer  (MAJOR.MINOR.PATCH)
   └─ Internal service / continuous delivery?
      └─ Commit-Based  (v1.0.{count}+{sha})

Semantic Versioning (SemVer)

Format: MAJOR.MINOR.PATCH[-PRERELEASE][+BUILD]

Version Increment Rules:

Key rules:

• •Once a version is released, its contents must not change
• •Pre-release versions (-alpha.1, -beta.2, -rc.1) have lower precedence than the release
• •Build metadata (+build.1) is ignored for version precedence

Calendar Versioning (CalVer)

Format: YYYY.MM[.DD][.MICRO]

When to use:

• •Time-based release cadences (monthly, quarterly)
• •Marketing-driven version numbers
• •Consumer products with regular update schedules
• •Ubuntu, pip, and similar projects use CalVer

Commit-Based Versioning

Format: v{MAJOR}.{MINOR}.{COMMIT_COUNT}+{SHORT_SHA}

Best for internal services with continuous delivery where every merge to main is a release candidate.

Pre-Release Label Progression

Automation: Version bump + changelog workflows → references/release-automation-workflows.md

Deployment Strategies — Concepts

Blue-Green Deployment

Two identical production environments; deploy to inactive, test, swap traffic.

Pros: Zero downtime · Instant rollback · Full pre-switch testing Cons: Double infrastructure cost · DB migration complexity

Canary Deployment

Route a small percentage of traffic to the new version; expand on success.

Pros: Low risk · Real user feedback · Gradual rollout Cons: Complex setup · Requires robust observability

Rolling Deployment

Replace instances one-at-a-time (or in small batches).

Pros: Built-in to K8s / ECS · Zero downtime · Automatic rollback Cons: Briefly mixed versions · Slower than blue-green

Feature Flags / Feature Toggles

Deploy code with features disabled; enable via configuration per user/percentage.

Pros: Instant rollback · Decouple deploy from release · A/B testing Cons: Code complexity · Stale flag cleanup required

Full YAML & K8s manifests for all strategies: references/deployment-strategy-examples.md

Rollback Procedures

Rollback Decision Criteria

Trigger a rollback when any of these thresholds are breached post-deploy:

Rollback Strategies by Deployment Type

Database Rollback Principles

1. •Forward-only migrations — never drop columns; deprecate first
2. •Backward-compatible changes — new code must work with old schema during rollout
3. •Blue-green with separate DBs — rollback by switching connection string
4. •Always test undo scripts in staging before production

Full rollback scripts (automated + manual + DB): references/rollback-scripts.md

Release Pipeline Architecture

A release pipeline should follow this stage progression:

Validate Tag → Build → Test → Create Release → Deploy Staging
    → Smoke Tests → Deploy Production → Post-Deploy Verification

Key pipeline principles:

• •Trigger on semantic version tags (v*.*.*)
• •Build once, deploy the same artifact to every environment
• •Gate production deployment behind staging smoke tests
• •Use GitHub Environments with required reviewers for production
• •Generate changelog automatically from conventional commits
• •Attach build artifacts to GitHub Releases

Full pipeline YAML (GitHub Actions + Azure Pipelines): references/release-pipeline-examples.md

Release Automation

What to Automate

Conventional Commits → Version Bump Mapping

Full automation workflows: references/release-automation-workflows.md

Release Checklist

Pre-Release

• • All tests passing (unit, integration, e2e)
• • Code coverage ≥ 80%
• • Security scan completed (dependencies + SAST)
• • Dependencies updated and audited
• • Changelog generated from conventional commits
• • Release notes drafted
• • Migration scripts tested in staging
• • Rollback procedure documented and tested
• • Stakeholders notified of release window

Deployment

• • Deploy to staging environment
• • Smoke tests passed (staging)
• • Load / performance testing completed
• • Deploy to production (via chosen strategy)
• • Smoke tests passed (production)
• • Monitoring dashboards reviewed

Post-Release

• • Health checks verified (HTTP 200, all endpoints)
• • Error rate at or below baseline
• • P95 latency at or below baseline
• • User feedback channels monitored
• • Incident response team aware and on-call
• • Documentation updated (API docs, runbook, changelog)
• • Release announcement sent to stakeholders

Communication template + runbook: references/release-runbook-template.md

Best Practices

✅ DO

• •Use semantic versioning consistently; tag every release in VCS
• •Maintain changelogs automatically via conventional commits
• •Version APIs explicitly (URL path or header)
• •Always test in staging before production
• •Use gradual rollouts (canary / feature flags) for high-risk changes
• •Monitor error rates and latency during and after deployment
• •Have a tested rollback plan before every release
• •Document procedures in a runbook
• •Notify stakeholders before the deployment window
• •Communicate breaking changes with migration guides
• •Automate version bumping, changelog generation, and smoke tests
• •Trigger automated rollback on health check failure
• •Establish baseline metrics before each release
• •Implement /health and /ready endpoints on every service

❌ DON'T

• •Deploy on Fridays, holidays, or outside on-call hours
• •Skip staging validation — even for "small" changes
• •Deploy without a documented rollback plan
• •Bundle multiple major changes into a single release
• •Skip versions or hard-code version numbers
• •Deploy without active monitoring and on-call coverage
• •Ignore failed health checks
• •Rush deployments under time pressure

Related Skills & Resources

Related Skills:

• •GitHub Actions & Workflows
• •YAML Pipelines
• •Version Control
• •Monitoring & Logging

External Resources:

• •Semantic Versioning Specification
• •Conventional Commits
• •Kubernetes Deployment Strategies
• •Martin Fowler — BlueGreenDeployment

Reference Files (full examples, scripts, and templates):

Version: 2.0.0 Author: AgentX Last Updated: February 10, 2026

Scripts

Troubleshooting