Build and Integration Frequency
How are you doing at continuous integration?
In software engineering, continuous integration (CI) is the practice of merging all developers' working copies to shared mainline several times a day. The main aim of CI is to prevent integration problems, referred to as "integration hell.
When embarking on a change, a developer takes a copy of the current code base on which to work. As other developers submit changed code to the source code repository, this copy gradually ceases to reflect the repository code. Not only can the existing code base change, but the new code can be added as well as new libraries and other resources that create dependencies and potential conflicts.
The longer a branch of the code remains checked out, the greater the risk of multiple integration conflicts and failures when the developer branch is reintegrated into the mainline. When developers submit code to the repository, they must first update their code to reflect the repository changes since they took their copy. The more changes the repository contains, the more work developers must do before submitting their changes.
Eventually, the repository may become so different from the developers' baselines that they enter what is sometimes referred to as "merge hell" or "integration hell", where the time it takes to integrate exceeds the time it took to make their original changes.
Continuous integration involves integrating early and often to avoid the pitfalls of "integration hell". The practice aims to reduce rework and thus reduce cost and time.
If you feel the technical debt might be preventing you from having a faster more modular build system that is capable of integrating all pieces of needed software components into valuable product increments, then exposing this weakness might be a way leading to a more frequent conversation on how to approach to a solution.