Continuous Integration mit Java und JavaScript, Teil 1: Die Kunst der Versionierung
Continuous Integration ist ein seltsamer Begriff. Das vorangestellte Wort "Continuous" betont die Integration. In der Praxis bedeutet es jedoch eher "Integrating continuously", denn die Integrationsprobleme halten Projekte auf, nicht die Frequenz.
- Dragan Zuvic
Continuous Integration ist ein seltsamer Begriff. Das vorangestellte Wort "Continuous" betont die Integration. In der Praxis bedeutet es jedoch eher "Integrating continuously", denn die Integrationsprobleme halten Projekte auf, nicht die Frequenz.
Ein unabhängiges Softwareprojekt integrieren zu wollen, ist eine Sysiphusarbeit. Sobald die Softwareentwicklung arbeitsteilig ist, muss entschieden werden, welche Module in welchen Versionen zusammen eine Einheit bilden. Benutzen Tester- oder Endanwender eine derartige Multi-Modul-Software, ist es unabdingbar zu wissen, aus welchen Teilen die Software besteht und welchen Stand (Version) das jeweils verwendete Modul hat. In der Zusammenarbeit zwischen Testern und Entwicklern sollte durch eine Benennung des Standes einer Multi-Modul-Software das vom Tester gemeldete Problem eindeutig auf einen Stand im Versionskontrollsystem abbildbar sein.
Das Grundproblem heißt Reproduzierbarkeit
Speziell bei mehreren Versionen und kundenspezifischen Auslieferungen darf der Überblick dabei nicht verloren gehen. Konzepte wie Continuous Integration (CI) helfen bei der Identifizierung inkompatibler Versionsstände. Hierbei wird bei einer kontinuierlichen Integration aller Module ein internes Release eines Systems erzeugt – so zumindest die ursprünglichste Definition von Grady Booch [1]. Durch das kontinuierliche Bauen der Software werden ebenso regelmäßige Modultests (Unit-Tests) aller Softwarebausteine durchgeführt. Beim Erstellen einer Multi-Modulsoftware existiert mindestens ein Integrationsprojekt, das die bisher erstellten Artefakte einbindet. Tests über solche oder nachgelagerte Projekte in Bezug auf die gleichzeitige Funktionsweise unabhängiger Module werden als Integrationstest bezeichnet. Sie dienen dazu, Bugs, die durch die Integration der Module entstehen, frühzeitig zu erkennen.
Wenn beispielsweise die Schnittstelle eines Lieferanten geändert wird, ohne die abhängigen Module zu benachrichtigen, sind solche Bugs vorprogrammiert: Die Modultests des Lieferanten weisen keinen Fehler auf. Ein davon abhängiges Modul ist dagegen zu der neuen Version des Lieferanten inkompatibel und wird noch mit der Vorgängerversion entwickelt. Solche Fehler erst bei der Auslieferung zu entdecken, bedeutet fast zwangsläufig eine verzögerte Auslieferung.
Durch das kontinuierliche Bauen der aktuellen Versionen lassen sich solche Probleme rechtzeitig entdecken. Die Tester können die Fehlerbeschreibung jedoch nicht dokumentieren, da das Wissen über die verwendeten Stände bei der simplen Form des Bauens mit der jeweils aktuellen Version verloren ging. Die Reproduzierbarkeit der Builds ist eine Grundvoraussetzung für den effizienten Einsatz von Techniken wie Continuous Delivery.
Die Herausforderungen sind vielfältig
Organisationsstrukturen haben zusätzlich einen großen Einfluss auf die Art des Bauens von Multi-Modulsoftware. Deren genauere Untersuchung würde den Rahmen dieses Artikels sprengen, aber die Effizienz des Bauprozesses hängt durchaus von der Kenntnis über die unternehmensspezifischen Gegebenheiten ab. Zu den wichtigen Faktoren gehören unter anderem die Anzahl der Testsysteme, die Art der Abschottung eines Produktionssystems, der Zugriff auf externe Netze, die Anzahl der Teams und die Fähigkeit der Zusammenarbeit untereinander. Ein Überblick über die verfügbaren CI-Techniken unterstützt die Auswahl einer passenden Vorgehensweise in der eigenen Organisation.
Im Laufe der Jahre haben sich in verschiedenen CI-Projekten des Autors immer wieder die folgenden Bereiche als "neuralgisch" herauskristallisiert: Build-System, Repository-Struktur, Dependency-Mechanismen, Projekt-Organisation und letztlich auch das Zielsystem beziehungsweise die Varianten des Endprodukts. Die einzelnen Bereiche werden zuerst unabhängig von einer spezifischen Technik betrachtet und in einem Folgeartikel an einem Beispielprojekt näher untersucht.
