Since K1 (lesson 1.8.5), a check has run on every pull request of the Kladde that you received as a ready-made template, and in K2 (lesson 2.7.8) you extended it to cover all test projects. From now on, you write such checks yourself. In this module, it grows step by step into a pipeline that tests, versions and, after an approval, delivers to Azure. This first lesson lays the foundation: continuous integration with GitHub Actions, built so that you can justify every line.
What continuous integration is
Continuous integration, CI for short, means: everyone merges their changes often, and every change is built and tested automatically on a neutral
machine before it reaches the main branch. The goal is a main that is green at all times. Whoever pulls
main in the morning gets a state that builds and whose tests pass.
Three things make up CI:
- A neutral machine. The pipeline's machine knows only the repository. Whatever works only on your machine because a file happens to be in your folder or your computer is set to German shows up there.
- The same steps on every change. No human decides whether tests run today.
- A clear verdict. Green or red, and by the exit code of the commands, not by a text that looks friendly.
CI is the first half of CI/CD. The second abbreviation stands for continuous delivery (every green state can be delivered) or
continuous deployment (every green state is delivered). In this module, the Kladde gets both: main goes to dev by itself,
prod only after an approval.