Continuous integration (CI) is a practice in software engineering where members of a team integrate their work frequently. Each person usually integrating at least once daily, leading overall to multiple daily integrations. Every 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 finds, 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 Continuous Integration in our own work.
After we organized the first Angular meetup in Poland in 2014, we tweeted about it. 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 I asked myself was whether we used continuous integration or not. 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 continuous integration (CI), is why we didn’t get the gig. They decided to go with someone else and thought we were not organized in a way that would/could satisfy a big client. This, of course, got me 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 utilizes 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 the quality of the produced software and a reduction in the time of its delivery.
This is attempted by organizing 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. 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. 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.
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.
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. This makes 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:
- continuous detection and fixing of integration problems, avoiding the 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 the demo, testing, and release purposes
- immediate feedback available to developers on the functionality, quality, and overall impact of their code.
- since the initial setup requires time
- a well-developed testing suite is needed to achieve CI’s automated testing advantages
- hardware costs for build machines can also be significant.