Continuous integration and continuous delivery: what they are? First of all, we define the concept of continuous integration.

A Practical Example?

When we develop software we do it in a team: that is, we are a group of people, including engineers and developers, who contribute to the development of the different parts of the software.

At a certain point, however, the different parts must be assembled, or integrated so that they work effectively together: that is, they must be aligned.

Here: continuous integration expresses this alignment when it occurs frequently - read “several times a day”: the integration from the work environments of the developers towards a shared environment in which the software as a whole resides.

The concept was originally born in the context of Extreme Programming, as a preventive countermeasure to the problem of integration hell, (the “hell” of the integration of portions of software developed independently over long periods and potentially significantly divergent).

In non-continuous development, the developments of the different parts of the software proceed independently for a long time, and it is only at the moment of integration that any (inevitable) problems emerge: the moment of integration, therefore, became the litmus test of design errors and/or development, which was often cumbersome to remedy given the period since the beginning of development.

Version control: that is, knowledge is power (and responsibility)

With continuous integration, a new development scenario opens: each phase of production, from the small code, commit to the test until the release of key functions, is traced and corresponds to a certain “version” of the software.

Each modification or integration has an identification number and all information related to it is traced: when, how, and by whom it was launched.

What Comes of It?

Lots of advantages for a quality code:

• If there is an error, it is easier to understand where it started and why
• Any defects and bugs are intercepted immediately and we play in advance in correcting them
• Each new version of the code represents an improved, optimized version of itself
• Each developer is made responsible for the part of the code released: it is an explicit call to responsibility and to the qualitative development that every developer cannot avoid
• Continuous delivery: when the Judgment Day is no longer the Judgment Day

Continuous delivery is the intrinsic consequence of continuous integration: if the software is continuously and frequently integrated, then it is also continuously and frequently releasable in production, that is, publishable online and visible to the customer.

This is a cornerstone of agile technology, which we at Octal also apply with the necessary customizations: the software as we have said is divided into parts and processes, each of which must be frequently integrated with the others and released into production.

Any changes introduced in the code can potentially be relaunched in the short run, without long waiting times between the development and production of the changes.

In what terms does development with continuous integration bring quality to software development and ultimately to the eyes of the end customer, even non-technical ones?

1. The D-Day Is Postponed

• In non-agile development and without continuous delivery the day of release corresponded to the Day of Universal Judgment.
• Try to think about it: 3 months of development and 1 day in which all the knots can potentially come to ahead.

It would scare anyone, right?

With continuous delivery, however, the developers are physiologically vaccinated on the release: the release is no longer the dreaded D-Day, but only one of the many phases of the software development and continuous improvement process.

#devops