Continuous Integration - Just another buzz word?

merge codelines without the intermediate step of merging them into a workspace and performing integration testing prior to checking the changes into the repository.

Can Continuous Integration and Component Based Development work together?

It appears on the surface that these two approaches conflict with one another. However, there may be some room for a hybrid solution.

Component Based development teams break off into their own areas to develop components without integration with the other component development teams. Creating unique active development codelines for each component is oftentimes the way to manage this. If you can make the assumption that the components will never intersect, then you can have them all part of the same codeline. The thought is that there are benefits to waiting until the latest possible moment to decide which component versions make it into the release. This approach typically involves a significant integration effort just prior to the formal release build, and almost always creates integration problems the first time all of the components are brought together.

The hybrid approach starts with implementing Continuous Integration within the component teams to ensure that the component codeline is of high quality and integrated within itself. Second, always integrate a component codeline to the release codeline or release workspace, independent of a formal release build. This process can even be automated - upon completion of the integration building of the components, the successful component builds are brought together in an "assembly integration" and form a "system-level integration build." As a final thought on this topic, there should never be a codebase convergence (branch merge) that doesn't involve a workspace integration effort with developers and the SCM group working together in harmony to ensure proper integration before checking in the integrated workspace changes.

Up Next!

Next month we will address in more detail the different build types, workspace management and coordination for incorporating changes into the SCM repository.

References

[1] Continuous Integration , by Martin Fowler & Matthew Foemmel; see

www.martinfowler.com/articles/continuousIntegration.html

[2] Integrate Often , by Don Wells; see www.extremeprogramming.org/rules/integrateoften.html

[3] Managing Complexity: Keeping a Large Java Project on Track , by Tom Copeland; see

www.onjava.com/pub/a/onjava/2003/09/10/dashboard.html

[4] Characteristics of the Agile SCM Solution , by Brad Appleton, Steve Berczuk, & Steve Konieczka; CM Crossroads Newsletter, June 2003