Continuous Integration: How to Avoid 'Integration Hell'

If you have worked on a software development team, you will recognize these scenarios:

1. You have a large team of engineers developing a software application. While committing the code in the repository, one of the developers forgets to commit one or two files. When other team members take the repository updates, they find problems in the code due to the missing file changes, and they have to spend a long time debugging the problems.
2. Your engineering team is developing a software product. Your Business Analysis team needs frequent updates of the code to validate the changes or demonstrate new features to the customers. Preparing a new build and deploying it on the staging server for a BA team takes a significant amount of a developer's valuable time.
3. You have delivered new software to your client and it is in UAT (User Acceptance Test) stage. The client finds some bugs or suggests minor tweaks which you need to deliver quickly. These deadlines create a rush to completion, which results in negative side effects and breaks the previously smooth running functionality.

The above examples are just some of the common cases a software development encounters during the software development life cycle. These issues can be frustrating and can cause delays and extend the schedule and increase the budget of a software development project. Fortunately, we can use the concept of CI (Continuous Integration) to protect us against just such situations.

Continuous Integration (CI)

Continuous integration is the practice of merging all developers’ working copies with a shared mainline and making a build several times a day. It is used to prevent integration problems, to improve the quality of software and to reduce the time taken to deliver. Continuous Integration is derived from the early practice of XP (Extreme Programming) where a team integrates the code change more often to avoid descending into 'integration hell', e.g., integrating a big chunk of code changes at the last minute which results in conflicts, and can take more time to resolve as compared to the time required to make original changes.

There are many CI tools available in market, which can be set up on a server to perform continuous integration. A CI server can be configured to make a build at scheduled intervals immediately when code is committed to the repository. Automated test scripts can be run on the build to ensure that the software behaves as expected after the code integration. It is also possible to deploy the build on testing server after all the tests are successfully passed, and make it available for demo or release. Moreover, some of the CI tools can generate the documentation from the code automatically to support the Quality Control, Release Management and other related activities.

Tools like Git, CVS, SVN, Perforce, Mercurial, Team Foundation, Ant, Maven, Gradle, MSBuild, NAnt, Rake, JUnit, NUnit, Selenium, CppNCSS, TestNG, Xunit, Clover, Cobertura, Emma, Serenity, Sonar, NCover, Checkstyle, PMD, Dry, Findbugs, Warnings, CCM, Violations, LDAP, Active Directory, Crowd, Weblogic, Glassfish, Tomcat, JBoss, EC2, Virtual Box, VmWare, and JCloud are an important part of any developer toolkit, and can augment and support continuous integration initiatives to create a flexible integration environment that is easier to maintain and upgrade.

CI tools can generate various reports and notify developers about any conflicts or errors in the integration so that they can fix the problem immediately. In short, Continuous Integration ensures that the code residing on the repository is stable, tested and deployable at any point in time.

Hasan Sunasara Who loves to design, develop and tune Java Enterprise Applications. I strive to learn new things and improve on every possible areas touched by on the path of life. When not working on Java, I socialize, read blogs and watch movies.