DevOps Dictionary

CI/CD Pipeline stands for Continuous Integration and Continuous Delivery, or sometimes Continuous Deployment. It is an automated workflow that takes code changes through build, test, security, packaging, and release steps so teams can ship software in a repeatable and controlled way.

A CI/CD pipeline helps developers find problems early, reduce manual release work, and move changes from a source code repository to production or another target environment with clear checks along the way.

What a CI/CD pipeline does

A CI/CD pipeline automates the steps that usually happen after a developer commits code. Common tasks include:

• Building the application: compiling code, resolving dependencies, and creating deployable artifacts.
• Running tests: executing unit tests, integration tests, end-to-end tests, and smoke tests.
• Checking code quality: running linters, formatters, static analysis, and policy checks.
• Scanning for security issues: checking dependencies, container images, secrets, and infrastructure definitions.
• Packaging artifacts: producing binaries, container images, Helm charts, or deployment bundles.
• Deploying changes: promoting releases to development, staging, production, or other environments.
• Recording results: storing logs, test reports, build metadata, and deployment history.

How it works

A pipeline usually starts when a developer opens a pull request, merges code, pushes a Git tag, or triggers a manual release. The CI/CD system then runs a defined set of jobs in order or in parallel.

A typical flow looks like this:

1. A developer commits code to a Git repository.
2. The pipeline checks out the code and installs dependencies.
3. The application is built and tested.
4. The pipeline runs quality and security checks.
5. If checks pass, the pipeline creates a versioned artifact, such as a container image.
6. The artifact is deployed to a test environment.
7. After approval or automated promotion, the same artifact is deployed to production.

CI/CD pipelines are commonly defined as code in files stored with the application, such as .github/workflows for GitHub Actions, .gitlab-ci.yml for GitLab CI/CD, or pipeline files for Jenkins, Azure DevOps, CircleCI, and Buildkite.

Continuous integration, delivery, and deployment

The acronym can be confusing because CI/CD combines related but distinct practices:

• Continuous Integration: developers merge code frequently, and each change is automatically built and tested.
• Continuous Delivery: code is always kept in a releasable state, but production deployment usually requires a manual approval.
• Continuous Deployment: every change that passes the required checks is automatically deployed to production.

Many teams use continuous integration and continuous delivery before moving to full continuous deployment. Production systems often require approvals, maintenance windows, compliance checks, or staged rollouts.

Key parts of a CI/CD pipeline

• Source control: usually Git, where code, configuration, and pipeline definitions are stored.
• Runner or agent: the machine or container that executes pipeline jobs.
• Jobs and stages: individual tasks grouped into phases such as build, test, scan, and deploy.
• Artifacts: outputs created by the pipeline, such as binaries, reports, or container images.
• Artifact registry: storage for build outputs, such as Docker Hub, Amazon ECR, Google Artifact Registry, Azure Container Registry, or Nexus.
• Secrets management: secure handling of tokens, credentials, signing keys, and deployment access.
• Deployment targets: environments such as virtual machines, Kubernetes clusters, serverless platforms, or managed application services.
• Approvals and gates: manual or automated controls used before sensitive steps, especially production releases.

Common use cases

• Running tests for every pull request before merge.
• Building and publishing container images after changes land on the main branch.
• Deploying a web service to a staging environment for validation.
• Promoting a tested release to production after approval.
• Applying infrastructure changes with tools such as Terraform or Pulumi.
• Rolling out Kubernetes workloads using Helm, Kustomize, or GitOps tools.
• Scanning application dependencies and container images for known vulnerabilities.

Benefits

• Faster feedback: developers learn quickly when a change breaks tests or violates a policy.
• More consistent releases: the same steps run every time, reducing manual mistakes.
• Better traceability: teams can see which commit, artifact, and deployment belong to a release.
• Smaller changes: frequent releases usually mean fewer changes per deployment, which can make failures easier to diagnose.
• Stronger controls: automated checks can enforce security, compliance, and operational requirements before deployment.

Tradeoffs and limitations

A CI/CD pipeline is only as useful as the checks it runs and the discipline behind it. A fast pipeline with weak tests can still ship broken code. A pipeline with too many slow steps can delay developers and encourage workarounds.

Common challenges include:

• Flaky tests: unreliable tests reduce trust in the pipeline.
• Slow builds: long feedback loops can slow delivery.
• Secret exposure: poor credential handling can leak sensitive access.
• Environment drift: differences between staging and production can hide release problems.
• Overly broad permissions: build agents with too much access can increase security risk.
• Complex rollback paths: automated deployment does not remove the need for recovery planning.

Simple example

A team maintains a Node.js API in GitHub and deploys it to Kubernetes. When a developer opens a pull request, the pipeline installs dependencies, runs unit tests, checks formatting, and scans dependencies. If the pull request is merged, the pipeline builds a Docker image, tags it with the commit SHA, pushes it to a registry, and deploys it to staging.

After smoke tests pass in staging, a release manager approves the production deployment. The pipeline then updates the Kubernetes deployment to use the same image that was tested in staging. If errors increase after release, the team can roll back to the previous image tag.

CI/CD pipeline vs. release pipeline

A release pipeline usually focuses on promoting a prepared artifact through environments. A CI/CD pipeline is broader. It often includes source checkout, build, test, scan, packaging, release approval, deployment, and post-deployment checks.

In practice, many teams use the terms loosely. The important distinction is whether the workflow covers the full path from code change to deployment, or only the release and promotion steps.