Sequential Integration   Continued from page 1 These solutions do not address the root problem. You want developers to be able to proceed in parallel, courageously making changes to any part of the system required, but you also want an error free integration of those efforts. Like a dozen steaming locomotives headed for the switch house all at the same time, there is going to be trouble. Instead of restricting development to being sequential, or requiring complex integration procedures let's rethink the problem. Our locomotives can all get into the switching house without a crash if they just take turns. We need to do this with code integration as well. Strictly sequential (or single threaded) integration by the developers themselves in combination with collective code ownership is a simple solution to this problem. All source code is released to the source code safe or repository by taking turns. That is, only one development pair integrates, tests and releases changes to the source code repository at any given moment. Single threaded integration allows a latest version to be consistently identified. This is not to imply that you can not integrate your own changes with the latest version at your own workstation any time you want. You just can't release your changes to the team with out waiting for your turn. Some sort of lock mechanism is required. The simplest thing is a physical token passed from developer to developer. A single computer dedicated to this purpose works well if the development team is co-located. Integrating and releasing code often shortens the time needed to hold the lock and thus reducing the wait time to acquire the lock. ExtremeProgramming.org home | XP Rules | Integrate Often | Email the webmaster Copyright 1997, 1999 J. Donovan Wells all rights reserved.