Fortlaufende Integration

Ein wichtiger Faktor für den Erfolg eines Softwaresystems ist die Schnelligkeit, mit der sich ein System an sich verändernde Anforderungen anpasst. Ein anderer Erfolgsfaktor ist die Geschwindigkeit, mit der Funktionalitäten eines Systems zur Verfügung stehen. Wichtig für die Qualität eines Systems ist es auch, möglichst frühzeitig Rückmeldung über die Stabilität des Systems oder auch den Nutzwert des Systems zu erhalten.

Diese und andere Fragestellungen werden in XP unter anderem mit der Fortlaufenden Integration (eine der 12 Arbeitsmethoden von XP) angegangen. Darunter versteht man die sofortige Integration von fertiggestellten Aufgaben (Komponententests plus modifizierter Quelltext) in das Gesamtsystem.

Die Funktionalität des Gesamtsystems wird in kleine Häppchen zerlegt und sukzessive dem System hinzugefügt. Das geschieht typischerweise in der Form, daß mehrere Programmierpaare gleichzeitig an verschiedenen Aufgaben des Systems arbeiten. Wenn ein Programmierpaar eine Aufgabe fertig hat, geht es zum Integrationsplatz, um die Quelltextänderung zum System hinzuzufügen. Diese Änderungen inclusive der zugehörigen Komponententests stehen damit sofort allen anderen Programmierpaaren zur Verfügung.

Da dieser Vorgang sich sehr häufig innerhalb sehr kurzer Zeit wiederholt, erreicht man eine nahezu sofortige Integration von Quelltextänderungen. Das jeweils entstehende System durchläuft alle bis dahin abgeschlossenen Akzeptanztests sowie alle bis dahin implementierten Komponententests fehlerfrei. Mit anderen Worten: Es steht unmittelbar ein benutzbares System zur Verfügung, dessen Funktionalität reproduzierbar erfolgreich getestet sind.

Durch die sehr kurzen zeitlichen Abstände dieser Integration spricht man von Fortlaufender Integration. Dies steht im Gegensatz zu traditionellen Methoden, bei denen bei weitem nicht so häufig integriert wird. Resultierend daraus ergeben sich zum Teil erhebliche Schwierigkeiten, ein System wieder stabil zum Laufen zu bringen.

Beispiel: Beim Erstellen einer Medizinapplikation wurde im Schnitt ca. alle 2 bis 3 Wochen integriert. Programmierer konnten sich dann natürlich im Normalfall nicht mehr daran erinnern, welche Änderungen sie gemacht hatten. Damit war im Falle eines Fehlverhaltens des Systems nicht nachvollziehbar, welche Änderung die Ursache dafür war. Eine Fehlersuche war dann immer zeitraubend und dauerte zum Teil länger als eine Woche. (Name der Firma sowie des Produktes habe ich aus Gründen der Diskretion weggelassen! Das Produkt wird noch heute verkauft. Quelle: Gespräch mit Betroffenen.)

Die Häufigkeit der Integration hängt sehr von den Verhältnissen im Projekt ab. In unserem Projekt integrieren wir derzeit ca. 4 bis 5 Mal pro Tag, Tendenz steigend. Das ergibt dann pro Woche bei zwei Programmierpaaren 40 bis 50 Integrationen.

Tipps

• Eine Integration erfolgt typischerweise mehrmals am Tag.
• Jede abgearbeitete Aufgabe führt zu einer Integration der Quelltextänderung UND der zugehörigen Modultests.
• Eine Integration wird erst vorgenommen, wenn sowohl der Quelltext als auch die Modultests refaktoriert sind. Erst dann ist die Aufgabe wirklich abgeschlossen.
• Eine Integration kann auch erfolgen, wenn mehr als ein Paar an derselben Methode arbeitet! Ja, das funktioniert!