Continuous integration: protection against quality by obscurity

How did continuous integration come about?

In 1935, Austrian physicist Erwin Schrödinger proposed a mental experiment in which a cat is confined to a cardboard box with a glass of poison and a random trigger that can release this poison. The point of the matter is that, as long as an observer does not evaluate the contents of the box, we cannot consider the cat to be alive or dead. So, according to Schrödinger, we must consider him alive and dead. In addition to the numerous developments related to physics and how their experiments and results should be evaluated, this paradox brings to the rest of us the importance of the observer in defining the state of what is being evaluated.

How does the ongoing integration process work?

In software engineering, the construction of a project begins with the integration of each delivery from the developers to the rest of the project. With each interaction of the development process, which generates new deliveries from the developers, new integrations are carried out. Integrations can simply combine deliveries but can also include assessments of validity, quality, security, etc.

Although performing the integration process on a continuous (uninterrupted) basis was proposed in the early 90s, it was only at the end of that decade that movements that sought to speed up the software development process proposed that the more continuous, the smaller the delivery the better it would be for the software development process. This method became known as Continuous Integration (or simply CI).

To make this method viable, automation of the integration process is necessary. And it is evident that the more deeply automated, the better. It is also evident that the more analyzes and validations are carried out, the better the product quality will be.

Just as we cannot say that Schrödinger’s cat is alive or dead until we open the box, we don’t know if the deliveries made by the developers work and meet the quality and safety requirements until we integrate them.

In engineering, it is common to hear the expression “security by obscurity”, where something is unduly considered safe because its faults are hidden or not evaluated. This concept can also be extended to the quality of the project. Something like developing and protecting your project in the Schrödinger box, a question that we don’t want, right?

Written by Andreyev Dias de Melo