Integration: Approaches and Strategy

Integration

Integration is one of the most difficult tasks in development with large teams. It is only after a successful integration that all the effort from all the different teams on the project becomes visible and testable. It requires a huge amount of coordination effort and is a technical challenge, both of which can be made easier by using tools.

It is common sense that integration should be done centrally. Otherwise, it will not be integration, but several subintegrations, which in turn will all have to be integrated later on anyway. Consequently, integration is a bottleneck, which becomes increasingly difficult as more and more tasks have to go through.

Teams often argue that they cannot establish short development cycles because integration takes so long (or they fear that it will take so long). Therefore, they prefer to integrate as seldom as possible. Sometimes they even defer integration to the very end of the whole development. However, integration is always more difficult if we have to integrate a lot of changes.

On the other hand, the more often we integrate, the better we get in terms of tools, coordination, and technology. So, we might have to invest in integration at the beginning in order to benefit from it later on.

Normal-sized (small) agile teams often integrate using a token or a single integration machine: only the team member with the token or sitting at the integration machine is allowed to integrate their local changes with the common code base.

With large teams, neither the token nor the integration machine is in sight of everybody. We can consider passing the integration token via email, but even then, we might encounter the problem that integration (which includes running all tests) takes so long that it will be completely impossible for several teams to integrate frequently.