CI/CD Pipeline Maturity: From Scripts to GitOps

The Deployment Bottleneck

Your best engineer asks for a production deploy. It takes 3 days, involves 5 people, and requires a change advisory board meeting.

Meanwhile, your competitor ships 50 times a day.

This Wardley map shows you where your CI/CD pipeline sits and how to evolve toward continuous deployment.

Reading the Map

The Deployment Value Chain

High Visibility (What the business cares about):

Feature Velocity (0.95) - Speed of shipping
Deployment Frequency (0.90) - How often you deploy
Automated Testing (0.85) - Confidence in changes
Code Review (0.80) - Quality gate

Infrastructure (What enables deployment):

Version Control (0.35) - Git (commodity)
Test Framework (0.40) - Jest/pytest (commodity)
CI Runner (0.45) - Build agents (commodity)
Artifact Storage (0.50) - Docker registries (commodity)

Evolution Insights

Commodity (75-100%): Use Standard Tools

Version Control (0.95) - Git is the standard
Test Framework (0.90) - Jest, pytest, JUnit
Cloud API (0.90) - AWS/GCP/Azure
CI Runner (0.85) - K8s jobs, GitHub runners
Artifact Storage (0.85) - ECR, Docker Hub
CI/CD Platform (0.80) - GitHub Actions winning
Config Management (0.80) - Secrets managers

Product (50-75%): Buy or Adopt

Automated Testing (0.75) - Testing patterns are standard
Rollback Capability (0.75) - Deployment tools handle this
Infrastructure as Code (0.70) - Terraform is standard
Code Review (0.70) - PR workflows are standard
Deployment Frequency (0.70) - Continuous deployment is proven
Deployment Automation (0.65) - Tools exist, configuration is custom

Custom (25-50%): This Is Your Advantage

Feature Flags (0.55) - How you use flags is custom
Feature Velocity (0.65) - Your process, your culture

Genesis (0-25%): Kill Now

Manual Deploys (0.05) - Destroying your velocity

Strategic Decisions

Decision 1: Kill Manual Deploys Immediately

If you have manual deploys (0.05 evolution, high inertia), this is your #1 priority. Not next quarter. This month.

Why manual deploys kill you:

Deployment fear → Lower frequency → Bigger batches → More risk
Bus factor = 1 (only Bob knows how to deploy)
Weekends and nights (deployments become scary events)
Slow feedback (takes days to know if a change works)

Migration plan (4 weeks):

Week 1: Document current manual process
Week 2: Script it (Bash/Python)
Week 3: Move script to GitHub Actions
Week 4: Make it automatic on merge to main

Decision 2: GitHub Actions vs Jenkins vs GitLab CI

CI/CD Platform is at 0.80 evolution - firmly commodity. Don't overthink this.

GitHub Actions (Recommended):

