Praktische Tipps für XP

Übersicht

Es gibt viele Veröffentlichungen zum Thema XP, die sehr schön beschreiben, wie zum Beispiel die verschiedenen Arbeitsmethoden von XP funktionieren. Häufig sind es aber gerade die Kleinigkeiten, die bei der täglichen Arbeit zum (kleinen?) Hindernis werden können.

Dieser Artikel beschreibt diese "Kleinigkeiten" wie beispielsweise eine mögliche Konfiguration von Versionskontrollsystemen oder der Einsatz von Benutzerkonten und die Verwaltung von Rechten, um den XP-Ansatz optimal zu unterstützen.

Der virtuelle Benutzer

Ein erstes Problem, das beim paarweisen Programmieren auftaucht, ist die Frage, mit welchem Benutzerkonto (account) auf dem Entwicklungsrechner gearbeitet werden soll. Es ist ja immerhin möglich, dass neue Paare gebildet werden, bevor eine Benutzergeschichte abgeschlossen wurde.

Die Lösung, die bei uns gut funktioniert, ist diese: Wir haben für jeden Entwicklungsrechner ein weiteres Benutzerkonto eingerichtet. Dieser "virtuelle Benutzer" hat lokal alle administrativen Rechte, damit auch bei der Installation von eventuell zusätzlich erforderlichen Entwicklungswerkzeugen keine Probleme auftreten. Bei der Namenswahl für solche Benutzerkonten kann dann der Fantasie freier Lauf gelassen werden. Wir haben uns für John Doe, Joe Blogs und Jane Fine entschieden, aber die amerikanischen Präsidenten oder die Figuren von Walt Disney mussten auch schon herhalten.

Jeweils ein virtueller Benutzer wird für jeden Entwicklungsrechner benötigt. Für die Integrationsmaschine wird ein weiterer virtueller Benutzer verwendet. Wie diese virtuellen Benutzer mit dem Versionskontrollsystem zusammenarbeiten, beschreibt der folgende Abschnitt.

Virtueller Benutzer für Tests

Da die virtuellen Benutzer jeweils nur einem Rechner zugeordnet sind, können sie für Tests, die einen Login benötigen, nicht verwendet werden. Denn alle Tests sollen ja nicht nur auf einer Entwicklungsmaschine, sondern auf allen Rechnern funktionieren. Dieses Szenario taucht beispielsweise auf, wenn man mit HTTPUnit eine Website testet, die nur nach einem erfolgreichen Login benutzt werden darf.

Für diesen Zweck haben wir einen weiteren virtuellen Benutzer eingeführt. Bei uns heisst er "Tom Tester". Alle Tests, die einen Login am System benötigen, werden unter Verwendung dieses Logins implementiert. Das heißt nicht, dass sich das Programmierpaar damit einloggt, sondern lediglich, dass im Quelltext der Tests "Tom Tester" sowie sein Passwort an den entsprechenden Stellen verwendet werden.

Die Konfiguration des Versionskontrollsystems

Wenn sich ein Programmiererpaar eine Benutzergeschichte (oder eine Aufgabe davon) ausgewählt hat, so logt (sp?) es sich an einem freien Entwicklungsrechner mit dem Benutzerkonto des virtuellen Benutzers, der diesem Entwicklungsrechner zugeordnet ist, ein. Dann können dort die benötigten Quelltexte ausgecheckt und bearbeitet werden. In diesem Fall wird für die benötigte Datei keine Sperre im Versionskontrollsystem gesetzt.

Wenn die Aufgabe bzw. die Benutzergeschichte beendet ist, und der geänderte Quelltext integriert werden soll, logt sich das Paar wieder aus und geht zur Integrationsmaschine. Dort wird der virtuelle Benutzer der Integrationsmaschine verwendet. Nur dieser hat das Recht, neue Quelltextversionen einzuchecken.

Das Programmierpaar holt sich nun den letzten Stand der Quelltexte aus dem Versionskontrollsystem. Dann wird das Merge-Tool gestartet. In die lokalen Dateien - die ja dem letzten Integrationsstand entsprechen - werden jetzt die Änderungen, die auf dem Entwicklungsrechner zur Verfügung stehen, eingepflegt. Als sehr hilfreich hat sich bei uns ein Mergetool mit dem Namen "Araxis Merge" herausgestellt.

Bevor dann die neue Version eingecheckt wird, werden nochmals sämtliche Tests ausgeführt. Dazu gehören natürlich alle bereits implementierten Akzeptanztests aber auch alle Komponententests.

Die Konfiguration hinsichtlich der Rechte ist wie folgt. Es gibt genau einen dedizierten virtuellen Benutzer, der neue Versionen in das Versionskontrollsystem einchecken darf (bei uns ist das Jane Fine). Dieser Benutzer ist der Integrationsmaschine zugeordnet. Nur von der Integrationsmaschine aus kann eine neue Version des Systems eingecheckt werden.

Die anderen Benutzer für die Entwicklungsrechner können nur lesend auf das Versionskontrollsystem zugreifen. Außerdem kann sich jeder dieser virtuellen Benutzer nur auf dem jeweils zugeordneten Entwicklungsrechner einloggen. Schließlich kann auch keiner dieser Benutzer eine Datei im Versionskontrollsystem sperren.

Noch eine Bemerkung: Natürlich haben wir auch Benutzerkonten für jeden Mitarbeiter. Diesen Benutzerkonten sind jedoch keinerlei Rechte für das Versionskontrollsystem zugewiesen. Mit anderen Worten: Jeder, der produktiv am System arbeiten will, kann dies nur an einer Entwicklungsmaschine tun, und nur mit einem Konto eines virtuellen Benutzers.

Tipps

• Um die virtuellen Benutzerkonten einfach verwenden zu können, sollten sie alle das gleiche Passwort haben.
• Um einen leichten Austausch von Quelltexten innerhalb des Teams zu ermöglichen, sollte auf allen Entwicklungsrechnern sowie auf der Integrationsmaschine das Verzeichnis, das alle Quelltexte enthält, für den Netzwerkzugriff frei gegeben werden. Dieser Share sollte jedoch nur einen lesenden Zugriff ermöglichen.