The Enterprise CI/CD Landscape¶

Estimated time: 17 min read · Part: CI/CD Foundations

The Major Platforms¶

Enterprises run a range of CI/CD platforms. The differences that matter in consulting are hosting model (SaaS vs. self-hosted), ecosystem integration, and extensibility. You will rarely get to choose the tool — the question is how to make the best use of what exists, and when to recommend a migration.

SaaS Runners vs. Self-Hosted Runners¶

The runner placement decision is one of the most consequential in enterprise CI/CD architecture. A SaaS-hosted runner (GitHub's ubuntu-latest, CircleCI's cloud executors) runs on the platform vendor's infrastructure — you get a fresh, ephemeral environment with no maintenance overhead. A self-hosted runner is software you install on your own machines; it makes an outbound connection to the CI control plane and polls for jobs, so no inbound firewall hole is needed.

Migration Discussions: Jenkins to Modern Platforms¶

Many enterprises still run Jenkins, often installed years ago by a team that has since moved on. Jenkins is powerful but carries significant operational overhead: the JVM, plugin management, plugin compatibility issues, and a Groovy-based DSL that has a steep learning curve. When a client asks about migrating to GitHub Actions or GitLab CI, the conversation is strategic, not syntactic.

// A typical Jenkins Declarative Pipeline — Groovy-based
pipeline {
    agent any
    stages {
        stage('Install') {
            steps {
                sh 'pip install -r requirements.txt'
            }
        }
        stage('Test') {
            steps {
                sh 'pytest tests/ --junitxml=results.xml'
            }
        }
    }
    post {
        always {
            junit 'results.xml'
        }
    }
}

WHY platform diversity matters You will walk into clients running any of these tools. The consultant's value is platform-agnostic assessment and the ability to reason about trade-offs — not knowing every YAML key of every tool.

HOW five assessment questions Speed, test coverage, security scanning, deployment safety, runner placement. These five questions apply to any CI/CD platform and give you a complete picture of maturity and risk.

WHERE enterprise engagements Use the self-hosted runner conversation as a bridge to hybrid infrastructure (Part 12 and 13) — on-prem runners are often the first thing that surfaces when a client starts modernizing their CI/CD pipeline.

Assessment: GitLab CI → GitHub Actions for ACME Client

RUNNER STRATEGY
Current: GitLab runners self-hosted inside the data center.
GitHub Actions: Requires self-hosted runners for the same reasons —
builds must reach internal Harbor registry and K8s cluster.
Recommendation: Deploy GitHub Actions self-hosted runners inside the DC.
This is low-risk: runners make outbound connections only; no firewall changes.

REGISTRY INTEGRATION
Current: Harbor (internal) receives docker push from runners inside DC.
GitHub Actions: With self-hosted runners, docker push to Harbor works
identically. No change to Harbor configuration needed.

DEPLOYMENT ACCESS
Current: kubectl runs from inside DC via self-hosted runner.
GitHub Actions: Same — kubectl on the self-hosted runner reaches the
internal K8s API server. Alternatively, use a GitOps tool (Argo CD) that
pulls from the registry rather than being pushed to from CI.

SECURITY MODEL
Current: Credentials stored as GitLab CI/CD variables.
GitHub Actions: Secrets stored in GitHub repository/environment secrets.
For cloud deployments OIDC is available; for internal Harbor/K8s,
secrets stored as environment-scoped secrets in GitHub.
Risk: secrets leave the GitLab system; ensure GitHub org security policies
(SSO, secret scanning, branch protection) are configured before migration.

RECOMMENDATION
Migration is feasible with self-hosted runners. Primary benefit: GitHub
Actions has a larger marketplace and better developer ergonomics. Primary
cost: self-hosted runner maintenance (same as current GitLab runners, so
no net increase). Suggested approach: pilot on one non-critical service,
run both pipelines in parallel for 2 sprints, then cut over.