CI/CD concepts and choosing a platform
Integration, delivery and deployment, pipeline as code, runners and agents, hosted versus self-hosted, and how GitHub Actions, GitLab CI, Jenkins and CircleCI compare.
Three terms that are not interchangeable
| Term | Means | Requires |
|---|---|---|
| Continuous integration | Every change is merged and verified automatically | Fast tests, a green default branch |
| Continuous delivery | Every green build is deployable on demand | Automated build and a deployment mechanism |
| Continuous deployment | Every green build goes to production automatically | Strong tests, canaries, fast rollback |
| Pipeline as code | The process lives in the repository | Review and versioning like any other code |
Most teams want continuous delivery, not deployment. The difference is a deliberate manual gate before production — not a lack of automation, but a decision about who accepts the risk.
Runners and agents
# hosted: the platform provides an ephemeral machine
jobs:
test:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- run: npm ci && npm test
# self-hosted: you provide the machine and its maintenance
jobs:
build-arm:
runs-on: [self-hosted, linux, arm64]
steps:
- uses: actions/checkout@v4
- run: docker build -t app:latest-arm64 .
# a runner group with labels lets you route by capability
deploy:
runs-on: [self-hosted, linux, prod-network]- Hosted runners are ephemeral, so nothing leaks between jobs and every job starts from a known image.
- Self-hosted runners are necessary for private networks, special hardware, or a large and consistent build cache.
- Never attach a self-hosted runner to a public repository: an untrusted pull request can run arbitrary code on your machine.
- Match runner capacity to your longest queue. A pipeline that waits twenty minutes for a runner has a capacity problem, not a slow test problem.
Comparing the platforms
| Platform | Strength | Watch out for |
|---|---|---|
| GitHub Actions | Huge ecosystem, matrix and reusable workflows | Third-party actions are a supply-chain risk |
| GitLab CI | Integrated with the repo, excellent environments and review apps | Runner administration is your job |
| Jenkins | Extremely flexible, runs anywhere | You maintain plugins, upgrades and security |
| CircleCI | Fast, good parallelism and caching | Cost scales with concurrency |
💡
Pick the platform that lives next to your code and your review process. A pipeline that is one file in the same repository, reviewed like code, beats a more powerful system that lives in a separate tool nobody wants to touch.
FAQ
How long should a pipeline take?
Under ten minutes for the feedback that gates a merge. Split work into fast checks that run on every commit and slow suites that run on a schedule or before release.
Do I need a build server for a small team?
Not necessarily. A hosted platform with a couple of workflow files covers most small projects. Self-hosting only pays once you need private network access, unusual hardware, or a very large cache.
Related
Triggers, concurrency and matrix builds Observability and speeding up slow pipelines
Last refreshed 2026-09-18.