✅ Built into GitHub (0 setup)
✅ Free for public repos, generous private limits
✅ Best DX (YAML-based, easy to iterate)
✅ Huge marketplace of actions
❌ Less powerful than Jenkins (but 90% don't need that power)

GitLab CI:

✅ Integrated with GitLab
✅ Strong CI/CD features
❌ Requires GitLab (switching cost)

Jenkins:

✅ Maximum flexibility
❌ Operational burden (need to run Jenkins cluster)
❌ Slow to iterate (Groovy pipelines are painful)
⚠️ Only use if you have specific requirements GitHub Actions can't meet

CircleCI/TravisCI/Etc:

⚠️ Niche benefits, not worth the switching cost if you're on GitHub

Decision 3: Feature Flags - Build vs Buy

Feature Flags sit at 0.55 evolution - right in the "Product" zone. You have options.

When to build:

Simple boolean flags (environment variables work)
Under 10 flags total
No targeting needs (all users get same experience)

When to buy:

Percentage rollouts (5% → 25% → 100%)
User targeting (enable for beta users)
A/B testing (variant assignment)
Kill switches (instant rollback)
Over 10 flags or complex rules

Good products:

Cheap/Simple: Unleash (self-hosted, free)
Mid-Tier: Split ($1500/month), GrowthBook ($20-200/month)
Enterprise: LaunchDarkly ($9K/year+), Optimizely

Roll your own starter:

# Simple flag service (good enough for many teams)
FLAGS = {
    "new_checkout": {"enabled": True, "rollout": 0.25},
    "ai_search": {"enabled": False, "rollout": 0.0},
}

def is_enabled(flag_name, user_id=None):
    flag = FLAGS.get(flag_name, {"enabled": False})
    if not flag["enabled"]:
        return False
    if user_id and flag.get("rollout", 1.0) < 1.0:
        return hash(f"{flag_name}:{user_id}") % 100 < flag["rollout"] * 100
    return True

This gets you 80% of the value at 1% of the cost.

The Four Stages of CI/CD Maturity

Stage 1: Manual Chaos (Genesis)

Deployment: SSH to server, git pull, restart
Testing: "Works on my machine"
Frequency: Weekly at best, often monthly
Recovery: Hope and prayer

If you're here: Drop everything, get to Stage 2

Stage 2: Scripted Deploys (Custom)

Deployment: Bash script that SSH's and runs commands
Testing: Some unit tests, run before pushing
Frequency: Daily
Recovery: Re-run script with old version

If you're here: Good start, automate the script

Stage 3: Continuous Integration (Product)

Deployment: GitHub Actions runs tests, builds artifacts, deploys on approval
Testing: Unit + integration tests, required before merge
Frequency: Multiple times per day
Recovery: Revert PR, re-deploy

If you're here: You're doing well, add feature flags

Stage 4: Continuous Deployment (Commodity)

Deployment: Merge to main → automatic production deploy
Testing: Unit + integration + e2e, automated
Frequency: 10-50+ times per day
Recovery: Feature flags kill switch, or automatic rollback

If you're here: You're in the top 10% of engineering teams

Dependency Analysis

Critical Path: Code to Production

Feature Velocity → Deployment Frequency → Deployment Automation → CI/CD Platform → Version Control

Key insight: Your deployment frequency depends on automation, which depends on a commodity (CI/CD platform). This is good!

Actionable: If your deployment automation is slow, it's probably not the CI/CD platform—it's your deployment process. Look at IaC, database migrations, or manual approval gates.

Critical Path: Quality

Feature Velocity → Automated Testing → Test Framework

Key insight: Test frameworks are commodity (0.90 evolution). If testing is slow, it's not Jest—it's your test design.

Actionable: Parallelize tests, use test doubles, reduce integration test count.

Common Patterns

Pattern 1: Trunk-Based Development

main branch (always deployable)
   ↓
Feature flag OFF → Deploy → Feature flag ON

Fastest cycle time (no long-lived branches)
Requires feature flags
Requires strong testing
Recommended for teams > 5 engineers

Pattern 2: GitHub Flow

feature branch → PR → Review → Merge → Deploy

Simpler than GitFlow
Good for teams under 10
Deploy on merge to main (continuous deployment)

Pattern 3: GitOps

Git repo (infrastructure state)
   ↓
Argo CD / Flux watches
   ↓
Applies to Kubernetes

Declarative infrastructure
Git as source of truth
Automatic drift correction
Overkill for small teams, perfect for large teams

Cost Optimization

GitHub Actions Costs

Free tier:

2,000 minutes/month (public repos unlimited)
Good for teams under 5

Paid:

$0.008/minute (Linux)
$0.016/minute (Windows)
$0.064/minute (macOS)

Optimization:

Cache dependencies (saves 2-5 minutes per build)
Use matrix builds (parallelize)
Self-hosted runners (free compute, you manage infrastructure)

Example:

50 deploys/day × 5 minutes × 30 days = 7,500 minutes
Linux: 7,500 × $0.008 = $60/month
Self-hosted: $0 compute + $50 ops time = $50/month equivalent

Feature Flag Costs

LaunchDarkly:

$9K/year (starter, 1000 MAU)
$40K+/year (enterprise)

Unleash (self-hosted):

Free (open source)
$100-200/month operational costs

DIY:

Engineering: 2-4 weeks ($10K-20K one-time)
Operational: Negligible

Recommendation: Start DIY, move to Unleash at scale, LaunchDarkly for enterprise

Movement Recommendations

Immediate (Next 30 Days)

Automate deploys: If manual, script it and run from CI
Add automated tests: Start with smoke tests
Enable branch protection: Require CI to pass before merge
Document rollback: Write the runbook

Short-Term (Next 6 Months)

Continuous deployment: Merge to main = production
Feature flags: Add for risky changes
Deployment metrics: Track DORA metrics (deploy frequency, lead time, MTTR, change failure rate)
Test coverage: Aim for 80% unit test coverage

Long-Term (12+ Months)

Progressive delivery: Canary deploys, percentage rollouts
Automatic rollback: Detect failures, auto-revert
GitOps: Infrastructure as code, automatic sync
Platform engineering: Internal deployment platform

How to Use This Map

Assess current state: Where are you? (Stage 1-4)
Identify blockers: Manual deploys? No tests? Slow CI?
Plan evolution: Move components right (toward commodity)
Set metrics: Track deploy frequency and lead time
Iterate weekly: Small improvements compound

Remember: The goal isn't "perfect CI/CD." It's fast feedback and safe deployments that let you ship with confidence.