Best Practices aus dem Software-Konfigurationsmanagement für die Kontinuierliche Integration

Software-Konfigurationsmanagement Best Practices aus dem Software-Konfigurationsmanagement für die Kontinuierliche Integration Agile Softwareentwicklungsmethoden sind mittlerweile sehr ausgereift und finden immer breitere Anwendung. Deshalb gewinnen sicher und gut funktionierende Verfahrensweisen zur durchgängigen Umsetzung Agiler Methoden in allen Phasen der Softwareentwicklung zunehmend an Bedeutung. Ohne diese Verfahrensweisen können Versuche, die Softwarequalität durch Agile Methoden zu verbessern, leicht scheitern. Es wird dann den Softwarefirmen eine wichtige Chance genommen, ihren Kunden qualitativ bessere Software zu liefern. Dieses Papier stellt das Konzept der Kontinuierlichen Integration vor und erklärt im Detail einige bewährte Methoden für das Software-Konfigurationsmanagement (SCM vom englischen Software Configuration Management), die bei der Einführung der Kontinuierlichen Integration helfen können. Überblick zum Thema Kontinuierliche Integration Die Kontinuierliche Integration, einer der fundamentalen Aspekte der Agilen Softwareentwicklung, wurde von Martin Fowler als ein vollautomatischer und reproduzierbarer Build, inklusive Tests, definiert,... der mehrmals am Tag laufen kann. Dies erlaubt jedem Entwickler, täglich zu integrieren und somit Integrationsprobleme zu verringern. 1 Durch die Erweiterung der Idee eines nächtlichen Builds, bei dem Codeänderungen jede Nacht kompiliert und getestet werden, hilft die Kontinuierliche Integration, Integrationsprobleme zu minimieren und Probleme schneller zu erkennen und zu lösen. Durch die Kontinuierliche Integration werden Entwickler ermutigt, das gemeinsam genutzte Sourcecode- Repository häufig upzudaten, idealerweise sogar mehrmals täglich. Nach jedem Update gibt es einen neuen Build- und Testzyklus. Die Ergebnisse dieses Prozesses werden dann an alle Mitglieder des Entwicklungsteams berichtet. Das stärkt die Kommunikation über die Qualität der vorgenommenen Code- Changes innerhalb der Gruppe. Es treten auffällig weniger Fehler während des Entwicklungsprozesses und im ausgelieferten Produkt auf, da den Entwicklern Probleme eher auffallen und es weniger zu prüfende Änderungen während der Fehlerbeseitigung gibt. Unternehmen, die in der Softwareentwicklung tätig sind, können auf bewährte Methoden des Software- Konfigurationsmanagements zurückgreifen, um Kontinuierliche Integration einzuführen und zukünftig von deren Vorteilen zu profitieren. Die Methoden umfassen: die Nutzung eines SCM-Systems, um den kompletten Sourcecode zu verwalten und zu versionieren die Einbeziehung von privaten Workspaces der Entwickler die Freigabe lokaler Entwickler-Builds häufige Updates des Codes im SCM-System die Einführung einer Staging- und Isolationshierarchie und automatische Builds für alle Stufen der Hierarchie Im Folgenden werden diese Verfahrensweisen beschrieben und praktische Hinweise gegeben, wie man ein SCM-System am besten konfiguriert und benutzt, um eine kontinuierliche Integrationsumgebung optimal zu gestalten. 1 Siehe Martin Fowlers Continues Integration Webseite

