Many articles have been published on XP, which describe excellently, e.g. how the various practices of XP work. However, frequently it is the small, apparently minor issues that could become major road blocks.
This article describes some of these subtle things such as the configuration of a revision control system (RCS) or the use of user accounts and the administration of user rights, in order to optimally support XP.
A first problem, which arises during pair programming, is, which user account should be used on the development machine. The account of one of the partners cannot be used, as right in the middle of the working through a task partners may be switched.
The solution, which works well for us, is as follows: For each development machine we have created another account. This "virtual user" has all rights of the local administrator, so that it can also be used to install additional development tools. Creativity is king when selecting names for this kind of user accounts. We have decided to use John Doe, Joe Blogs, and Jane Fine. Previously we have also used the names of Amercian presidents and of the toon characters of Walt Disney.
For each development machine we need one virtual user. For the integration machine we have created an additional user. How these virtual users work with the revision control system, will be described in the next section.
Some tests may required a login, e.g. for a web site that allows only for authenticated users. As the virtual users are assigned to one machine, they cannot be used for such tests as they should run on all the development machines and also the integration machine.
For this scenario we have created yet another virtual user. He is named Tom Tester. All tests, which required a login, use this virtual user's account. This does not mean, that any pair is using the account to log into the system, but it means that in the source code the credentials of that user is being used.
After a pair has selected a user story (or a task of a story), the pair logs into the development machine using the account of the virtual user that has been assigned to the particular development machine. Then all the required source files are checked out and can be edited. In this case no lock is set for any of the files.
After the pair has finished its task and wants to integrate the changes, the pair closes all development tools (in order to avoid file sharing problems) and then moves on to the integration machine. Only the virtual user of the development machine has the right to check in new versions.
At the integration machine the pair gets the latest version of the system from the RCS. Then a merge tool is employed to merge the local copy with the modified files, which are available on a share of the development machine. As a merge tool we have figured out that "Araxis Merge" seems to be a good choice as it wellsuited for rapid integration.
We have also experimented with the merge capabilities of MS SourceSafe and of CVS. Both of them require you to branch first, then you can merge. However, as we work on one single version stream (at least now, at least conceptually), we figured out that this is more complicated than using a plain merge tool. It is worth the investment and you don't have to go crazy figuring out whether version 1.2.5376.3 can be merged with version 1.2.5370.2.
After the merge is finished all sources are compiled, and all tests are executed. If and only if all the tests run successfully, the new version is checked into the RCS. Testing at this stage includes not only all the unit tests but also all acceptance tests.
The configuration of the permissions is as follows. There is exactly one virtual user, who has the right to check in new revisions of the system. This user has the permission to log into a system at the integration machine only. This enforces the policy that only at the integration machine, new revisions can be checked in.
All other virtual users - the ones assigned to the development machines - have read-only access to the RCS. Furthermore, the virtual users can log in to only the development machine they have been assigned to. Finally, no virtual user of a development machine can lock any file in the RCS.
A final note: Of course, we also have normal user accounts for each team member. However, with these accounts, the RCS cannot be used. In other words: whoever wants to work productively, has to go to a development machine and has to log in there using the account of a virtual user.
© Copyright 2001-2002 by Manfred Lange, All rights reserved. Terms of use.
Last change: