Deployment Automation Skill

code

✨ SKILL ACTIVATED: deployment-automation
   Purpose: CI/CD pipeline design and deployment strategies
   Functionality: Architecture planning, CI pipeline design, deployment patterns, monitoring setup
   Output: Complete CI/CD pipeline specifications and automation workflows
   Scope: Portable across VS Code, CLI, Claude, Cursor, and compatible agents

Purpose

Systematic methodology for designing and implementing CI/CD pipelines, deployment strategies, and release automation. Covers GitHub Actions workflows, container orchestration, infrastructure-as-code patterns, and automated release processes.

When to Use This Skill

•Designing CI/CD pipelines and workflows
•Implementing GitHub Actions automation
•Planning container deployments (Docker, Kubernetes)
•Creating release and versioning strategies
•Setting up infrastructure-as-code (Terraform, CloudFormation)
•Automating testing, building, and deployment phases
•Establishing monitoring and rollback strategies
•Planning multi-environment deployments

Deployment Framework

Phase 1: Architecture Planning

Objective: Define deployment strategy and infrastructure

Strategy Options:

•
Blue-Green Deployment
- •Run two identical production environments
- •Switch traffic between versions
- •Pros: Zero downtime, instant rollback
- •Cons: Double infrastructure cost, data consistency challenges
- •Best for: Critical applications, frequent releases
•
Canary Deployment
- •Release to small percentage of users first
- •Gradually increase traffic percentage
- •Monitor metrics and rollback if needed
- •Pros: Low risk, real-world testing
- •Cons: Complex monitoring, slower rollout
- •Best for: High-traffic applications, major changes
•
Rolling Deployment
- •Update instances/containers one at a time
- •Maintain availability during updates
- •Pros: No extra infrastructure, simple monitoring
- •Cons: Longer deployment time, brief capacity reduction
- •Best for: Microservices, stateless applications
•
Feature Flags
- •Deploy behind feature toggles
- •Control feature availability without redeployment
- •Pros: Instant enable/disable, A/B testing
- •Cons: Code complexity, configuration management
- •Best for: Rapid development, large teams

Selection Matrix:

Factor	Blue-Green	Canary	Rolling	Feature Flag
Complexity	Medium	High	Low	Medium
Rollback Speed	Instant	Minutes	Minutes	Instant
Cost	2x	1x	1x	1x
Risk	Low	Low	Medium	Low

Phase 2: CI Pipeline Design

Objective: Automate code validation and artifact creation

Pipeline Stages:

code

Push Code
  ↓ [Trigger]
1. Build
   - Compile/transpile code
   - Run linters
   - Generate artifacts
  ↓ [Success]
2. Test
   - Unit tests
   - Integration tests
   - Coverage reports
  ↓ [Success]
3. Security
   - SAST (static analysis)
   - Dependency scanning
   - Container scanning
  ↓ [Success]
4. Artifact
   - Build Docker image / packages
   - Push to registry
   - Create release artifacts
  ↓ [Success]
5. Deploy (Staging)
   - Deploy to staging environment
   - Run smoke tests
   - Verify functionality
  ↓ [Approval Gate]
6. Deploy (Production)
   - Execute deployment strategy
   - Monitor health metrics
   - Enable rollback if needed

GitHub Actions Example Structure:

yaml

name: CI/CD Pipeline
on:
  push:
    branches: [main, develop]
  pull_request:
    branches: [main]

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: Build
        run: npm run build
  
  test:
    needs: build
    runs-on: ubuntu-latest
    steps:
      - name: Run tests
        run: npm test
  
  deploy:
    needs: [build, test]
    if: github.ref == 'refs/heads/main'
    runs-on: ubuntu-latest
    steps:
      - name: Deploy
        run: npm run deploy

Phase 3: Environment Configuration

Objective: Manage configuration across environments

Environment Levels:

Level	Purpose	Data	Secrets	Update Frequency
Dev	Developer testing	Fake/seeded	Non-prod	Per commit
Staging	Pre-production testing	Production-like	Non-prod	Per release candidate
Production	Live user traffic	Real data	Prod secrets	Controlled releases

Configuration Management:

•
Environment Variables
- •Use .env files for development (NOT committed)
- •Use GitHub Secrets for sensitive data
- •Use ConfigMaps for Kubernetes
- •Use Systems Manager Parameter Store (AWS)
•
Secrets Rotation
- •Automate secret rotation schedules
- •Implement graceful secret transitions
- •Audit secret access
- •Revoke compromised secrets immediately

•

Configuration-as-Code

yaml

# Example: Environment config
environments:
  development:
    database_url: postgresql://dev-db:5432/app_dev
    log_level: DEBUG
    cache_ttl: 300
  production:
    database_url: # from secret
    log_level: ERROR
    cache_ttl: 3600

Phase 4: Testing Strategy

Objective: Comprehensive validation before production

Test Layers:

