CI/CD

How it works

CI/CD is a set of practices and automation that moves code changes from commit to running software. The abbreviation covers three related ideas.

Continuous Integration means developers merge small changes into a shared branch frequently, and every change triggers an automated build and test run. This avoids the “integration hell” of large, infrequent merges, because conflicts and breakages are found while they are still small.

Continuous Delivery means every change that passes the pipeline is kept in a releasable state, and a person decides when to release, often with an approval step. Continuous Deployment removes that manual step: every change that passes all checks goes to production automatically.

A typical pipeline has stages: checkout, build, unit tests, static analysis and security scans, packaging (for example a container image), deployment to a test environment, integration tests, and promotion to production. Pipelines are defined as code in the repository, using tools such as GitHub Actions, GitLab CI or Jenkins.

A practical example

A minimal GitHub Actions workflow that runs tests on every push and pull request:

name: ci
on:
  push:
    branches: [main]
  pull_request:

jobs:
  test:
    runs-on: ubuntu-latest
    steps: [{uses: actions/checkout@v4}, {run: npm ci}, {run: npm test}]

A delivery stage would add steps to build an image, push it to a registry and trigger a deployment.

Common mistakes

• Slow or flaky tests, which teach people to ignore failures or rerun until green.
• Building a different artefact for each environment instead of promoting one tested artefact.
• Storing credentials in the repository or in plain pipeline variables rather than a secrets manager.
• Giving pipelines broad production permissions that are never reviewed.
• Having no automated rollback or clear way to redeploy a previous version.
• Treating the pipeline as a one time setup rather than code that needs maintenance.

When to use it and when not to

Almost any team that ships software benefits from CI. Continuous deployment fits well where tests are trusted and changes are small and reversible. Where regulation or business risk demands sign off, continuous delivery with an approval gate is more appropriate. For Kubernetes, many teams separate CI (build and test) from deployment, which is handled by GitOps tooling.

Further reading: GitHub Actions, GitLab CI and Jenkins. See our CI/CD pipeline service.

See also

• GitHub Actions
• GitLab CI
• Jenkins
• GitOps