What CI/CD Automates
Objectives
By the end of this lesson, you should be able to:
- Define continuous integration and continuous deployment separately
- Explain what problem each one solves, specifically
- Explain why CI without CD is still valuable on its own
💡 Why this matters: Course 3 built a real, passing test suite, Module 2 of this course built a container image. Both are only as useful as how consistently they’re actually run, CI/CD is what makes “run the tests” and “build the image” happen automatically, on every change, instead of whenever someone remembers to.
Continuous Integration
Continuous integration (CI) means every change, every push, every pull request, automatically triggers the project’s test suite, and often linting or a build step too. The goal is catching a broken change immediately, before it merges, rather than discovering it later, after it’s already mixed in with other work, or worse, after it’s already been deployed. CI doesn’t deploy anything, it verifies.
Continuous Deployment
Continuous deployment (CD) picks up where CI leaves off, once tests pass, automatically building a deployable artifact (Module 3’s container image) and shipping it, to staging, to production, or both, without a person manually running the deployment steps by hand. Some teams use continuous delivery instead, identical up through “ready to deploy,” but with a manual approval step before it actually goes out, still automated everywhere except that one intentional pause.
Why CI Alone Is Still Worth Having
A project with CI, but no CD, still gets a real benefit: every pull request shows, automatically, whether it broke anything, before a human reviewer even needs to run the tests locally. This is worth setting up on its own, independent of whether a team is ready for fully automated deployment, Module 3’s Docker image and Course 3’s test suite already exist, CI is what starts running them automatically, CD, covered later in this module, is what takes the next step.
What This Module Builds
A real GitHub Actions workflow, run automatically on every push, first just running Course 3’s test suite (CI), then extended to build and publish Module 3’s Docker image once those tests pass (CD), exactly the progression described above, built concretely, one workflow file at a time.
Try It
- Explain, in your own words, the difference between continuous integration and continuous deployment, using this track’s own Notes API as the example.
- Describe a real scenario where CI without CD would still catch a bug before it caused a problem.
- Explain, in one or two sentences, what “continuous delivery” adds between CI and full CD.
Recap
- Continuous integration automatically verifies every change, running tests (and often linting) on every push or pull request.
- Continuous deployment automatically ships a verified change, building and publishing an artifact once tests pass.
- CI alone is valuable on its own, catching broken changes before they merge, independent of whether deployment itself is automated yet.
Next lesson: building a real GitHub Actions workflow that runs a test suite automatically.