Sunday, January 25, 2004

Class Ownership #3 - Regular Integration

Class Ownership and Continuous Integration don’t mix!

However, class ownership and regular integration might be a best of both worlds solution!

As I mentioned, the other day, class ownership forces team working. However, there is a side effect to team working and the use of most popular version control and continuous integration tools - it is impossible for two team members to check-in code simultaneously! If two (or more) people have been collaborating on a single Feature and one is adding methods which the other must use, or indeed modifying method signatures from existing code, then when the first developer checks-in, the build will break. Not until the second (or subsequent) developer checks-in his updates will the continuous build recover.

The problem with continuous integration is that it overloads two concepts - check-in, a mechanism for safe storage, version history, and file sharing - with build, a mechanism for integration of the code. This becomes problematic when mixed with class ownership.

FDD has an explicit Promote-to-Build milestone for every Feature. What does this mean? It means simply that check-in can happen multiple times throughout the development of a Feature. Several owners can check-in and check-out as they see fit. In fact, check-in should happen every night. What happens if the developer is off sick tomorrow? Unless they have checked-in so that their secondary class owner can takeover, a Feature might get blocked. FDD relies on a 2-stage promotion process. Check-in happens to a revision labeled “dev” area in the version control. The Chief Programmer or Development Manager has the right to “promote to build” which is a process of relabeling check-ins. Only the revisions labeled “build” are built.

In FDD, the continuous integration process would run on the “build” revisions. As Work Packages of Features are only promoted to build (relabeled as “build” revisions) when the Work Package is complete and reviewed, then there is an inevitable delay between check-in and the basic integration test of compiling the build. This process might better be called regular integration. By encouraging the development of small batches, there is still basic integrated compile checking happening frequently to highlight problems early. This meets the spirit of the continuous integration movement in agile methods, whilst delivering the long term quality and integrity benefits of class ownership.