DEVOPSdigest

Inevitably, software and application developers are forced to delay pushing fixes and features because other parts of the code are not ready. "Integration Hell" earned its name because clients are missing out on the latest versions of applications. This can be avoided with continuous integration.

Continuous Integration (CI) 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" – clients that miss out on the latest versions of applications because they are not launched, which also negatively impacts on team morale.

Using the CI approach to development, development teams typically write higher quality code, receive immediate notification of broken code, experience reduced deployment time, and see a boost in confidence.

The following six 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 do not have to wait for 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 is 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 does not 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.

6. Include Load and Performance Tests as Part of CI

Changes to a source repository done by the developers can be automatically detected and tested for load and performance. After the tests are complete, the built code is deployed to staging servers for testing from where additional tests are run such as integration or load tests. Upon the successful completion of those tests, the tested and approved code is deployed to production instances.