CI/CD
The pipeline that turns "I wrote code" into "users have it." When it is good, it is the difference between a team that ships and a team that does not.
CI. Continuous integration
Continuous integration means every time a developer pushes code, it is tested automatically.
How it works. Developers work on branches. They push commits. A CI service watches the repo. Common ones are GitHub Actions, CircleCI, Jenkins, and GitLab CI. On every push it does this.
1. Pull the code. 2. Install the dependencies. 3. Run the test suite. 4. Run linters, type checks, and security scans. 5. Build the artifact (container image, binary, whatever you ship).
If any step fails, the developer gets notified. They fix it before merging.
The benefit. Bugs are caught minutes after being written, when the context is still fresh, instead of days later when someone else stumbles into them. Tests run on a clean environment every time.
CD. Continuous delivery or deployment
Continuous delivery means that after CI passes, the artifact is prepared for production automatically. A human clicks a button to ship it.
Continuous deployment means that after CI passes, the artifact goes to production automatically. No button.
Both are called "CD." Continuous delivery is the more common one. Continuous deployment is the goal at high-trust teams. Small teams that ship 50+ times a day live there.
The pipeline. CI builds the container image. The image goes to a registry. The deploy system pulls it and rolls it out to the production servers. Health checks confirm the new version is serving traffic. The old version shuts down.
Common deploy tools. ArgoCD, Spinnaker, GitHub Actions deploy steps, AWS CodeDeploy, or simple shell scripts that call kubectl.
Rollout strategies
Deploying to every server at once is risky. If the new version has a bug, every user gets hit at the same time. Better strategies.
Rolling deployment. Replace servers one at a time. If the new ones look unhealthy, stop the rollout. Most cloud platforms do this by default.
Canary deployment. Deploy the new version to 1 percent of servers first. Watch the metrics for 10 to 30 minutes. If error rate or latency rises, abort and roll back. If not, ramp up to 5 percent, then 25, then 100.
Blue-green. Keep two complete environments. "Blue" is serving production. "Green" gets the new version. Health-check green. If it looks good, swap traffic from blue to green at the load balancer. Rolling back is instant. You swap back.
Canary is the gold standard for high-traffic systems. The whole point is to catch a bad deploy before it hits everyone.
Why this matters
Teams without CI/CD ship slowly and shakily. Every release is an event. Code freezes. Manual testing. A deployment day. Panic. Bugs reach production weeks after they were introduced. Rollbacks are painful.
Teams with good CI/CD ship dozens or hundreds of times a day. Each change is small. If something breaks, it is easy to find and revert. Engineers iterate quickly because the cost of being wrong is low.
The DORA metrics (DevOps Research and Assessment) consistently show that deployment frequency and mean time to recovery are the leading indicators of team health.
Building this pipeline is not glamorous. But it is one of the highest-leverage investments a team can make. Once it is in place, every future feature ships faster.
This is the last concept in the foundation curriculum. You now understand how requests work, how systems scale, how data is stored, how systems stay reliable, and how they are shipped. Every modern web architecture is built from these pieces.