How CI/CD works: why releasing code every day is safer than once a month
The CI pipeline: what happens on a server each time you push code
Push your code, and a few minutes later a check mark or a red cross shows up next to it. A CI pipeline put it there. Which computer did the checking, and how did it know what to check?
-
1
On Friday, Rono made a commit, Git's word for one saved change, and pushed it: he sent it to the shared repository. He never ran the tests, and the app broke for everyone who pulled it.
-
2
The team hands the job to a machine instead. Each push to the shared repository wakes up a separate computer, called a runner.
-
3
The runner starts from a clean computer and takes a fresh copy of the repository, and nothing from anyone's laptop. If the app needs a file that sits only on your laptop, it fails here, and everyone sees it.
-
4
The runner finds its steps in a file inside the repository, next to the code: first build the app, then run the tests. Those steps, in order, are the pipeline, and the team changes it the same way it changes the app.
-
5
A few minutes later, the result shows next to the commit, for the whole team: a check mark when every step passed, a cross when one failed. A run that passed is called green, and one that failed is red.
-
6
Main is checked on every push now. Still, the new version reaches the neighbours the old way, on a long night of steps that Rono does by hand. Some teams put new code in front of their users many times a day: how do they dare?
-
Quick check
A file you forgot to commit.
Show the answer
Red. The runner takes a fresh copy of the repository, and your file is not in it, so the build or the tests fail there.
-
Go further
The names you will meet in real teams.