Skip to content
Back to glossary
Software Delivery

What is CI/CD (Continuous Integration / Continuous Delivery)?

CI/CD is the automated pipeline that builds, tests and deploys code on every change, turning releases into a routine, repeatable operation.

What CI and CD actually mean

The two letters are often confused. CI (Continuous Integration) is the discipline of merging every developer's work into a shared branch many times a day, with automated builds and tests catching conflicts within minutes. CD (Continuous Delivery) extends that discipline to the deployment side: every commit that passes CI produces an artefact ready to ship to production. A stricter variant, Continuous Deployment, removes the manual approval and ships every passing commit automatically.

The trio CI + CD lives inside a pipeline: a graph of automated steps triggered by code changes, typically running in a hosted runner and managed from your Git provider (GitLab CI, GitHub Actions, Jenkins, ArgoCD).

What a pragmatic pipeline looks like

In a healthy production setup we'd typically deploy:

  1. Lint + format : fast static checks that catch typos and style issues in seconds.
  2. Build : compile, package, produce a container image with a deterministic tag.
  3. Unit tests : run in parallel, fail fast.
  4. Security scans : SAST on the source, container vulnerability scan on the image.
  5. Push artefact : to a registry tagged with the commit SHA.
  6. Deploy to staging : automatic, with smoke tests against the deployed version.
  7. Deploy to production : gated by a human approval, or automatic for low-risk services.
  8. Post-deploy verification : synthetic monitoring confirms the new version answers correctly.

The whole sequence usually finishes in 5–15 minutes for a typical web app. Slower pipelines are a sign that tests are too coupled or builds are not cached.

Why it matters beyond developer convenience

CI/CD is the easiest way to reduce the change failure rate : one of the four DORA metrics. Each commit ships in isolation, so when something breaks, the cause is the last 50 lines of code, not the last quarter of work. Rollback is one button. Auditors get a chronological log of every change in production with the commit, the test result and the approver.

For regulated Swiss industries, a well-designed CI/CD pipeline is also the cleanest way to enforce the four-eyes principle: every change requires a reviewer's approval before merge, recorded forever in Git history.

Common anti-patterns

  • Pipelines that take 90 minutes : developers wait, batch their work, and the value of CI evaporates.
  • A single "deploy.sh" script run by one person : that's not CI/CD, it's a bus factor of one.
  • Tests that fail randomly : also called flaky; teams disable them, then real bugs slip through.
  • Manual approvals for low-risk changes : bottlenecks that exist because no one trusts the tests.

Related Hidora services

  • Consulting : pipeline design, GitLab CI / GitHub Actions setup, training.
  • Managed Services : operating the runners, secrets and registry that CI/CD depends on.