Best Practices für die Kontinuierliche Integration Nutzung eines SCM-Systems, um den kompletten Sourcecode zu verwalten und zu versionieren Softwareentwicklungsprojekte sind fast immer Parallelentwicklungen, bei denen mehrere Entwickler Änderungen am Projekt vornehmen, die integriert werden müssen, um das Projekt zu kompilieren. Weiterhin müssen alle Änderungen in jedem Teil des Systems erfasst werden, um mögliche Probleme zu identifizieren und zu lösen. Aus diesem Grund ist es wichtig, ein Software- Konfigurationsmanagementsystem (SCM) einzusetzen, um jede Änderung am Code strikt mit einer Versionsnummer zu versehen. Zudem muss natürlich alles, was zum Kompilieren des Systems benötigt wird, durch Versionsnummern gesteuert werden. Dazu gehören: Externe Bibliotheken Property-Dateien Datenbankschemata Testskripte Installationsskripte Jeder Entwickler sollte mindestens Lesezugriff auf all die Dateien haben, die für den Build notwendig sind und sollte diese Dateien immer direkt aus dem SCM-System ziehen. Dieser Ansatz garantiert, dass die Entwickler mit der neuesten Kompilierumgebung arbeiten und sollte dem landläufigen, aber fehleranfälligen Platzieren dieser Dateien auf einem gemeinsam genutzten Dateiserver-Laufwerk vorgezogen werden. Soweit möglich sollten die Entwickler den neuesten Sourcecode und die Konfigurationsdateien automatisch aus dem SCM-System bekommen, um sicherzustellen, dass wirklich immer die richtigen Konfigurationen benutzt werden. Dies ist insbesondere dann wichtig, wenn an verschiedenen, geographisch verteilten Standorten an ein und derselben Software gearbeitet wird. Geht man an die Sache mit einem gemeinsam genutzten Dateiserver heran, ist es sehr schwierig, Veränderungen zwischen den Gruppen zu synchronisieren, die sich an verschiedenen Standorten und in möglicherweise unterschiedlichen Zeitzonen befinden. Um die Kontinuierliche Integration effektiv zu implementieren, sollten alle Entwicklergruppen auf der gleichen zentralen Sourcecode-Datenbank arbeiten, so dass die neuesten Änderungen aller Entwickler stets einfach und sofort verfügbar sind. Einbeziehung privater Workspaces der Entwickler Um den vollen Nutzen aus der Kontinuierlichen Integration zu ziehen, müssen Softwareentwicklungsunternehmen sicherstellen, dass der einzelne Entwickler unabhängig vom Zustand und der Stabilität des Sourcecodes des Gesamtprojekts produktiv bleiben kann. Das wird erreicht, wenn private Entwickler-Workspaces verwendet werden, die vollständige SCM-Funktionalität bieten. Private Workspaces erlauben den Entwicklern isoliertes Arbeiten, bei Bedarf die Rückkehr zu stabilen Zuständen, die Überprüfung ihrer Änderungen die Weitergabe von ausschließlich funktionierendem, gut getestetem Code an die anderen Gruppenmitglieder. Der Nutzen der Isolation geht in zwei Richtungen. Zum einen schützt sie den einzelnen Entwickler vor hereinkommenden Codeänderungen, zum anderen schützt sie die gemeinsam genutzte Codebasis vor unvollständigen oder falschen Änderungen irgendeines Entwicklers. Durch die Schaffung von 2

