We use analytics cookies.We use cookies to analyze site traffic and improve your experience.
Loading...
System Design and AI Engineering, by Roni Das. 984 interactive lessons.
Start LearningIntermediate · DevOps & CI/CD
Continuous Integration and Continuous Deployment: automating the process of testing and deploying code. Push code, tests run, and it ships to production automatically.
In short
CI/CD stands for Continuous Integration and Continuous Delivery (or Deployment). Continuous Integration means every code change is automatically built and tested the moment it merges, so bugs surface in minutes instead of weeks. Continuous Delivery/Deployment means that once those tests pass, the same change is automatically packaged and shipped toward production, either at the click of a button (delivery) or with no human at all (deployment).
In short
CI/CD stands for Continuous Integration and Continuous Delivery (or Deployment). Continuous Integration means every code change is automatically built and tested the moment it merges, so bugs surface in minutes instead of weeks. Continuous Delivery/Deployment means that once those tests pass, the same change is automatically packaged and shipped toward production, either at the click of a button (delivery) or with no human at all (deployment).
Learn it in the course
This page is the free part.
₹1,111 in India$25 everywhere elseonce, for the whole course
The System Design course covers CI/CD across a run of lessons, not one page. These 4 alone are about 72 minutes of step-by-step reading, every one with a quiz.
Automatically building, testing, and validating every code change, catching issues within minutes of committing.
Automatically deploying every change that passes the pipeline to production, no human gate, no release ceremony.
Ensuring that code is always in a deployable state, every commit could go to production if you choose.
Running tests automatically on every code change, catching bugs before humans have to look at them.
all part of
System Design Masterclass
770 lessons · about 287 hours · 18 free to read
₹1,111in India, by UPI
$25everywhere else, by PayPal
It is really nice and good Please join the course
You own this course
Continue with Continuous Integrationpay once,
yours for life
The two halves solve two different problems. Continuous Integration (CI) is about catching breakage early. Instead of letting developers work on private branches for weeks and then fighting a painful merge, everyone pushes small changes to a shared branch many times a day. Each push triggers an automated build and test run. If your change breaks the build, you find out in 5 to 15 minutes, while the change is still fresh in your head.
Continuous Delivery and Continuous Deployment cover what happens after the tests pass. Continuous Delivery means the build is automatically turned into a deployable artifact and pushed all the way to a staging environment, ready to release with one manual approval. Continuous Deployment goes one step further: there is no manual approval at all. A green build on the main branch goes straight to production on its own.
People write both as CD, which causes endless confusion. The practical difference is one human click. A bank running Continuous Delivery wants a person to sign off before money-moving code ships. A company like Amazon, which deploys to production thousands of times a day, leans on full Continuous Deployment for most services.
A CI/CD pipeline is a sequence of stages defined in a config file that lives in your repo, like .github/workflows/ci.yml for GitHub Actions or .gitlab-ci.yml for GitLab. When you push a commit or open a pull request, the platform spins up a fresh, isolated runner (a container or VM), checks out your code, and walks through the stages in order.
A typical stage order is: install dependencies, run linters, compile or build, run unit tests, build a container image, run integration tests against that image, then deploy. If any stage exits with a non-zero code, the pipeline stops and the commit is marked as failed. Nothing downstream runs.
Two ideas make this reliable. First, every run starts from a clean machine, so there is no leftover state from the last build (this is why a pipeline catches the classic it works on my machine bug). Second, the build produces an immutable artifact, usually a Docker image tagged with the commit SHA. The exact same artifact that passed tests in staging is the one promoted to production, so you never accidentally ship something that was never tested.
Almost any project with more than one engineer benefits from at least CI. The moment two people share a codebase, automated tests on every merge pay for themselves by stopping one person from silently breaking another person's work. Full Continuous Deployment is a stronger commitment: it only works if your test suite is genuinely trustworthy, because a weak suite means you are now shipping bugs to users automatically and fast.
The cost is real. You need to write and maintain tests, keep the pipeline fast (a 40 minute pipeline kills the fast-feedback benefit, so teams aim for under 10 minutes), and pay for compute on the runners. Flaky tests that fail randomly are especially poisonous because people start ignoring red builds, which defeats the whole point.
The trade-off most teams land on is CI everywhere plus Continuous Delivery for risky systems and full Continuous Deployment for low-risk, well-tested services. Safety nets like feature flags, canary releases, and automated rollback on error-rate spikes make aggressive deployment far less scary.
Say you fix a bug in a checkout service and open a pull request on GitHub. GitHub Actions immediately runs your pipeline: it installs Node dependencies, runs ESLint, runs 800 unit tests, and builds a Docker image. All of that finishes in about 6 minutes and posts a green check on your PR. A teammate reviews and merges.
On merge to main, a second pipeline runs. It rebuilds the image, runs integration tests against a throwaway Postgres container, pushes the image to a registry tagged with the commit SHA, and deploys it to a canary that serves 5 percent of production traffic. A monitor watches error rates for 10 minutes. If errors stay flat, the deployment rolls out to 100 percent automatically. If errors spike, it rolls back to the previous image with no human involved. Your bug fix reached every user within roughly 20 minutes of merging, and nobody had to manually copy files to a server.
GitHub Actions
Runs CI/CD pipelines defined in YAML directly inside GitHub repos; triggers on push and pull request events using ephemeral runners.
Amazon
Pioneered extreme Continuous Deployment, reportedly deploying to production on the order of thousands of times a day across its services.
Jenkins
The long-running open-source automation server that popularized self-hosted CI/CD pipelines and a huge plugin ecosystem.
GitLab CI
Ships CI/CD built into the GitLab platform via .gitlab-ci.yml, covering build, test, and deploy in one tool.
Both are abbreviated CD and both automatically push tested code toward production. The difference is the last step. Continuous Delivery stops at a ready-to-release state and waits for a human to click deploy. Continuous Deployment removes that click entirely, so a passing build on main goes live with no human approval.
No. DevOps is a broad culture and set of practices for how development and operations teams work together. CI/CD is one specific, concrete practice within DevOps: the automated pipeline that builds, tests, and ships code. You can do CI/CD without fully adopting DevOps, but CI/CD is usually the first thing teams automate on a DevOps journey.
You do not strictly need it, but even solo it is cheap to add and catches mistakes. A simple CI step that runs your tests on every push stops you from deploying a broken build, and free tiers on GitHub Actions or GitLab CI cover small projects at no cost. Full automated deployment matters more once real users depend on your project.
The whole value of CI is fast feedback. If the pipeline takes 40 minutes, developers context-switch away and stop paying attention to results, which reverses the benefit. Teams aim for pipelines under 10 minutes by running tests in parallel, caching dependencies, and splitting slow integration tests into a separate stage.
The pipeline stops at the failing stage and marks the commit or pull request as failed, usually with a red status check. Nothing downstream runs, so a failed build never gets deployed. The developer sees logs from the failing stage, fixes the issue, and pushes again to re-trigger the pipeline.
Docker
A platform for packaging applications into lightweight, portable containers. 'Works on my machine' becomes 'works everywhere.'
Kubernetes
An orchestration platform that automates deploying, scaling, and managing containerized applications. K8s is the operating system for your cloud.
Blue-Green Deployment
A deployment strategy using two identical environments. Traffic switches from blue (current) to green (new) instantly, with easy rollback.
Canary Deployment
Rolling out a new version to a small percentage of users first, then gradually increasing. Like sending a canary into a coal mine to test for danger.
Rolling Deployment
Gradually replacing old instances with new ones, a few at a time. No downtime, but both versions run simultaneously during the rollout.
GitOps
Using Git as the single source of truth for infrastructure and application configuration. Changes are made via pull requests and automatically reconciled by tools like ArgoCD or Flux.
This page explains the idea. The "Continuous Integration" lesson builds it up step by step, with diagrams. It is part of the System Design Masterclass course, which has 770 lessons. 18 of them are free to read. You pay once and keep it for life, with no subscription.
Open the Continuous Integration lessoncourse 1
From absolute beginner to principal engineer, drawn step by step.
Asked about CI/CD in an interview?
Each question has why it is asked, a full answer, what the interviewer listens for, the follow-ups, the common mistakes and a diagram (268 diagrams in all). A PDF you keep, junior to staff level.
India: UPI, cards or netbanking through Razorpay. Elsewhere: card or PayPal. Download at once from My packs.
