Why you should care about Continuous Integration ?

Continuous integration (CI) is a practice in software engineering where members of a team integrate their work frequently, with each person usually integrating at least once daily, leading overall to multiple daily integrations. Each instance of integration into the shared mainline is verified by an automated build (including a test), which enables quick detection of integration errors. CI is an approach that, many find, leads to measurably reduced integration problems and allows a team to develop cohesive software quicker.

The following is an overview of the practice and an argument for its implementation. But first let’s take a quick glance at our own history and how we got to using CI in our own work.

Our story

After we organised the first AngularJS meetup in Poland in 2014, we tweeted about it and a couple of weeks later a big research company from Germany (with offices spanning all of Europe) pinged us on Twitter.

Soon after, one of the questions that company’s CTO asked us was whether we used continuous integration. Back then we did not. We were a small team and wanted to focus on delivering our projects and not spend weeks on figuring out our company’s internal processes. This, and specifically us not using CI, is why we didn’t get the gig. They decided to go with someone else and thought we were not organised in a way that would/could satisfy a big client. This of course got our CTO to start thinking about CI, and this year we have finally implemented it in our company for all current projects.

But why was that research company so insistent that their subcontractors use CI? What are some of the main characteristics and advantages of continuous integration?

CI implements and utilises continuous processes of applying quality control. These processes are regimented into small pieces of effort, applied frequently, sometimes as frequently as possible. By thus replacing the traditional practice of applying quality control only once all development has been completed, CI aims at an improvement in quality of the produced software and a reduction in the time of its delivery.

This is attempted by organising work in such a way that integrating new or changed code is done frequently enough that no big-enough window remains between commit and build, and therefore optimally no errors can arise in the process without the developers spotting and correcting them immediately.

The way to set this up is by triggering builds with every commit to a repository instead of just with a periodically scheduled build. In a multi-developer environment replete with rapid commits this has the advantage of triggering a short timer after each commit, and then starting a build either when the timer expires or following a longer interval since the previous build. This is done with automated tools such as CruiseControl, Jenkins etc. which offer scheduling of this sort by default.

CI requires a version control system with atomic commit support, meaning that all of the developer’s changes can be seen in terms of a single commit operation, making all the changes included in every subsequent build. To this end, the build needs to complete quickly, so that all the problems with integration are quickly identified.

Conclusion

Continuous integration is not all easy since the initial setup requires time. A well-developed testing suite is also needed to achieve its automated testing advantages. Finally, hardware costs for build machines can also be significant. But once these investments are made, the advantages of CI become evident over time and make implementation well worth the initial hassle. Some of these advantages of CI include continuous detection and fixing of integration problems, avoiding last-minute chaos of release dates; early warnings of broken or incompatible code and other conflicting changes; immediate unit testing for all changes; availability at all times of an up-to-date build for demo, testing and release purposes; and immediate feedback available to developers on the functionality, quality, and overall impact of their code. Many teams using CI report that the advantages easily outweigh the disadvantages in practice and that the ability to detect and fix integration bugs early, saves both time and money throughout project development.

Continuous integration in a nutshell:

Advantages

• continuous detection and fixing of integration problems, avoiding last-minute chaos of release dates
• early warnings of broken or incompatible code and other conflicting changes; immediate unit testing for all changes
• availability at all times of an up-to-date build for demo, testing, and release purposes
• immediate feedback available to developers on the functionality, quality, and overall impact of their code.

Disadvantages

• since the initial setup requires time
• well-developed testing suite is needed to achieve CI’s automated testing advantages
• hardware costs for build machines can also be significant.

This article was originally taken from Briisk Blog.