CI/CD Pipeline Tool Selection

{
  "_meta": {
    "schema": "https://www.drawdecisiontree.com/decision-dag.schema.json",
    "source": "https://www.drawdecisiontree.com",
    "description": "DrawDecisionTree.com is a free tool for building, sharing, and embedding interactive decision trees. This file is the machine-readable export of a published decision tree. The `dsl` field contains the original source in the Decision DAG DSL; the `dag` schema is documented at the URL in `schema` above.",
    "links": {
      "interactive": "https://www.drawdecisiontree.com/t/drawdecisiontree/ci-cd-pipeline.html",
      "embed": "https://www.drawdecisiontree.com/embed/path/drawdecisiontree/ci-cd-pipeline",
      "dsl_reference": "https://www.drawdecisiontree.com/decision-tree-dsl-reference.html",
      "guides": "https://www.drawdecisiontree.com/guides",
      "schema_docs": "https://www.drawdecisiontree.com/decision-dag.schema.json",
      "author_trees": "https://www.drawdecisiontree.com/trees/drawdecisiontree"
    },
    "generated_at": "2026-05-29T12:05:39.254Z"
  },
  "author": {
    "handle": "drawdecisiontree",
    "first_name": "Andrew",
    "last_name": null,
    "avatar_url": "1d32d828-b6ca-40ec-bdd7-771fe7b9c36a/avatar-1778531481027.svg",
    "display_name": "Andrew"
  },
  "file": {
    "id": "98b2a22f-f060-4467-a134-3a6f5bdad28f",
    "name": "CI/CD Pipeline Tool Selection",
    "public_slug": "ci-cd-pipeline",
    "updated_at": "2026-05-12T16:53:43.587978+00:00",
    "url": "https://www.drawdecisiontree.com/t/drawdecisiontree/ci-cd-pipeline.html",
    "json_url": "https://www.drawdecisiontree.com/t/drawdecisiontree/ci-cd-pipeline/tree.json",
    "dsl_url": "https://www.drawdecisiontree.com/t/drawdecisiontree/ci-cd-pipeline/tree.dag"
  },
  "meta": {
    "description": "Choosing a CI/CD platform is a long-term infrastructure commitment — pipelines accumulate config, custom scripts, and team muscle memory that make switching painful. This tree eliminates tools that don't fit your source control host, infrastructure model, or team scale, leaving only the options genuinely viable for your situation.",
    "mode": "elimination",
    "entry": "Q1",
    "tags": [
      "devops",
      "ci/cd",
      "automation",
      "infrastructure",
      "engineering"
    ],
    "image": "https://images.unsplash.com/photo-1618401471353-b98afee0b2eb?w=1200&q=80"
  },
  "questions": [
    {
      "id": "Q1",
      "text": "Where is your primary source code hosted?"
    },
    {
      "id": "A",
      "text": "GitHub [GITHUB-ACTIONS, JENKINS, CIRCLE-CI, BUILDKITE]"
    },
    {
      "id": "B",
      "text": "GitLab [GITLAB-CI, JENKINS, CIRCLE-CI, BUILDKITE]"
    },
    {
      "id": "C",
      "text": "Bitbucket or another SCM [JENKINS, CIRCLE-CI, BUILDKITE]"
    },
    {
      "id": "Q2",
      "text": "Must build agents run on your own infrastructure — on-premise servers or VMs in your own cloud account?"
    },
    {
      "id": "A",
      "text": "YES — agents must run on our own servers or VMs [GITHUB-ACTIONS, JENKINS, GITLAB-CI, BUILDKITE]"
    },
    {
      "id": "B",
      "text": "NO — fully managed cloud agents are acceptable [GITHUB-ACTIONS, GITLAB-CI, CIRCLE-CI, BUILDKITE]"
    },
    {
      "id": "Q3",
      "text": "Do you have a dedicated DevOps or platform engineering team to own CI/CD infrastructure?"
    },
    {
      "id": "A",
      "text": "YES — dedicated team, complex pipelines, enterprise scale [JENKINS, BUILDKITE, GITHUB-ACTIONS, GITLAB-CI]"
    },
    {
      "id": "B",
      "text": "NO — small team, developers own their own pipelines, simplicity matters [GITHUB-ACTIONS, GITLAB-CI, CIRCLE-CI]"
    }
  ],
  "outcomes": [
    {
      "id": "JENKINS",
      "label": "Jenkins"
    },
    {
      "id": "BUILDKITE",
      "label": "Buildkite"
    }
  ],
  "dsl": "dag: CI/CD Pipeline Tool Selection\nversion: 1.0.0\nimage: https://images.unsplash.com/photo-1618401471353-b98afee0b2eb?w=1200&q=80\ndescription: Choosing a CI/CD platform is a long-term infrastructure commitment — pipelines accumulate config, custom scripts, and team muscle memory that make switching painful. This tree eliminates tools that don't fit your source control host, infrastructure model, or team scale, leaving only the options genuinely viable for your situation.\ntags: devops, ci/cd, automation, infrastructure, engineering\nentry: Q1\nmode: elimination\n\nQ1: Where is your primary source code hosted?\n  hint: Choose the platform where the majority of your repositories live. If you use multiple SCMs, pick the one hosting your most business-critical pipelines.\n  A: GitHub [GITHUB-ACTIONS, JENKINS, CIRCLE-CI, BUILDKITE]\n  B: GitLab [GITLAB-CI, JENKINS, CIRCLE-CI, BUILDKITE]\n  C: Bitbucket or another SCM [JENKINS, CIRCLE-CI, BUILDKITE]\n\nQ2: Must build agents run on your own infrastructure — on-premise servers or VMs in your own cloud account?\n  hint: Self-hosted agents are required when builds need access to internal network resources, air-gapped environments, or compliance mandates prohibit source code leaving your own infrastructure. If cloud-managed agents behind a VPN tunnel are acceptable, answer No.\n  A: YES — agents must run on our own servers or VMs [GITHUB-ACTIONS, JENKINS, GITLAB-CI, BUILDKITE]\n  B: NO — fully managed cloud agents are acceptable [GITHUB-ACTIONS, GITLAB-CI, CIRCLE-CI, BUILDKITE]\n\nQ3: Do you have a dedicated DevOps or platform engineering team to own CI/CD infrastructure?\n  hint: Jenkins and Buildkite are powerful but operationally heavy — they reward teams who can invest time in plugin management, agent auto-scaling, and pipeline observability. If CI/CD is owned by developers alongside their product work, a lower-overhead option will serve better long-term.\n  A: YES — dedicated team, complex pipelines, enterprise scale [JENKINS, BUILDKITE, GITHUB-ACTIONS, GITLAB-CI]\n  B: NO — small team, developers own their own pipelines, simplicity matters [GITHUB-ACTIONS, GITLAB-CI, CIRCLE-CI]\n\n[GITHUB-ACTIONS]: GitHub Actions\n  color: #24292E\n  description: GitHub Actions is the obvious choice for GitHub-hosted repositories — it is deeply integrated into the GitHub UI, pull request checks, and security features like Dependabot and code scanning. Workflows are defined in YAML files committed alongside your code, making pipeline-as-code frictionless from day one. The free tier is generous (2,000 minutes/month for private repositories), and the GitHub Marketplace provides thousands of pre-built Actions for common tasks. Self-hosted runners extend Actions to on-premise or cloud VMs with minimal configuration, satisfying both managed and self-hosted requirements. The ecosystem lock-in is real — Actions YAML syntax does not translate to other platforms — but for teams already on GitHub, the integration depth and zero-ops model is unmatched.\n  code: CICD_GITHUB_ACTIONS\n\n[JENKINS]: Jenkins\n  color: #D33833\n  description: Jenkins is the most battle-tested CI/CD engine in the industry — it integrates with virtually any tool, SCM, or deployment target through its plugin ecosystem of over 1,800 plugins. Its declarative and scripted Pipeline DSL (Groovy-based) supports arbitrarily complex build graphs, parallel stages, and shared library abstractions. Jenkins is the right choice for large enterprises with existing investment, air-gapped environments, or workloads requiring deep customisation of the build environment. The trade-off is substantial operational overhead: managing plugin versions, security patching, agent provisioning, and pipeline library maintenance requires dedicated staff. For new greenfield projects without existing Jenkins investment, modern alternatives offer a far better developer experience with less ops burden.\n  code: CICD_JENKINS\n\n[GITLAB-CI]: GitLab CI/CD\n  color: #FC6D26\n  description: GitLab CI/CD is tightly integrated with the GitLab platform — pipelines are defined in a single `.gitlab-ci.yml` file and run automatically on every push, merge request, and tag. It provides a complete DevSecOps platform out of the box: container registry, dependency scanning, SAST, DAST, and deployment environments are all first-class features. GitLab offers both a SaaS version (GitLab.com) and a fully self-managed option, making it viable for air-gapped or compliance-sensitive environments. For organisations already on GitLab, using GitLab CI/CD eliminates the need for a separate CI system entirely. The runner architecture is flexible — shared, group-level, and project-specific runners can coexist and execute jobs in Docker, Kubernetes, or directly on bare metal.\n  code: CICD_GITLAB_CI\n\n[CIRCLE-CI]: CircleCI\n  color: #343434\n  description: CircleCI is a high-performance SaaS CI/CD platform known for fast feedback loops and a clean developer experience. Its resource class system lets you right-size compute for each job — from small Docker containers to GPU-enabled large machines — and Docker Layer Caching dramatically reduces build times for containerised workloads. CircleCI's orbs (reusable config packages) eliminate boilerplate for common integrations with AWS, Slack, test reporters, and deployment targets. It works natively with GitHub and Bitbucket and is a strong choice for product-focused teams that want a polished managed platform without operating build infrastructure. Pricing is compute-credit based, which scales predictably but can become expensive at very high build volumes compared to self-hosted alternatives.\n  code: CICD_CIRCLECI\n\n[BUILDKITE]: Buildkite\n  color: #14CC80\n  description: Buildkite is a hybrid CI/CD platform: the coordination layer — scheduling, UI, secrets, and analytics — runs as a managed SaaS service, while the actual build agents run on your own infrastructure — any cloud provider, on-premise servers, ARM machines, or GPU hardware. This gives you the operational simplicity of a managed control plane with the flexibility and data sovereignty of self-hosted execution. Buildkite scales exceptionally well for large engineering organisations — Shopify, Airbnb, and Stripe run it at significant scale. Its pipeline configuration is minimal YAML or even dynamic (pipelines generated at runtime from a script), and the agent model makes autoscaling straightforward using AWS Auto Scaling Groups, GKE node pools, or your own orchestration. It is the right choice when self-hosted execution is required but you want to avoid the full operational complexity of Jenkins.\n  code: CICD_BUILDKITE\n"
}