privaten Entwickler-Workspaces kommt der einzelne Entwickler in den Genuss aller Vorteile eines SCM-Systems, inklusive der Möglichkeiten zu einem früheren Entwicklungsstand zurückzukehren, alle Änderungen der Software einzusehen und zu verfolgen und bestimmte Änderungen auf einen späteren Zeitpunkt zu verschieben, um zwischenzeitlich an einer anderen Aufgabe zu arbeiten. Wenn eine Entwicklungsaufgabe abgeschlossen ist (z.b. wenn ein Entwickler die Entwicklung eines Features inkl. Unit-Test beendet hat), sollten Entwickler ihre lokalen Änderungen durch check in bzw. keep im SCM-System festhalten und entsprechend kennzeichnen. Verschiedene Hersteller benutzen unterschiedliche Termini für diesen Vorgang, das Konzept ist aber stets das gleiche: die Arbeit auf dem SCM Server speichern, so dass die Änderungen dort persistent gelagert sind und einfach wieder geladen werden können. Dieser Teil des Prozesses sorgt dafür, dass die Arbeit des Entwicklers sicher auf dem SCM landet und dieser Status jederzeit wieder hergestellt werden kann. Dadurch, dass die Änderungen noch nicht freigegeben sind, sind andere Entwickler durch diesen Vorgang nicht betroffen. Wenn ein Entwickler die Isolation aufgibt und sich dafür entscheidet, den veränderten Code für die anderen zugänglich zu machen, nimmt er für sich in Anspruch, dass die Änderungen einen höheren Reifegrad erreicht haben. Dieses Vorgehen, gepaart mit der Verwendung lokaler Entwickler-Builds, stellt sicher, dass nur wirklich ausgereifter und gut getesteter Code an die anderen Mitglieder der Entwicklungsgruppe weitergegeben wird. Das ist der entscheidende Vorteil der Kontinuierlichen Integration. Einsatz lokaler Entwickler-Builds Wenn das primäre Ziel der Kontinuierlichen Integration darin besteht, die Softwarequalität zu verbessern und Build- und Testproblemen vorzubeugen, dann ist die wahrscheinlich wichtigste SCM- Regel, automatisierte, lokale Entwickler-Builds zu ermöglichen. An dieser Stelle sollten Entwickler Zugriff auf eine lokale Build-Umgebung haben, welche die Umgebung für den späteren, finalen Build perfekt widerspiegelt. Dies beinhaltet: Datenbankschemata Konfigurationsdateien Umgebungsvariablen gemeinsam benutzte Bibliotheken und Dateien bekannte Kompiler/Linker/Laufzeitumgebungen Das alles minimiert das Es-kompiliert-perfekt-auf-meiner-Maschine -Syndrom, das so viele Entwicklerteams plagt. Sobald die Kompilierumgebung verfügbar ist, sollte jede Anstrengung unternommen werden, den lokalen Build zu automatisieren, so dass jeder Entwickler schnell und einfach kompilieren kann, ohne eine Reihe manueller Schritte durchführen zu müssen. Idealerweise sollte jeder Entwickler Zugriff auf eine eigene Build-Umgebung haben, welche die gleichen Werkzeuge benutzt und die gleiche Konfiguration aufweist, wie die Maschine auf der das finale Produkt kompiliert wird. Ein wichtiger Teil der Konfiguration eines lokalen Entwickler-Builds ist, dass der Entwickler darauf trainiert wird, verschiedene Schritte zu unternehmen, die sicherstellen, dass lokale Änderungen nur einen minimalen negativen Einfluss haben, wenn sie den anderen Entwicklern und Teams zugänglich gemacht werden. Diese Schritte sind: Updaten des privaten Workspaces, um den neuesten, veröffentlichten Code zu erhalten Zusammenführung von konkurrierenden Diffs zwischen eingecheckter Konfiguration und privatem Workspace Wenn man sicherstellt, dass die Entwickler die richtige Build-Umgebung benutzen und nur den neuesten Sourcecode mit bereits bereinigten Diffs verwenden, ist die Wahrscheinlichkeit sehr hoch, 3

dass der lokale Build erfolgreich funktionieren wird. Und wenn dieser erfolgreich ist, müsste auch der Build der Kontinuierlichen Integration erfolgreich sein. Häufiges Updaten des Codes im SCM-System Traditionell tendieren Entwickler dazu, das Promoten des Sourcecodes hinauszuschieben, manchmal tagelang, weil sie die anderen Entwickler nicht zu früh beeinflussen wollen oder aber um nicht die Schuld für einen nicht erfolgreichen Build-Vorgang in die Schuhe geschoben zu bekommen. Unglücklicherweise verkehrt sich das ins Gegenteil und führt typischerweise zu noch mehr Problemen, weil mehr Änderungen am Sourcecode durchgesehen werden müssen, wenn ein Build- Vorgang fehlschlägt. Unabhängig davon, ob die Kontinuierliche Integration eingesetzt wird, ist es eine gute Idee, Entwickler dazu zu ermutigen, ihren Code in kleinen Stückchen zu kompilieren, zu testen und zu verteilen. Es ist ein einfacher und effektiver Weg, die Zusammenarbeit im Team zu verbessern und die Kosten durch abgebrochene Build-Vorgänge zu reduzieren. Wenn ein Unternehmen die Einführung der Kontinuierlichen Integration anstrebt, ist es insbesondere wichtig, den Sourcecode im SCM-System oft upzudaten. Die Kontinuierliche Integration repräsentiert einen Paradigmenwechsel in der Softwareentwicklung, bei dem die Betonung auf der Kommunikation zwischen den Entwicklern über die durchgeführten Änderungen liegt. Durch das Teilen von Aufgaben in kleinere Stücke, die in einigen Stunden erledigt sein können, sind die Entwickler in der Lage, sich häufig abzustimmen und ihre Änderungen zu verteidigen. Sie erhalten somit ein direktes Feedback zur Qualität der Änderungen durch die Ergebnisse des kontinuierlichen Integrationsprozesses und die Resultate der Unit-Tests. Wenn das Team sich an den neuen Ansatz gewöhnt hat, können die Entwickler auch ein Gefühl für den Fortschritt entwickeln, indem sie nicht nur sehen, dass die eigenen Änderungen erfolgreich kompilieren, sondern auch, was die anderen Entwickler zur Verfügung stellen. Einführung einer Staging- und Isolationshierarchie Befürworter der Kontinuierlichen Integration schlagen vor, Verzweigungen (branching) so wenig wie möglich zu verwenden und die Entwickler direkt auf der Mainline des Projekts arbeiten zu lassen. Dieser Ansatz verursacht jedoch verschiedene Schwierigkeiten: Man riskiert die Stabilität der Mainline. Es unterstellt, dass traditionelle Verzweigungen der einzig mögliche Isolationsmechanismus sind. Es mindert die Flexibilität und Agilität, die für schnelles, iteratives Entwickeln gebraucht werden. In modernen SCM-Systemen besteht ein besserer Ansatz darin, eine Staging- und Isolationshierarchie für den Entwicklungsprozess zu implementieren. Eine solche Hierarchie benutzt Objekte im SCM-System, um die Abhängigkeiten zwischen Entwicklerteams und Prozessschritten zu repräsentieren. Beispielsweise möchte man gern die folgenden Gruppen und Aktivitäten modellieren: Release-Entwicklung Qualitätskontrolle Produktentwicklung Komponentenentwicklung Jeder Gruppe oder Aktivität ist das Äquivalent eines privaten Workspaces zugeordnet (manchmal, abhängig vom SCM-System, auch streams oder branches /Verzweigungen genannt). Jedes Team nutzt dann die gleichen Vorteile der privaten Workspaces wie die einzelnen Entwickler. 4

