starter.wiki

Developer Workflow

CI/CD

Choose pipeline automation by repository alignment, execution ownership, trust boundary, and operating burden.

Recommendation

Use GitHub Actions for an ordinary GitHub-hosted application.

Change the route for GitLab consolidation, customer-controlled execution at scale, or a Jenkins estate whose migration cost is higher than its current operating burden.12

For: Application and platform teams establishing or replacing continuous integration and delivery automation

Main trade-off

Managed pipeline control reduces setup while transferring workflow state, secrets, caches, artifacts, concurrency, and usage economics to the platform; self-operation preserves control but creates infrastructure and upgrade work.1234

Choose by control plane and execution ownership

Workflow syntax matters less than where trust, runners, artifacts, and operating responsibility live.

  1. Trust boundary

    Define who can change workflows, access secrets, approve deployment, and execute untrusted contributions.12

  2. Runner model

    Choose hosted, self-hosted, hybrid, ephemeral, privileged, platform-specific, and specialized hardware execution deliberately.3

  3. Workflow state

    Model caches, artifacts, provenance, logs, retries, concurrency, approvals, environments, retention, and recovery.12

  4. Economics and operations

    Include usage, queueing, idle capacity, egress, storage, runner maintenance, plugins, upgrades, and incident ownership.12

Pipeline routes

Keep the repository-native default bounded and preserve explicit hybrid and self-operated exceptions.

The application source is governed on GitHub

Start with GitHub Actions.

GitHub Actions is the repository-native default when workflow events, permissions, reviews, and automation already live on GitHub.

Verify: Model runner trust, usage, cache, artifact, secret, and deployment boundaries before treating adjacency as sufficient.1

GitLab is the source and delivery platform

Evaluate GitLab CI/CD.

GitLab is the integrated route when repositories, pipelines, protected environments, and runners should share its platform boundary.

Verify: Verify hosted versus self-managed runners, upgrade ownership, quotas, and the wider GitLab commitment.2

Execution must stay on customer-controlled infrastructure

Evaluate Buildkite.

Buildkite is the hybrid route when a managed control plane should coordinate customer-operated agents and specialized build infrastructure.

Verify: The team still owns agent security, capacity, networking, images, updates, queues, and failure recovery.3

An established Jenkins estate has material migration cost

Retain or modernize Jenkins deliberately.

Jenkins remains the self-operated exception when existing jobs, plugins, infrastructure, and organizational knowledge outweigh migration benefits.

Verify: Do not select a new Jenkins estate without accepting controller, plugin, credential, agent, backup, availability, and upgrade ownership.4

Boundary: Testing owns what should be verified, Git Repository Hosting owns source collaboration, Preview Environments owns review-instance lifecycle, and Hosting owns the production runtime.

Official resources

Verify current product boundaries, control-plane behavior, execution limits, pricing, licensing, and operating requirements in first-party material before adoption.

Sources

Official product material supports the bounded routes and verification points; route selection remains an editorial judgment.

  1. 1
    GitHub Actions overview

    GitHub · Accessed Official

  2. 2
    GitLab CI/CD documentation

    GitLab · Accessed Official

  3. 3
    Buildkite pipelines documentation

    Buildkite · Accessed Official

  4. 4
    Jenkins documentation

    Jenkins · Accessed Official

  5. 5
    GitHub Actions billing

    GitHub · Accessed Official

  6. 6
    Buildkite pricing

    Buildkite · Accessed Official