CI/CD and Deployment
Turn a green test suite into a running production service — automatically, safely, and without dropping requests.
Big idea: Continuous Integration (CI) proves that every commit still lints, tests and builds. Continuous Delivery / Deployment (CD) takes that proven artifact and ships it to real environments. Together they replace the error-prone ritual of "SSH in and run
git pull" with a repeatable pipeline that a machine executes the same way every time.
By the end you will be able to:
- describe the classic pipeline stages -- lint -> test -> build -> deploy -- and why order matters;
- separate environments (dev, staging, production) and promote one artifact through them;
- handle secrets in CI without ever committing them to the repository;
- explain zero-downtime deploys and contrast rolling, blue-green and canary strategies;
- read a real GitHub Actions workflow and know what each step buys you.
1. CI vs CD -- three terms people blur
The three letters hide three distinct ideas. Getting them straight makes every tool and tutorial clearer.
- Continuous Integration (CI) -- on every push and every pull request, an automated job checks out the code, installs dependencies, runs the linter, runs the test suite, and produces a build. Its promise is narrow but powerful: "main always compiles and passes its tests."
- Continuous Delivery (CD) -- every green build is automatically packaged into a deployable artifact (a Docker image, a tarball, a versioned bundle) and pushed as far as staging. A human still clicks "promote to production."
- Continuous Deployment (also CD) -- the same, but the last step is automatic too: a green build on main goes all the way to production with no human gate.
Most teams run CI plus delivery, then adopt full deployment once their tests, monitoring and rollback are trustworthy enough to skip the manual click. The pipeline is identical; only the final approval differs.
Why automate at all? A manual deploy is a checklist executed by a tired human at 6 pm on a Friday. A pipeline is the same checklist executed by a machine, identically, every time, with a log you can audit. It removes the "it worked on my machine" and "I forgot to run the migration" class of incidents.