CI vs CD vs CD — The Three Terms
| Term | What it automates | Manual step? |
|---|---|---|
| Continuous Integration (CI) | Build + test on every commit | None — fully automated |
| Continuous Delivery (CD) | CI + prepare release artifact | Yes — human approves production deploy |
| Continuous Deployment (CD) | CI + auto-deploy to production | None — fully automated end-to-end |
Most teams start with CI + Continuous Delivery (human gate before production). Full Continuous Deployment requires very high test coverage and confidence in monitoring/rollback.
A Typical CI/CD Pipeline
If any stage fails, the pipeline stops and alerts the team. Code never reaches the next stage unless the current stage passes.
GitHub Actions — CI/CD in Practice
Popular CI/CD Tools Compared
| Tool | Hosted/Self-hosted | Best For | Cost |
|---|---|---|---|
| GitHub Actions | Hosted (GitHub) | GitHub repos, simple setup | Free tier available |
| GitLab CI/CD | Both | GitLab repos, full DevOps platform | Free tier available |
| Jenkins | Self-hosted | Enterprises, full customisation | Free (infra cost only) |
| CircleCI | Hosted | Fast builds, Docker-native | Free tier available |
| AWS CodePipeline | Hosted (AWS) | AWS-native deployments | Pay per use |
| Bitbucket Pipelines | Hosted (Atlassian) | Bitbucket repos, Jira integration | Free tier available |
CI/CD Best Practices
- Keep pipelines fast: Target under 10 minutes for CI. Run tests in parallel. Cache dependencies.
- Fail fast: Put the fastest checks (linting, unit tests) first so developers get feedback in under 2 minutes.
- Build once: Create the deployment artifact once; deploy the same artifact to staging and production. Never rebuild for production.
- Test in production-like environment: Staging should mirror production configuration as closely as possible.
- Feature flags over long-lived branches: Merge frequently; use flags to hide incomplete features.
- Monitor after deploy: Watch error rates and key metrics for 15 minutes post-deploy. Have an automated rollback trigger.
💡 Start Small
You do not need a perfect pipeline on day one. Start with: (1) Run tests on every PR. (2) Block merge if tests fail. That alone eliminates most regression bugs. Add staging deploys, E2E tests, and security scans incrementally.
How We Research and Update This Guide
We test the underlying formula or workflow, compare outputs with reliable references, and revise examples whenever the page content changes.
- The workflow or formula is tested directly in the tool and compared against independent reference examples.
- Examples are kept practical so readers can verify the result without hidden assumptions.
- Pages are revised whenever the interface, calculation flow, or surrounding guidance materially changes.
Frequently Asked Questions — CI/CD
Continuous Integration (CI): Every code commit automatically triggers a build and test run. If tests fail, developers are alerted immediately. Goal: catch integration problems early. Continuous Delivery (CD): Every passing build is automatically prepared for release — the deployment to production is ready but requires a manual approval step. Goal: always have a deployable artifact. Continuous Deployment (CD): Every passing build is automatically deployed to production — no manual step. Goal: ship to users as fast as possible.
A typical pipeline has these stages: (1) Source — code pushed to Git triggers the pipeline. (2) Build — code is compiled or bundled. (3) Test — unit tests, integration tests, linting, security scans run in parallel. (4) Staging deploy — app is deployed to a staging environment. (5) Acceptance tests — automated or manual E2E tests against staging. (6) Production deploy — if all passes, code goes to production. Each stage must pass before the next runs.
GitHub Actions is GitHub's built-in CI/CD platform. You define workflows as YAML files in .github/workflows/. Workflows are triggered by events (push, pull request, schedule). Each workflow has jobs; each job runs on a virtual machine (runner) and contains steps (run commands or use Actions). It is free for public repos and has a generous free tier for private repos. It integrates natively with GitHub events, making it the easiest option for GitHub-hosted code.
Jenkins is a self-hosted, open-source CI server you install and manage on your own infrastructure — full control, high customisation, but you maintain the server. GitHub Actions is a cloud-hosted service managed by GitHub — zero infrastructure to maintain, tight GitHub integration, but less control over the runtime environment. GitHub Actions is the default choice for new projects; Jenkins is preferred in enterprises with specific security or compliance requirements that prevent cloud-based CI.
Layer your CI/CD pipeline: (1) Pre-commit hooks — linting and formatting checks before code is even committed. (2) PR checks — CI runs tests on every pull request; merge is blocked if tests fail. (3) Required reviews — require at least one human code review before merge. (4) Staging environment — deploy to staging first, run smoke tests. (5) Feature flags — deploy code without enabling it; gradually roll out. (6) Automated rollback — if error rate spikes post-deploy, automatically roll back.
A deployment artifact is the output of the build step — a versioned, tested, ready-to-deploy package of your application. Examples: a Docker image tagged with a version (myapp:1.4.2), a compiled Java JAR, a zip of a Node.js app, a Python wheel package. Artifacts are stored in an artifact registry (Docker Hub, AWS ECR, Nexus, GitHub Packages). The key principle: build once, deploy the same artifact to staging and production — never rebuild for production.