Teachers

Automating what you did by hand

Last week's deployment ended with you playing robot: mvn verify, docker build, docker push, then a click on Render. Four steps, in the right order, every time, forever. Miss one — ship an image you never tested, or forget to push at all — and production quietly drifts away from your code.

CI/CD is the practice of giving that ritual to an actual robot. A pipeline watches your repository, and on every change it runs the same steps, in the same order — and refuses to continue the moment one of them fails.

Three terms, one idea

Continuous Integration (CI) — every change is merged often, and every merge is automatically built and tested. CI answers one question: does the project still work with this change in it?
Continuous Delivery — every change that passes CI is automatically packaged and ready to deploy. A human presses the final button.
Continuous Deployment — nobody presses the button. Every change that survives all the checks goes live automatically.

	Tested automatically	Packaged automatically	Deployed automatically
Continuous Integration	✅	❌	❌
Continuous Delivery	✅	✅	❌ (a human clicks)
Continuous Deployment	✅	✅	✅

<aside> 💡

The two CDs differ by exactly one thing: who triggers the final deploy — a person (Delivery) or the pipeline itself (Deployment). This week you build the full Deployment version, because the project is yours alone. Many companies deliberately stop at Delivery and keep a human approval before production.

</aside>

Where does all this run?

Not on your laptop. When the pipeline starts, GitHub boots a runner for you: a fresh Linux virtual machine that lives only for this one run. It comes with an operating system and common tools — and nothing of yours. No repository, no database, no environment variables, no leftover files from last time. Everything your pipeline needs, you must ask for explicitly.

When the run finishes, the machine is thrown away.

<aside> 💡

This is why CI kills “it works on my machine”: the runner is nobody's machine. If your project builds there, it builds anywhere — and if it only builds on your laptop, the runner will tell you this within minutes.

</aside>

Stages and gates

A pipeline is a chain of stages, and every stage is a gate:

commit → [ build ] → [ test ] → [ package image ] → [ deploy ]
             │           │              │                │
           fails?      fails?         fails?           fails?
             → STOP. Nothing after this point runs.

The ordering is the protection: code that does not compile never gets tested, code that fails its tests never becomes an image, and an image that was never tested never reaches production. The payoff is fast feedback — you hear about a problem minutes after the commit that caused it, on every pull request, instead of during a deploy on Friday afternoon.

💬 Question: Your teammate's code passes all the tests on their laptop. Your code passes all the tests on yours. After merging both into main, the application is broken. What did nobody ever run?

Answer

This week's map

Every chapter this week automates one of last week's manual steps:

GitHub Actions — runs mvn verify for you on every pull request, and blocks the merge when it fails.
Docker in CI — builds the Docker image and pushes it to a registry, exactly as you did by hand.
Spring profiles — lets the same image behave differently per environment.
Deploying from a Pipeline — replaces the click on Render.
Quality Gates — adds a check you never did by hand at all.

Extra resources

Continuous integration vs. delivery vs. deployment — Atlassian: the three terms explained in more depth, with the same one-button distinction.
Continuous Integration — Martin Fowler: the classic long-form article on why teams integrate continuously. Long, but this is where much of the industry learned it.
GitHub Actions documentation: the official home of everything you will use in the next chapters.

The HackYourFuture curriculum is licensed under CC BY-NC-SA 4.0 *https://hackyourfuture.net/*

CC BY-NC-SA 4.0 Icons

Built with ❤️ by the HackYourFuture community · Thank you, contributors

Found a mistake or have a suggestion? Let us know in the feedback form.

Week 12