CI/CD Fundamentals

Every commit a developer makes eventually has to become running software. CI/CD is the set of practices that automates that journey instead of leaving it to someone remembering to run the right commands in the right order.

Continuous Integration (CI)

CI means every developer merges their changes into a shared branch frequently - often several times a day - and a machine automatically builds the project and runs the test suite on every merge.

The payoff: if two people's changes conflict, or someone breaks a test, you find out in minutes, not weeks later when it's tangled up with a dozen other changes.

Continuous Delivery vs. Continuous Deployment

These two terms get used interchangeably, but they're not the same:

Most teams start with delivery (a safety net of human judgment before production) and graduate to full deployment once their test suite is trustworthy enough.

The pipeline shape

Nearly every CI/CD pipeline, regardless of the tool running it, boils down to the same stages:

checkout → build → test → package → deploy

Every stage after checkout only runs if the one before it succeeded - that's the whole point. A failing test should stop a bad build from ever reaching a deploy step.

Why bother automating it?

• Fast feedback - a broken build is caught in minutes, while the change is still fresh in the author's head.
• Consistency - the exact same steps run every time, with no "works on my machine" variance.
• Confidence - a green pipeline is a receipt that the thing you're about to ship actually builds and passes its tests.

Every pipeline needs somewhere to track changes before it can build anything from them - that's git, which you'll use constantly across this track.

Try it in the practice terminal (opens in a new tab):

git init

When you're ready, hit Mark complete and move to the next lesson.