Mit einer Staging-Hierarchie bewegen sich Änderungen im Entwicklungsprozess von weniger stabil zu einer stabileren Konfiguration, wenn sie für das nächste Level getestet und für gut befunden wurden. Dies erlaubt die Stabilisierung des Sourcecodes vor einem Release, ohne Stillstandszeiten für die Entwickler. Zusätzlich erlaubt das Staging falls benötigt eine zusätzliche Isolation jedes Teams, so dass die Änderungen eines Teams integriert und getestet werden können, bevor die Komponenten insgesamt integriert werden. Abbildung 1: Typisches Entwicklungsszenario In Abbildung 1 sieht man vier Entwicklungsteams und einen Bereich, auf dem man den Code von Drittanbietern ablegen kann. Die Entwicklungsteams sitzen an geographisch verteilten Standorten. Die Hierarchie repräsentiert den normalen Fluss von Änderungen von Entwicklungsstufe zu Entwicklungsstufe. Die Abbildung zeigt, wie die Änderungen, die vom GUI-Produktentwicklerteam in Indien eingepflegt werden, von deren privaten Entwicklerarbeitsplätzen (diese sind zur Vereinfachung nicht eingezeichnet) in die GUI-Stage fließen, wo sie fortlaufend integriert und getestet werden können. Ausgereifte Änderungen fliessen dann zur UI_int-Stage und zur Qualitätssicherungs- (QA) und Release-Stage (Rel), wobei sie für jeden Schritt noch einmal die Kontinuierliche Integration und Tests durchlaufen. Das Webentwicklerteam in Austin zieht dann gut getestete Änderungen aus der UI_int- Stage und nutzt diese als Basis für seine Entwicklungsarbeit. Wenn die Änderungen an der Webseite ausgereift sind, können diese in der Hierarchie nach oben geschoben werden und werden damit Gegenstand von umfangreicheren Tests in den UI_int-, QA- und Rel-Stages. Die Nutzung einer Entwicklungshierarchie, eröffnet mehr Möglichkeiten definierte Checkpoints zu setzen. Jede Änderung, die in das System aufgenommen wird, ist eine potentielle Fehlerquelle und deshalb ein potentieller Checkpoint. Wenn sich eine Änderung als fehlerhaft herausstellt, kann man sowohl die Quell- als auch die Ziel-Stage auf einen früheren Checkpoint zurücksetzen. Im Unterschied dazu hat man bei direkter Arbeit auf der Projekt-Mainline nur die Möglichkeit einen einzigen Checkpoint zu setzen, nämlich auf der Mainline selbst. Man hat so gut wie keine Chance, den Code auf einem niedrigeren Granularitätsgrad zu kompilieren, zu testen und zu validieren, wenn man nicht die komplette Mainline immer wieder für einen angemessenen Zeitraum einfriert. Die Checkpoints auf der Mainline veralten sofort mit der nächsten Änderung und sind für eine gezielte Fehlersuche in einzelnen Komponenten nur bedingt brauchbar. 5

