CI/CD Platforms
Continuous integration and delivery platforms - GitHub Actions and GitLab CI in depth, plus the broader landscape
CI/CD Platforms
Continuous integration runs your tests on every change. Continuous delivery automates building, packaging, and shipping that change toward production. A CI/CD platform is the place all of that happens — workflow definitions in code, runners executing them, secrets and credentials managed, deployment policies enforced.
CI vs CD vs Continuous Deployment
| Term | What it means |
|---|---|
| Continuous Integration (CI) | Every PR / push runs build + tests automatically |
| Continuous Delivery (CD) | Every passing main-branch build is ready to deploy; humans pull the trigger |
| Continuous Deployment | Every passing main-branch build is deployed automatically |
Most "CI/CD" stories really mean CI + Continuous Delivery. Full Continuous Deployment requires real test coverage, observability, and an org culture that's comfortable shipping many times a day.
The Players
This section focuses on GitHub Actions and GitLab CI — the two most widely used today, with sharply different models. The broader landscape:
| Platform | Notes |
|---|---|
| GitHub Actions | Tightly integrated with GitHub; huge marketplace; per-job runners; YAML in .github/workflows/ |
| GitLab CI | Built into GitLab; single .gitlab-ci.yml; first-class runners; strong DAG |
| CircleCI | SaaS; fast; mature; great for teams not on GitHub/GitLab |
| Jenkins | The granddaddy; self-hosted; infinite flexibility; high ops cost |
| Buildkite | Hybrid — your runners, their orchestration; popular at scale |
| Argo Workflows / Tekton | Kubernetes-native CI; pipelines as CRDs |
| Drone | Lightweight, container-native |
| AWS CodePipeline / Google Cloud Build / Azure DevOps | Cloud-managed CI/CD |
Learning Path
1. Getting Started
First workflow on each platform, runners, triggers, the basic build-test-deploy loop
2. GitHub Actions
Workflow syntax, matrix builds, OIDC, reusable workflows, self-hosted runners
3. GitLab CI
Pipeline syntax, stages vs needs (DAG), runners, parent/child pipelines
4. Best Practices
Speed, caching, security (OIDC, no long-lived secrets), pipeline design, deployment strategies
What a Good CI/CD Pipeline Looks Like
Regardless of platform, the shape is similar:
push / PR
│
▼
┌──────────────────────────────────────────────────────────────┐
│ CI: lint, test, build, scan (must be fast — < 10m) │
│ → produce an immutable artifact (container image, etc.) │
└──────────────────────────────────────────────────────────────┘
│ on green main
▼
┌──────────────────────────────────────────────────────────────┐
│ CD to staging │
│ → deploy, run smoke tests, automated checks │
└──────────────────────────────────────────────────────────────┘
│ on success (or after manual approval)
▼
┌──────────────────────────────────────────────────────────────┐
│ CD to production │
│ → progressive rollout (canary / blue-green) │
│ → automated rollback on SLO breach │
└──────────────────────────────────────────────────────────────┘The interesting properties:
- One immutable artifact flows from CI through every environment — staging and production deploy the same image.
- Configuration changes per environment, not artifacts.
- Promotion is automatic unless there's a real reason for human gate (production critical path = yes; staging = no).
- Rollback is a deploy, not an artifact change — point to the previous tag.
The Cross-Platform Principles
Whatever platform you pick:
| Principle | Why |
|---|---|
| Pipeline-as-code in the repo | Versioned with the code it builds; auditable |
| Pinned tool versions | Reproducible builds across time |
| Caching aggressively | Slow CI = slow iteration; slow iteration = bad code |
| No long-lived secrets in CI | OIDC → short-lived cloud credentials |
| Build once, deploy many | Same artifact across staging/prod |
| Pipelines as data, not logic | Move complex orchestration into scripts that humans can run too |
| Fast feedback first | Lint and unit tests in parallel; slow integration tests gate later |
The platform pages dig into how each does these. Best Practices ties them together.
CI/CD isn't separate from the rest of your platform — it pulls images from your registry, gets secrets from Vault, deploys via Kubernetes or your own runtime, and emits metrics via Prometheus. It's the glue.