Learn how to build, test, deploy, and maintain robust software systems.
Continuous Integration and Continuous Delivery (CI/CD) automate the path from source code to production. Instead of a developer manually building, testing, and deploying by hand — a process full of forgotten steps and human error — a pipeline runs the checks automatically every time code is pushed. This lesson explains what CI and CD actually mean, how a pipeline is structured, why build artifacts and environments matter, and the deployment strategies (rolling, blue/green, canary) that let you release safely. The examples use GitHub Actions, but the ideas apply to any CI/CD tool.
CI means integrating changes frequently and verifying each one automatically: build and run the tests as soon as code is pushed, so problems are caught early. CI is the practice, not a specific tool.
| Continuous Integration | Continuous Delivery | Continuous Deployment | |
|---|---|---|---|
| Automates | Build + test on every change | Releasable state at all times | Deployment to production |
| Production deploy | Manual | Manual (one click) | Automatic |
| Goal | Catch integration errors early | Always ready to release | Ship every change that passes |
Real pipelines vary, but they generally move from checking out code to verifying it to packaging it to deploying it.
Code moves through environments — development, staging, production — and a good pipeline promotes one artifact through them with environment-specific configuration.
Deployment credentials and API keys must never be hardcoded in the pipeline. CI systems provide secret stores that inject secrets as environment variables.
| Strategy | How it works | Risk | Rollback |
|---|---|---|---|
| Rolling | Replace instances gradually | Medium | Stop and redeploy |
| Blue/green | Run two versions, switch traffic | Low | Switch back instantly |
| Canary | Roll out to a small %, then expand | Low | Pull back the canary |
Blue/green keeps a current (blue) and a new (green) environment, then switches traffic in one step. Canary sends a small percentage of traffic to the new version, monitors it, and expands gradually.
Every production deployment needs a recovery strategy — the ability to quickly return to a known-good state.
Each step is a check. If lint or test fails, the whole pipeline fails.
Build once, then deploy the same artifact to staging and production.
(no rebuild between environments)