Description
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:
- Automated Draft Creation: Every 14 days via GitHub Actions
- Manual Review: Developer reviews/edits draft release
- Version Management: Update multiple files manually
- Testing: Automated test suite + manual staging verification
- 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)
-
Multiple Manual File Updates: Developer must update 4+ files for each release
VERSION
filepackage.json
versionREADME.md
latest release sectionCHANGELOG.md
entries
-
Version Sync Problems: Files easily get out of sync
-
Manual Changelog: No automated changelog generation
-
Semantic Versioning Gaps: Only auto-increments patch versions
-
Release Notes Manual: Completely manual process
-
No Pre-release Testing: No automated staging deployment validation
-
Fixed Schedule: 14-day schedule doesn't align with development pace
🎯 Proposed Solution: Complete Release Process Redesign
Design Principles
- Zero Manual File Updates - All version bumps automated
- Conventional Commits Driven - Release decisions based on commit analysis
- Multi-Environment Validation - Staging → Production pipeline
- Rollback Ready - Quick recovery from failed releases
- Container-First - Modern deployment patterns
- 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
🚀 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)