Automatische Builds für alle Stufen der Hierarchie Um Entwicklern direktes Feedback über die eingecheckten Änderungen zu geben, muß der Code regelmäßig kompiliert werden, idealerweise mehrmals am Tag. Ein kontinuierlicher Integrationsserver wie z.b. CruiseControl, CruiseControl.NET oder Draco.NET kann genutzt werden, um diesen Prozess zu automatisieren. Der kontinuierliche Integrationsserver fragt das SCM-System regelmäßig nach Änderungen ab, schickt diese Daten dann zum Build-Server, startet den Build-Prozess und speichert die Ergebnisse der Build- und Unit-Tests. An dieser Stelle ist es wichtig anzumerken, dass der Server für die Kontinuierliche Integration die existierenden Build-Skripte und die Build-Umgebung nutzen muß, um zu kompilieren. Wenn z.b. das make Kommando benutzt wird, um Komponenten, die in C geschrieben sind zu kompilieren und zu linken, wird der kontinuierliche Integrationsserver das Makefile aufrufen, um den Build-Prozess zu starten. Weil der kontinuierliche Integrationsserver den existierenden Build benutzt, ist es für die Entwicklergruppe wichtig Zeit und Aufwand in die folgenden Aktivitäten zu stecken, den Build so schnell wie möglich machen, Automatische Unit-Tests erstellen und Unit-Tests als Teil des Build-Prozesses begreifen. Es ist wichtig, diesen Punkten die notwendige Aufmerksamkeit zu schenken, selbst wenn sie Mehraufwand dahingehend bedeuten, das Build-System kompatibel zu einer kontinuierlichen Integrationsumgebung zu halten. Es wird nicht nur der Build-Prozess verbessert, sondern auch die Gesamtqualität des Softwarereleases erhöht. Es ist essentiell, die Ergebnisse des Build-Prozesses dem gesamten Entwicklungsteam zur Verfügung zu stellen, sobald die Kontinuierliche Integration verwendet werden soll. Entscheider, die kontinuierliche Integrationssysteme planen, sollten skalierbare Kommunikationsmethoden wie z.b. E- Mail-Benachrichtigungen oder eine interne Webseite vorsehen, um die Ergebnisse anzuzeigen. Kontinuierliche Integrationsserver wie z.b. CruiseControl besitzen eingebaute Web-Reporting- Funktionen, die einfach angepasst werden können, so dass Build-Ergebnisse auf LCD-Anzeigen in allgemein zugänglichen Bereichen an den geografisch verteilten Standorten dargestellt werden können. Auf diese Weise können alle Teammitglieder die Build-Ergebnisse einfach einsehen, darauf schnell reagieren und damit die Verzögerungen verhindern, die durch nächtliche oder wöchentliche Integration oft auftreten. Zusammenfassung Die Kontinuierliche Integration ist kein komplett neues Konzept, wird aber zunehmend von Software entwickelnden Unternehmen als Schlüsseltechnologie im Rahmen des Wechsels zu Agilen Methoden erkannt und eingeführt. Mit einem robusten SCM-System und den Best Practices, die hier beschrieben sind, können Entwicklungsleiter, Leiter der Qualitätskontrolle und Entwickler die Kontinuierliche Integration verwenden, um die Qualität der Software zu verbessern. Die Kosten für Nacharbeiten hinsichtlich abgebrochener Builds werden signifikant sinken und der Wert des Produkts, das der Kunde erhält, wird steigen. AccuRev dankt der Firma für ihren Beitrag zur Übersetzung dieses Dokuments. Copyright 2008 AccuRev, Inc. AccuRev ist ein eingetragenes Warenzeichen von AccuRev, Inc. Alle anderen Waren- oder Markenzeichen, die in diesem Dokument Verwendung finden, sind Eigentum der jeweiligen Inhaber. 6