Skip to content

Modernize Release Process: Complete Automation & CI/CD Pipeline #678

Open
@aaronlippold

Description

@aaronlippold

Modernize Vulcan Release Process: Complete Automation & CI/CD Pipeline

📋 Overview

This issue proposes a complete redesign of Vulcan's release process to eliminate manual steps, improve reliability, and implement modern CI/CD best practices. The current process requires significant manual intervention and is prone to human error.

🔍 Current State Analysis

Existing Release Workflow

Based on Wiki: Releasing Vulcan:

  1. Automated Draft Creation: Every 14 days via GitHub Actions
  2. Manual Review: Developer reviews/edits draft release
  3. Version Management: Update multiple files manually
  4. Testing: Automated test suite + manual staging verification
  5. Publishing: Manual release publication

Current Automation (✅ Working)

  • Draft Release Creation (.github/workflows/create-draft-release.yml)

    • Runs every 14 days automatically
    • Auto-calculates next patch version (v2.1.8 → v2.1.9)
    • Downloads source artifacts
    • Creates GitHub draft release
  • Docker Publishing (.github/workflows/push-to-docker.yml)

    • Triggers on successful test suite OR published release
    • Publishes mitre/vulcan:latest on master pushes
    • Publishes mitre/vulcan:v2.x.x on release publication
  • Test Automation (.github/workflows/run-tests.yml)

    • Runs on PRs, pushes, draft releases
    • PostgreSQL + LDAP container testing
    • RSpec + RuboCop + Yarn lint

Current Pain Points (🔴 Issues)

  1. Multiple Manual File Updates: Developer must update 4+ files for each release

    • VERSION file
    • package.json version
    • README.md latest release section
    • CHANGELOG.md entries
  2. Version Sync Problems: Files easily get out of sync

  3. Manual Changelog: No automated changelog generation

  4. Semantic Versioning Gaps: Only auto-increments patch versions

  5. Release Notes Manual: Completely manual process

  6. No Pre-release Testing: No automated staging deployment validation

  7. Fixed Schedule: 14-day schedule doesn't align with development pace

🎯 Proposed Solution: Complete Release Process Redesign

Design Principles

  1. Zero Manual File Updates - All version bumps automated
  2. Conventional Commits Driven - Release decisions based on commit analysis
  3. Multi-Environment Validation - Staging → Production pipeline
  4. Rollback Ready - Quick recovery from failed releases
  5. Container-First - Modern deployment patterns
  6. Security-First - Automated vulnerability scanning

Architecture Overview

graph TD
    A[Developer Commit] --> B[Commit Analysis]
    B --> C{Should Release?}
    C -->|Yes| D[Version Management]
    C -->|No| E[Wait for more commits]
    D --> F[Build & Test]
    F --> G[Security Scanning]
    G --> H[Build Artifacts]
    H --> I[Deploy Staging]
    I --> J[Staging Validation]
    J --> K[Manual Approval Gate]
    K --> L[Create GitHub Release]
    L --> M[Deploy Production]
    M --> N[Post-deployment Validation]
    N --> O[Notify Stakeholders]
    
    P[Emergency Rollback] -.-> M
Loading

🚀 Implementation Plan

Phase 1: Foundation (Week 1-2)

  • Implement conventional commit standards
  • Create automated version management workflow
  • Add semantic-release integration
  • Automated changelog generation

Phase 2: Enhanced Validation (Week 3-4)

  • Multi-stage validation pipeline
  • Automated security scanning
  • Container vulnerability assessment
  • Build artifact validation

Phase 3: Deployment Pipeline (Week 5-6)

  • Staging deployment automation
  • Integration test validation
  • Manual approval gates
  • Production deployment automation

Phase 4: Monitoring & Recovery (Week 7-8)

  • Post-deployment validation
  • Stakeholder notifications
  • Emergency rollback system
  • Incident management integration

📝 Detailed Implementation

1. Conventional Commit Standards

Implement standardized commit message format:

feat: add OIDC auto-discovery (#672)           # → Minor version bump
fix: resolve LDAP authentication issue (#669)  # → Patch version bump  
feat!: migrate to rails-settings-cached       # → Major version bump
docs: update installation guide               # → No version bump
ci: update GitHub Actions versions            # → No version bump

2. Automated Version Management

Create workflow to atomically update all version files:

# .github/workflows/version-management.yml
name: Automated Version Management

jobs:
  version_bump:
    runs-on: ubuntu-latest
    steps:
      - name: Update all version files atomically
        run: |
          NEW_VERSION="${{ steps.version.outputs.new_version }}"
          
          # Update VERSION file
          echo "$NEW_VERSION" > VERSION
          
          # Update package.json
          jq ".version = \"${NEW_VERSION#v}\"" package.json > package.json.tmp
          mv package.json.tmp package.json
          
          # Update README.md latest release section
          sed -i "s/Latest Release: \[v[0-9]\+\.[0-9]\+\.[0-9]\+\]/Latest Release: [$NEW_VERSION]/" README.md
          
          # Update documentation
          find docs/ -name "*.yaml" -o -name "*.yml" | xargs sed -i "s/mitre\/vulcan:v[0-9]\+\.[0-9]\+\.[0-9]\+/mitre\/vulcan:$NEW_VERSION/g"

3. Multi-Stage Validation Pipeline

# .github/workflows/release-validation.yml
name: Release Validation Pipeline

jobs:
  # Stage 1: Build & Test
  build_and_test:
    strategy:
      matrix:
        ruby: ['3.0', '3.1', '3.2']
        node: ['16', '18', '20']
    steps:
      - name: Run comprehensive test suite
      - name: Security scanning
      - name: Vulnerability assessment
        
  # Stage 2: Build Release Artifacts  
  build_artifacts:
    steps:
      - name: Build multi-platform Docker images
      - name: Generate SBOM
      
  # Stage 3: Staging Deployment
  deploy_staging:
    environment: staging
    steps:
      - name: Deploy to staging
      - name: Run integration tests
      - name: Performance validation
      - name: Security validation
      
  # Stage 4: Manual Approval Gate
  approval_gate:
    environment: production-approval
    steps:
      - name: Request manual approval from team leads

4. Emergency Rollback System

# .github/workflows/emergency-rollback.yml
name: Emergency Rollback

on:
  workflow_dispatch:
    inputs:
      target_version:
        description: 'Version to rollback to'
        required: true
      reason:
        description: 'Rollback reason'
        required: true

jobs:
  rollback:
    environment: production-emergency
    steps:
      - name: Validate rollback target
      - name: Execute rollback
      - name: Validate rollback success
      - name: Create incident report

📊 Expected Benefits

Automation Benefits

  • Zero Manual Steps: Complete automation from commit → production
  • Consistent Quality: Every release follows same validation pipeline
  • Fast Recovery: Automated rollback in <5 minutes
  • Security First: Automated vulnerability scanning & validation

Developer Experience

  • Simple: git commit -m "feat: new feature" → automatic release
  • Predictable: Clear release timeline and process
  • Safe: Staging validation + approval gates
  • Transparent: Full audit trail and notifications

Enterprise Ready

  • Compliance: Full audit trail and approval workflows
  • Security: Automated scanning and validation
  • Reliability: Multi-stage validation and rollback capabilities
  • Monitoring: Comprehensive notifications and metrics

Cost Savings

  • Time: 3 hours → 15 minutes per release
  • Risk: Eliminate human error in version management
  • Quality: Consistent testing and validation
  • Recovery: Fast rollback vs lengthy incident response

🔧 Required Tools & Dependencies

  • semantic-release: Automated version management + changelog
  • conventional-changelog: Generate changelogs from conventional commits
  • GitHub CLI: Streamline GitHub operations
  • Docker Buildx: Multi-platform container builds
  • Trivy: Container vulnerability scanning
  • OWASP ZAP: Security validation

📅 Timeline

  • Target Start: After v2.2.0 settings migration release
  • Estimated Duration: 8 weeks
  • Target Completion: Before v2.3.0 release

🎯 Success Criteria

  • Zero manual file updates required for releases
  • Automated semantic versioning based on conventional commits
  • Automated changelog generation
  • Multi-stage validation pipeline operational
  • Emergency rollback system tested and documented
  • Release time reduced from 3 hours to <15 minutes
  • All team members trained on new process

📚 References

🏷️ Related Issues

  • This modernization enables the container-first migration tooling planned in the settings migration work
  • Supports the enterprise configuration management roadmap
  • Aligns with Vulcan modernization initiatives

Priority: Medium (after v2.2.0 settings migration)
Effort: Large (8 weeks)
Impact: High (major developer experience improvement)

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions