Top 5 Tips to Avoid “Integration Hell” with Continuous Integration

Inevitably, developers are forced to delay pushing fixes and features because other parts of the code aren’t ready. “Integration Hell” earned its name because clients are missing out on the latest version of the application–and because it negatively impacts team morale.


Continuous Integration is a software development practice involving “integrating” updates multiple times a day. The process is designed to catch problems early on and prevent Integration Hell. Development teams typically write higher quality code, receive immediate notification of broken code, experience reduced deployment time, and see a boost in confidence when using the CI approach to development.

The following five tips can help developers create a better experience working with CI:

1) Commit Code Frequently

CI works best when making frequent small, incremental changes to the application. Clients don’t have to wait weeks between releases for fixes and new features. Organizationally, frequent updates prevent developers from stepping on each other’s toes, because problems are typically fixed before a second developer takes a look. With CI, teams spend less time delegating tasks, can take action immediately, and use work time more efficiently.

2) Fix Broken Builds Immediately

Pushing high-frequency updates allows the development team to address broken builds and programming bugs with minimal time between identifying the problem and pushing a fix. Developers using CI should fix problems immediately to get the most out of the practice.

3) Split the Code: Feature Branches

Organizing and separating application code furthers much of CI’s selling points. Multiple developers work with hundreds of files, scripts, and templates that all contribute to a larger application. Separating the code allows for independent updates of smaller parts of a larger system element. The development team can push an update to a smaller segment of the code without worrying about pushing unfinished updates in larger code groupings. Splitting the code makes managing the project easier and allows for reverting smaller code segments–thus losing less work–when there’s a problem with an update.

The “Feature Branch” approach, which works well with CI, involves removing code from the “trunk,” or main part of the code, so features can be added or upgraded over a longer period of time without disrupting the CI programming flow. Branches are a temporary thing: The relevant code is pulled out of the main application for work and then returned when work is completed. The feature branch approach keeps all end users on the most recent version of the application, which avoids the need to support multiple versions of the same product.

4) Rely on Automation

CI servers are a huge asset in avoiding Integration Hell. Developers can push code as soon as they believe it is ready for use, and the server runs tests on that code to identify problems the developers may have missed. The CI server acts as a gatekeeper and alerts developers of problems with the code so they can fix it for the next update push. This means the development team doesn’t need to worry as much about pushing bad code live; they can spend less time debugging, and more time developing. The one downside is that CI servers require additional setup costs and programming.

5) Use Feature Toggles

Unfinished features can hold up the development process and delay updates. Development teams can work around hang-ups by programming toggles for in-progress features. These are simple “true/false” tests that can be controlled with a variable that either enables or disables a feature. The team can remove the toggle when the feature is ready for production.

Wondering if Continuous Integration is right for you? Get in touch with us at Apica today.