CI/CD definition
CI/CD stands for continuous integration and continuous delivery or deployment, a set of automated practices for building, testing and releasing software. Continuous integration merges and tests every code change automatically. Continuous delivery keeps the code always ready to release, and continuous deployment pushes every passing change to production without manual steps.
How does a CI/CD pipeline work?
A pipeline is a sequence of automated stages defined as code in the repository, for example a GitHub Actions workflow or a GitLab CI file. It runs on every pull request and every merge, giving developers fast feedback and ensuring nothing reaches production without passing the same checks.
- Trigger: a commit or pull request starts the pipeline.
- Build: install dependencies and compile the application.
- Static checks: linting, type checks and security scans of code and dependencies.
- Tests: unit and integration tests, run in parallel where possible.
- Package: build a versioned artifact or container image and sign it.
- Deploy to staging and run end-to-end and smoke tests.
- Release to production, ideally gradually, with automatic rollback on errors.
- Monitor: watch error rates and key metrics after each release.
Continuous delivery vs continuous deployment
Both start with continuous integration. Continuous delivery means every change that passes the pipeline is ready to release, but a person decides when to push it to production, often with one click. Continuous deployment removes that step: every passing change goes live automatically. Deployment requires strong automated tests, monitoring and rollback, while delivery suits teams with regulatory approvals or scheduled releases, such as mobile apps that pass through app store review.
Popular CI/CD tools
Choose tools that fit where your code already lives. Teams on GitHub usually start with Actions, GitLab users with GitLab CI, and enterprises with complex needs sometimes keep Jenkins for its flexibility despite the maintenance it requires. Switching later is possible but costly.
- GitHub Actions and GitLab CI/CD: pipelines built into the code platform.
- Jenkins: highly extensible, self-hosted automation server.
- CircleCI, Buildkite and Bitbucket Pipelines: hosted or hybrid CI services.
- Azure Pipelines and AWS CodePipeline: cloud provider pipelines.
- Argo CD and Flux: GitOps-based deployment to Kubernetes.
- Fastlane and Expo EAS: build, sign and submit mobile apps.
CI/CD best practices
Speed matters most. If a pipeline takes an hour, developers batch changes and stop waiting for feedback. Cache dependencies, run tests in parallel, split slow end-to-end suites and quarantine flaky tests instead of retrying them forever. Integrate small changes into the main branch at least daily, using feature flags to hide unfinished work rather than long-lived branches.
Build an artifact once and promote that same artifact through staging to production, so what you tested is exactly what you release. Use short-lived credentials through OpenID Connect instead of storing long-lived cloud keys in the CI system, and protect the main branch with required checks and reviews.
Example: a web and mobile pipeline
A product team's pipeline lints and tests every pull request in a few minutes and deploys a preview environment for reviewers. Merging to main builds a container image, deploys it to staging, runs end-to-end tests and releases to production with a canary step. The mobile app's pipeline builds signed binaries, uploads them to TestFlight and Google Play internal testing, and ships JavaScript fixes over the air. Nexzem sets up pipelines like this for client projects from the first sprint.