Avoid “Integration Hell” Using Continuous Integration

Hasan Sunasara relates three scenarios that many development teams can recognize in an article on how not to descend into Integration Hell (see article here):

• Required files don’t get committed. We’re all human – for whatever reason, sometimes a developer forgets to commit a required file. Other team members then find problems in the code after taking the repository update, and project time is lost debugging the problems.
• The Business Analysis team pushes for code updates to validate the changes and demo new functionality to customers. When this happens, the development team loses valuable time because they have to stop what they are doing to perform a build and deploy to the staging server.
• A client finds some bugs in a new release, or requests some minor tweaks be made, which the team knows they need to deliver quickly. The artificial deadline creates a rush to completion, resulting in negative side effects and breaks the previous build.

Not only are these scenarios frustrating to the development team, but according to Hasan they can also delay development schedules, and increase the budget for the overall project. Both the team and the business lose in these scenarios. To combat these scenarios, keep the project on track, and satisfy your customers in a timely manner, Hasan recommends that teams perform Continuous Integration for their builds.

“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 the 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.”

The benefit is that, through Continuous Integration, the development team ensures that code in the repository is stable, tested, and deployable at any point in time. Continuous Integration is a journey in and of itself, and while the shift in process is subtle, it requires a disciplined approach to changing old habits for newer, healthier ones. Test-driven development blazes the trail for Continuous Integration by requiring that the proper unit and integration tests are written up front, ensuring that the merges are feasible from the get go. After the tests are written, code is then developed, ensuring that only working code makes it into the build. As Hasan mentions, automated testing helps the team monitor the health of builds, exposing problems as they happen in real time. Dealing with issues immediately ensures the build is readily deployable, allowing the team to be proactive to requests from the business instead of being reactive.

Here at Datical, we recommend taking things one step further, and bringing the database component into the Continuous Integration process. Datical DB makes it possible to develop database changes hand-in-hand with code changes at the time of creation, as opposed to waiting to make database changes until after code development is completed. This allows the developer to make the pertinent changes all at once, when knowledge of the problem and rationale for the solution are still fresh in his or her mind. It also puts the DBA team in the driver’s seat, proactively validating the database changes in real time, as opposed to having to wait to receive a bundle of changes from development before making the necessary adjustments to the application schema. By doing so, the benefits of Continuous Integration also accrue to the DBA team, as they are now able to solve issues in real time, just as their development brethren can through CI.  Read more about Datical’s approach by downloading our white paper, Extending Branch/Merge Strategy to Database Changes.

Datical DB automates this whole process by integrating with your version control repository, as well as Continuous Integration servers like Jenkins and Atlassian Bamboo. Through the integration with your repository, Datical DB makes it incredibly easy to tag database changes to specific code releases, opening up a world of possibilities for experimenting in code branches. Integration with the CI server ensures changes are tested and validated holistically, making deployments that much easier.