Values

CI system is like a seal of quality control. Something that confirms that things are as they should be. It must meet several conditions in order to truly add value.

• Tasks should be short. The goal is to know as quickly as possible if everything is OK. This is an important part of the work and should be kept in mind when scaling the project.
• It should be understandable. Every engineer should know what happens in each step of the pipeline, so they can diagnose problems themselves. This is particularly important when there are dependencies in the system and it is not clear which component is causing the issue.
• Locally reproducible. What happens on the servers should also happen locally. This is the best way to debug. Of course, it is not always possible to reproduce everything, but you can do quite a lot to make both scenarios similar. This is very helpful.

Tasks

There are various tools implementing CI, just as there are various tools supporting building. However, I believe that universal steps can still be distinguished in a typical pipeline.

• Building. Depending on the language, compilation, linking, or whatever else… In general, the process where we obtain a raw artifact. This is the obvious minimum.
• Testing. From unit tests to integration tests to system tests. Automated tests in a CI system are an undeniable benefit.
• Packaging. Processing the raw artifact into something that can be further worked with. Installer, image, package, etc.

Here, the list of basic things could be ended, but I believe the following points are becoming less optional:

• Static analysis: an automaton that is even more strict than the compiler. A tool that checks compliance with the standards we agreed upon.
• Dependency scanning. Listing dependencies, their licenses, and most importantly, vulnerabilities. We don’t want to deliver something that has security holes.

Methodology

CI is just a tool. A holistic DevOps approach to the project is what matters. DevOps ties together all other values.