•
Unit Tests
- •Fast execution (< 1 second per test)
- •80%+ code coverage target
- •Test single functions/methods
- •Run on every commit
•
Integration Tests
- •15-30 second execution
- •Test component interactions
- •Use test databases/services
- •Run on pull requests
•
End-to-End Tests
- •Full user workflows
- •1-5 minute execution
- •Browser/API testing
- •Run before production deployment
•
Performance Tests
- •Load testing (concurrent users)
- •Stress testing (peak conditions)
- •Profiling and optimization
- •Establish performance baselines
•
Security Tests
- •SAST (SonarQube, CodeQL)
- •DAST (Burp Suite, OWASP ZAP)
- •Dependency scanning (Dependabot, Snyk)
- •Container scanning (Trivy)

Phase 5: Monitoring & Observability

Objective: Track health and performance in production

Key Metrics:

yaml

Availability:
  - Uptime percentage (target: 99.9%+)
  - Error rates (target: < 0.1%)
  - Successful request rate

Performance:
  - Response time (p50, p95, p99)
  - Throughput (requests/second)
  - Database query latency

Resources:
  - CPU usage
  - Memory usage
  - Disk usage
  - Network bandwidth

Business:
  - User signups
  - Transactions completed
  - Feature adoption

Observability Stack:

•
Logs
- •Structured logging (JSON format)
- •Log levels: ERROR, WARN, INFO, DEBUG
- •Centralized logging (ELK, Splunk, CloudWatch)
- •Searchable and filterable
•
Metrics
- •Prometheus/CloudWatch for metrics collection
- •Dashboards for visualization
- •Alerting on thresholds
- •Time-series retention
•
Traces
- •Distributed tracing (Jaeger, Datadog)
- •Request flow across services
- •Latency breakdown
- •Error context
•
Alerts
- •Alert on error rate spike
- •Alert on latency increase
- •Alert on resource exhaustion
- •Page on-call team

Phase 6: Rollback Strategy

Objective: Recover quickly from failed deployments

Rollback Approaches:

•
Instant Rollback (Blue-Green)
- •Switch load balancer to previous version
- •Execution time: < 1 minute
- •Data migration: Backward compatible required
•
Gradual Rollback (Canary)
- •Reduce traffic to new version
- •Route back to stable version
- •Execution time: 5-15 minutes
•
Database Rollback
- •Non-breaking schema changes (add columns, new tables)
- •Never delete data immediately
- •Use feature flags for data compatibility
- •Plan migration path
•
Rollback Checklist
- • Identify root cause
- • Notify on-call team
- • Initiate rollback procedure
- • Verify previous version health
- • Post-mortem after resolution

Phase 7: Release Management

Objective: Systematic version releases

Version Strategy (Semantic Versioning):

code

MAJOR.MINOR.PATCH (e.g., 1.5.3)

MAJOR: Breaking changes
MINOR: New features (backward compatible)
PATCH: Bug fixes

Examples:
- 1.0.0 → 2.0.0 (major breaking change)
- 1.0.0 → 1.1.0 (new feature)
- 1.0.0 → 1.0.1 (bug fix)

Release Workflow:

•
Planning
- •Define features/fixes for release
- •Set target release date
- •Plan migration path if needed
•
Development
- •Feature branches with pull requests
- •Automated testing on all PRs
- •Code review requirements
•
Staging
- •Deploy to staging environment
- •Run full test suite
- •Performance/load testing
- •Stakeholder approval
•
Release
- •Create version tag
- •Build and push artifacts
- •Update changelog
- •Deploy to production
- •Announce release
•
Post-Release
- •Monitor metrics
- •Gather user feedback
- •Plan hotfixes if needed
- •Document lessons learned

Common Patterns

GitHub Actions Workflow Template

yaml

name: Release
on:
  workflow_dispatch:  # Manual trigger
    inputs:
      version:
        description: 'Release version'
        required: true

jobs:
  release:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      
      - name: Create tag
        run: |
          git tag ${{ github.event.inputs.version }}
          git push origin ${{ github.event.inputs.version }}
      
      - name: Build artifacts
        run: npm run build
      
      - name: Create release
        uses: actions/create-release@v1
        with:
          tag_name: ${{ github.event.inputs.version }}
          release_name: Release ${{ github.event.inputs.version }}
      
      - name: Deploy to production
        run: npm run deploy:prod

Canary Deployment with Monitoring

yaml

name: Deploy with Canary
jobs:
  deploy:
    steps:
      - name: Deploy canary (10%)
        run: kubectl set image deploy/app app=myapp:${{ github.sha }} --record
      
      - name: Wait and monitor
        run: |
          for i in {1..5}; do
            ERROR_RATE=$(curl https://metrics/error_rate)
            if [ $ERROR_RATE -gt 1 ]; then
              echo "High error rate detected: $ERROR_RATE"
              kubectl rollout undo deploy/app
              exit 1
            fi
            sleep 60
          done
      
      - name: Full rollout (100%)
        run: kubectl set image deploy/app app=myapp:${{ github.sha }}

Quality Checklist

Best Practices

•Automate Everything - Minimize manual steps
•Test Before Deploy - Comprehensive automated testing
•Environment Parity - Staging mirrors production
•Fast Feedback - CI/CD completes in < 10 minutes
•Observable - Logs, metrics, traces for troubleshooting
•Documented - Playbooks for common scenarios
•Gated - Approval gates for production changes
•Measurable - DORA metrics (deployment frequency, lead time, MTTR, change failure rate)