Softwareentwicklung und Testprozess

Transkript

1 Fakultät für Wirtschaftswissenschaften SEMESTERPROJEKT Softwareentwicklung und Testprozess Modul: Formale Methoden (WS2011/2012) eingereicht von: Thomas Hintze Fernstudiengang Master Wirtschaftsinformatik Betreuer: Prof. Dr. Jürgen Cleve Rostock, den 29. Oktober 2011

2 Inhalt I. Abbildungsverzeichnis...4 II. Abkürzungsverzeichnis Einleitung Problemstellung Abgrenzung Software-Entwicklung und Testprozess Software-Entwicklung Versionsmanagement Anforderungen Begriffe Konzeption Arbeitsweise Problemfelder Praktische Anwendung Resümee Build-Automatisierung Build-Typen Inkrementelle Compilierung Make Ant Integration des Versionsmanagements in den Build-Prozess Verteilter Build-Prozess Praktische Anwendung Resümee Testprozess Testautomatisierung Regressionstest Integration des Regressionstests in den Build-Prozess Oberflächentest Problemfelder Resümee

3 2.2.2 Defektmanagement Fehlerdatenbanken Anwendung Crash Reports Resümee Bewertung des Praxisbeispiels Ist-Zustand Soll-Konzept Bewertung Resümee und Ausblick Ehrenwörtliche Erklärung Literatur

4 I. Abbildungsverzeichnis Abbildung 1: Grobdarstellung der Software-Entwicklung...9 Abbildung 2: Produktdiversifizierung bei Software-Produkten...11 Abbildung 3: Software-Entwicklung und Testprozess...12 Abbildung 4: Überblick Versionsverwaltung...16 Abbildung 5: check in/check out/revert...17 Abbildung 6: branching...18 Abbildung 7: merging...19 Abbildung 8: Merge-Konflikt...20 Abbildung 9: Konfiguration SVN-Interface im Powerbuilder...22 Abbildung 10: Powerbuilder check out...23 Abbildung 11: Differenzen-Anzeige...24 Abbildung 12: Beispiel eines Abhängigkeitsgraphen...27 Abbildung 13: Beispiel eines dezentralen Build-Prozesses...32 Abbildung 14: Build-Einstellung im Powerbuider Abbildung 15: Regressionstest auf Kommandozeilenebene...36 Abbildung 16: Vergleich von begleitendem und abschließendem Testen...37 Abbildung 17: Eröffnung eines Service-Requests für ein Oracle-Produkt...42 Abbildung 18: Lebenszyklus einer Anomalie in Bugzilla...44 Abbildung 19: Beispiel-Chart eines zeitlichen Verlaufs korrigierter Anomalien...45 Abbildung 20: Software-Entwicklung und Testprozess

5 II. Abkürzungsverzeichnis ADR = Automatic Diagnose Repository ant = Another Neat Tool awt = Abstract Window Toolkit CGI = Common Gateway Interface CLI Command Line Interface CSV = Comma Separated Values HTML = Hypertext Markup Language IPS = Incidient Packaging Service pbl = Powerbuilder Library QTP = QuickTest Professional SR = Service Request SVN = Subversion TAR = Technical Assistance Request XML = Extensible Markup Language zip = Zipper -5-

6 1 Einleitung Software-Fehler sind allgegenwärtig. Zu bedeutsamen, öffentlich gewordenen Fehlern zählen beispielhaft das Jahr-2010-Problem der Banken und Sparkassen 1, Fehler in der Patriot Luftabwehr2 während des ersten Golfkrieges, Fehler im Abfertigungssystem der Lufthansa 3 oder auch ein mehrstündiger Ausfall des gesamten Handels an der Tokioter Börse 4. Durch systematische Software-Tests vor Inbetriebnahme der Systeme hätte vielleicht der eine oder der andere Fehler verhindert werden können. Selbst das Entwickeln kleiner isolierter Software-Programme oder -module wird von Programmierern heutzutage kaum ohne zeitnahe Tests erledigt. Das hier zumeist vorherrschende Trial and Error -Prinzip5 kann bei überschaubarer Komplexität zu durchaus akzeptablen Ergebnissen führen. Sollen jedoch umfangreiche Software-Systeme industriell entwickelt werden, kann sich das Austesten der Entwicklungsergebnisse ebenso aufwändig gestalten, wie die Entwicklung der Systeme selbst. Gerade dann, wenn mehrere Entwickler an einem Projekt beteiligt sind, ist neben der reinen Programmierungs- und Testarbeit noch eine beachtliche Anstrengung für die Koordination und Kommunikation6 der Entwicklungsprozesse und den nebenläufigen Testprozessen notwendig. Mit aktuellen Entwicklungssystemen und Softwaretools lassen sich Software-Infrastrukturen installieren, mit denen eine konfliktarme gemeinsame Arbeit am Software-Projekt möglich ist. Hierbei helfen Versionsverwaltungssysteme und Build-Automatisierung ebenso wie Testautomatisierung und Defektmanagement7 nicht nur die Produktivität der SoftwareEntwickler zu steigern. Sie sind auch dazu geeignet, der Projektleitung Status- und Statistikinformationen als Input für das projektbezogene Risikomanagement, für die weitere Projektplanung oder die Abrechnung zu liefern. 1.1 Problemstellung Vor allem große umfangreiche Software-Systeme durchlaufen mit fortschreitender Zeit einzelne Lebenszyklen. Dabei müssen nach der initialen Erstellung geänderte Anforderungen implementiert werden, um das System weiterhin einsetzen und zweckorientiert nutzen zu Mio. EC-Karten mussten getauscht werden, weil der Jahreswechsel 2009/2010 nicht verarbeitet werden konnte. Es entstand ein Schaden in dreistelliger Millionenhöhe (SPIEGELONLINE 2010). Ein Software-Fehler in der Genauigkeit der Zielerfassung führte 1991 zu 28 Toten und mehr als 90 Verletzten (HOFFMANN 2008: 44). Nach dem Update des Abfertigungssystems USAS der Lufthansa im Jahre 2004 wurden aufgrund eines Software-Fehlers 60 Flüge gestrichen und 6000 Passagiere nicht befördert. Zudem fiel der gesamt CargoBereich aus. Betroffen waren insgesamt 46 verbundene Fluggesellschaften (WIWO 2004). Ende 2005 fiel an der Tokioter Börse wegen eines Software-Fehlers der Handel mehrstündig aus (FTD 2010). Trial and Error (deutsch: Versuch und Irrtum) als heuristische Methode zur Problemlösung ist gekennzeichnet durch Probieren. PEZZE und YOUNG sehen neben dem gestiegenen Koordinationsbedarf auch erhöhten Kommunikationsbedarf in der Qualitätssicherung, gerade dann, wenn Software im Team entwickelt und getestet wird. Dieser Mehraufwand kann durch ausgereifte Entwicklungsprozesse minimiert werden (PEZZE/YOUNG 2009: 451). Die Aufzählung basiert auf HOFFMANN 2008:

7 können8. So entstehen während der Lebenszyklen des Software-Systems verschiedene Versionen, Varianten und sofern in anderen Software-Systemen applikationsübergreifend integriert, auch Komponenten des ursprünglichen Systems, die als Produktdiversifizierungen 9 betrachtet werden können. Software-Entwickler nutzen bei ihrer täglichen Arbeit technische Hilfsmittel, um geregelt und produktiv arbeiten zu können. Zu qualitätssichernden Hilfsmitteln zählen Versionsverwaltung, Build-Automatisierung, Testautomatisierung und Defektmanagement. Ziel dieser Arbeit ist es, eine Abhandlung zum Thema Softwareentwicklung und Testprozess aus Entwicklersicht zu erstellen. Dabei wird neben theoretischen Grundlagen ein reales Software-Entwicklungsprojekt10 eines Großhandelsunternehmens11 beschrieben und aufgrund der Erkenntnisse dieser Arbeit bewertet. 1.2 Abgrenzung Die Aufgabenstellung ist inhaltlich an das Kapitel 8 des Buches Software-Qualität von HOFFMANN12 angelehnt. Somit folgen die thematischen Abgrenzungen automatisch aus der zugrunde liegenden Basislektüre. Es werden hier weder Methoden der Softwaree-Etwicklung noch des Testprozessmanagements behandelt. 8 Dies ist schon allein aus Gründen des langfristigen Investitionsschutzes geboten (HEINRICH/LEHNER 2005: 240). 9 Nach HOFFMANN ist Produktdiversifizierung bei Software-Produkten das Ergebnis von aufeinanderfolgenden Entwicklungsphasen (HOFFMANN 2008: 415ff). 10 Das Entwicklungsprojekt läuft mittlerweile über mehrere Jahre und wird von zwei Großhandelsbetrieben kooperativ vorangetrieben. 11 Hierbei handelt es sich nicht um ein Informationstechnologieunternehmen. 12 HOFFMANN 2008:

8 2 Software-Entwicklung und Testprozess A fool with a tool is still a fool. Software-Entwicklungswerkzeuge werden für unterschiedliche Aufgaben innerhalb des Entwicklungsprozesses genutzt. Dabei hat eine mittlerweile große Auswahl an technischen Werkzeugen die Aufgabe, den Software-Entwickler bei der Erledigung seiner Arbeit zu unterstützen. Sind diese Werkzeuge in einer Software-Entwicklungsumgebung integriert, stellt dies einen Idealfall dar. Durch Integration ist beispielsweise der Austausch von Daten zwischen den einzelnen Entwicklungswerkzeugen möglich. Zu den charakteristischen, technisch orientierten Werkzeugen für Software-Entwickler, die zumeist in Entwicklungsumgebungen eingebettet sind, gehören Basiswerkzeuge, Testwerkzeuge, Dokumentationswerkzeuge, Installationswerkzeuge und Archivwerkzeuge. Basiswerkzeuge erledigen technische Basisdienste. Hierzu gehören typischerweise Editor13, Compiler, Linker, Debugger und auch Profiler 14. Diese Werkzeuge sind heutzutage überwiegend in einer integrierten Entwicklungsumgebung zusammengefasst. Der Einsatz von Testwerkzeugen hilft dabei, manuelle Test während und nach der Programmierung idealerweise überflüssig zu machen. Die Automatisierung der Softwaretests wird durch Test-Frameworks möglich. Dokumentationswerkzeuge helfen dabei, die technische Dokumentation und die Anwenderdokumentation zu erstellen. Der Einsatz von Generatoren kann den Entwickler dabei unterstützen, direkt aus den Quelltexten Software-Dokumentationen zu erzeugen, beispielsweise Informationen über Inhalt, Erstellung und Änderung des Quell-Codes. Die Auslieferung von Software erfolgt in zwei Schritten. Vom Entwickler wird im ersten Schritt auf dem Entwicklungssystem ein Software-Paket erstellt, das im zweiten Schritt auf dem Produktionssystem installiert wird. Dabei müssen plattformspezifische Besonderheiten der Zielsysteme beachtet werden. Installationswerkzeuge unterstützen den Entwickler bei der Paketierung der entwickelten Programme und deren Installation auf den Zielsystemen. Die technische und organisatorische Verwaltung von Programmen und Programmbestandteilen wird mit Hilfe von Archivwerkzeugen realisiert. Die 15 Kernsäule der Softwareinfrastruktur ist dabei das Konfigurationsmanagement. Je umfangreicher und komplexer sich Software-Entwicklungsprojekte gestalten, desto eher werden nicht nur Basiswerkzeuge eingesetzt, sondern auch ergänzende, meist kostenintensive Produkte angeschafft. Wegen der überwiegend modularen Architektur der integrierten Entwicklungsumgebungen kann auf den spezifischen Technologiebedarf flexibel und individuell reagiert werden. 13 Editoren sind heutzutage meist mit Syntax-Hervorhebung, Code- und Klassen-Browser ausgestattet. 14 Aufzählung nach KÖNIG/ROMMELFANGER/OHSE 2003: 44f. 15 HOFFMANN 2008:

9 Gerade bei mittleren und großen Software-Projekten ist die Entwicklung und damit das Projekt nicht mit der finalen Auslieferung der Software abgeschlossen. Der häufig mehrere Jahre andauernde Entwicklungsprozess mündet ab Nutzung der Systeme in deren Weiterentwicklung und Wartung. Dabei ist die Weiterentwicklung von der Wartung nur schwer zu trennen16. Weil schon geringe Wartungsarbeiten hohe Kosten verursachen können 17, wird die Wartung häufig in einzeln zu veröffentlichende Release-Konzepte eingebunden. Somit wird die Wartung wieder in Entwicklungsprojekte überführt. Abbildung 1: Grobdarstellung der Software-Entwicklung Mit der Einführung der entwickelten Software entstehen nach der initialen Version erste Folgeversionen, die als Releases an den Anwender ausgeliefert werden. Diese Releases müssen fortan zusätzlich weiterentwickelt werden. HOFFMANN bezeichnet diesen Vorgang als Versionsdiversifizierung 18. Im Ergebnis muss ein Software-Entwickler gleichzeitig verschiedene Versionen desselben Produktes weiterentwickeln. Aus den unterschiedlichen Versionen eines Produktes können auch verschiedene Varianten dieses Produktes durch Portierung hervorgehen. Nach HOFFMANN sind häufig auftretende Portierungsvarianten beispielsweise: andere Betriebssysteme, andere Hardware-Plattformen und Endgeräte19. HOFFMANN bezeichnet das Resultat der Portierung von Produktversionen als Variantendiversifizierung 20. Sobald ein Software-Produkt als Komponente in anderen Software-Produkten eingesetzt werden kann, können von diesem Produkt aufgrund der Vielzahl von Schnittstellen verschiedenen Komponenten entstehen. Dieser Vorgang wird als Komponentendiversifizierung 21 bezeichnet. Der von HOFFMANN im Zusammenhang mit einem Software-Produkt eingeführte Begriff der 16 Vgl. Lang 2003: Lang nennt hier Neuerstellung von Dokumentationen und Spezifikationen, Recompilierung und Test (Lang 2003: 48). 18 HOFFMANN 2008: Variantendiversifizierung nach HOFFMANN 2008: HOFFMANN 2008: ebenda. 21 HOFFMANN 2008:

10 Produktdiversifizierung22 ist der Wirtschaftswissenschaft entlehnt. Im Unterschied zu HOFFMANN handelt es sich jedoch dabei um ein neues Produkt in einem neuen Markt 23. Die verschiedenen Diversifikationen werden in der Wirtschaftswissenschaft allerdings anhand des vorhandenen Produktprogramms differenziert24: Horizontale Diversifikation erweitert das Sortiment um ein Produkt derselben Produktionsstufe. Vertikale Diversifikation erweitert das Sortiment um Produkte der vor- und nachgelagerten Produktionsstufen. Laterale Diversifikation erweitert das Sortiment um Produkte, bei denen kein weiterer Zusammenhang mit den Produktionsstufen besteht. Besonders die laterale Diversifikation zeigt, dass betriebswirtschaftliche Begrifflichkeiten von materiellen Gütern nicht ohne Weiteres auf immaterielle Güter, wie Software, übertragbar sind. Die Produktdiversifizierung bei Software-Produkten, bestehend aus Versions-, Varianten- und Komponentendiversifizierung, erhöht die Komplexität in der Entwicklung und Wartung erheblich. Zur Veranschaulichung dient die folgende Darstellung anhand eines weiterentwickelten Produktes. 22 HOFFMANN 2008: ALBERS/HERRMANN 2000: ALBERS/HERRMANN 2000: ebenda

11 Abbildung 2: Produktdiversifizierung bei Software-Produkten Quelle: Eigene Darstellung in Anlehnung an HOFFMANN 2008: 416. Die Entwicklung und der Test von Software in größeren Teams und die mit der Zeit zunehmende Produktdiversifizierung führt zwangsläufig zum Einsatz von Entwicklungs- und Testwerkzeugen, um die Komplexität bei Sicherstellung einer angemessenen SoftwareQualität beherrschen zu können. Dabei bilden Versionsverwaltung, Build-System und Testumgebungen zusammen mit einem Defektmanagement eine Basisinfrastruktur insbesondere für große Software-Projekte

12 Abbildung 3: Software-Entwicklung und Testprozess In den nachfolgenden Abschnitten Software-Entwicklung (2.1) und Testprozess (2.2) werden diese wichtigen Bestandteile der Infrastruktur für Software-Entwickler vorgestellt. 2.1 Software-Entwicklung Umfangreiche Software-Projekte stellen hohe Anforderungen an Breite und Tiefe des Anwendungswissens der Projektbeteiligten. Einzelnen Personen ist es oft nicht möglich 25, über das gesamte Anwendungswissen zu verfügen. Die Konsolidierung dieses Wissens ist jedoch entscheidend für den Projekterfolg. Damit wird Team-Arbeit zu einem wichtigen Erfolgsfaktor, besonders in der Entwicklung umfangreicher Software-Systeme. Zum Unterstützen der Teamarbeit in der Software-Entwicklung gibt es eine Vielzahl kollaborativer Ansätze. Gleichzeitig gilt es, die manuelle Ausführung repititiver Aufgaben im Entwicklungsprozess zu reduzieren. Hierzu können Versionsmanagement und die Automatisierung des Build-Prozesses verwendet werden. 25 Wegen der meist begrenzten kognitiven Fähigkeiten einer einzelnen Person

13 Mit Hilfe des Versionsmanagements wird die Versionierung und Weiterentwicklung bzw. Wartung verschiedener Versionsstände von Dateien und Verzeichnisstrukturen unterstützt. Gleichzeitig ist eine verteilte Arbeit im Team möglich. Um die tägliche Arbeit des Software-Entwicklers von wiederkehrenden, lästigen und zeitaufwändigen Arbeiten zu befreien, wurde die Automatisierung des Build-Prozesses (und des damit eng verbunden Testprozesses26) eingeführt. Erst die Automatisierung erlaubt regelmäßige Software-Builds durchzuführen und so in der Folge bessere Quelltexte und damit qualitativ bessere Produkte zu erzeugen Versionsmanagement Schon frühzeitig hatte man erkannt, dass nicht nur die Speicherung des aktuellen Bearbeitungsstandes von Dateien nützlich ist, sondern auch auf ältere Stände zugegriffen werden musste. Diese Funktionalität wurde damals teilweise auf Betriebssystemebene integriert. Ende der 1970ger27 Jahre veröffentlichte die Digital Equipment Corporation das Betriebssystem VAX/VMS28. In diesem Betriebssystem war bereits eine rudimentäre Versionsverwaltung integriert. Es konnte eine einstellbare Anzahl von Dateiversionen automatisch vorgehalten werden. So wurden die Nutzer in die Lage versetzt, ältere Versionen einer Datei zu öffnen, um beispielsweise Dateiänderungen nachvollziehen zu können. Doch die Fähigkeit, Dateien zu indizieren, macht noch keine Versionsverwaltung aus. Schließlich kann eine Datei zum Zweck der Nachvollziehbarkeit mit jeder Änderung unter einem anderen Dateinamen abgelegt werden. Sofern zwischen Dateien Abhängigkeiten bestehen, muss nicht mehr nur eine ältere Version einer Datei, sondern ältere Versionen gleich mehrerer Dateien betrachtet werden. Kommen nun noch weitere Benutzer hinzu, können ohne Absprache unter den Nutzern Dateiverluste durch überschreiben auftreten. Was möglicherweise bei kleineren Teams noch funktionieren kann, ist bei größeren Teams kaum noch zu organisieren. Jeder Nutzer müsste sich nun zusätzlich mit dem passenden Nutzer verabreden. Mit Einsatz eines Versionsverwaltungssystems können verschiedene Nutzer zeitgleich an einer Datei arbeiten. Die Änderungen werden danach zusammengeführt. Dadurch entstehen keine Wartezeiten, denn meist ändern verschiedene Nutzer auch verschiedene Bereiche der Dateien. Dieses Dateikontrollsystem wird nun noch durch ein Versionskontrollsystem erweitert. Ähnlich einem Dateiverzeichnisbaum werden die einzelnen Versionen in Ästen verwaltet. Von diesen Ästen können wiederum andere Äste oder Zweige abgehen, die Unterversionen einer Version darstellen. Für Unterversionen werden aber nur die Änderungen vorgehalten, damit diese Unterversionen auch wieder in die Hauptversionen übernommen werden können. Datei- und Versionskontrolle sind in nahezu allen verfügbaren Versionskontrollsystemen integriert. Es sind sowohl kostenfreie als auch kostenpflichtige proprietäre Versionsverwaltungssysteme erhältlich. Zu den kostenfreien Systemen zählen beispielsweise CVS, Subversion, Baazar, Darcs, Git, GNU arch, Mercurial, Monotone. Zu den proprietären Systemen gehören Alienbrain, Perforce, Team Foundation Server, Visual Source Safe, 26 Vgl. Abschnitt Das ofizielle Release wurde am 25. Oktober 1977 veröffentlicht (Quelle: Abruf ). 28 VAX: Vrtual Adress Extention, VMS: Virtual Memory System

14 Clearcase, IBM Rational Synergy und Bitkeeper29. Die Vielzahl an Systemen resultiert aus den unterschiedlichen Rahmenbedingungen und Anforderungen, die bei der Entwicklung großer Software-Systeme auftreten können Anforderungen Wesentliche Gründe, die für den den Einsatz von Versionsverwaltungssystemen durch Software-Entwickler sprechen, sind: Änderungshistorie Änderungen an Text- oder Binärdateien können nachvollzogen werden. Dabei können Antworten auf folgende Fragen gegeben werden: Wer hat etwas geändert? Wann wurde etwas geändert? Was wurde geändert? Warum wurde etwas geändert? Trial and Error Sofern Fehler in der Software-Entwicklung eine Rücknahme der Änderungen verlangen, kann der frühere Zustand, der zeitlich vor einer Änderung existierte, wieder hergestellt werden. Backup Durchführung der Sicherung aller notwendigen Dateien und Verzeichnisse. Restore Die Rückgewinnung beliebiger alter Release-Stände muss ebenso gewährleistet sein, wie die nachträgliche Rücknahme von überflüssigen oder fehlerhaften Programmänderungen. Integration in IDE's Bereitstellung von Schnittstellen für Entwicklungssysteme. Gemeinsamer Zugriff und parallele Entwicklung Das Versionsverwaltungssystemen muss den gleichzeitigen Zugriff mehrerer Entwickler unterstützen und die notwendigen Techniken dafür bereitstellen. Berechtigungssteuerung Eine Verwaltung für die Steuerung von Zugriffsrechten für Dateien und Verzeichnisse muss bereitgestellt werden Begriffe Im Zusammenhang mit Versionsverwaltungssystemen werden häufig spezifische Begriffe genutzt. Die Erklärung der grundlegenden Begriffe erfolgt in Kurzform. add: Erstmalige Aufnahme einer Datei in die Versionsverwaltung revision: Gibt die Versionsnummer einer Datei an. 29 Die beispielhafte Aufzählung der Versionsverwaltungssysteme stammt aus Abruf

15 head: Ist die letzte Revision im Repository. check out: Extrahieren einer Datei aus dem Repository. check in: Hochladen einer Datei in das Repository. Es wird eine neue Revision erzeugt. Damit ist ein anschließender check out für andere Nutzer möglich. update/sync: Synchronisiert die (lokalen) Dateien des Nutzers mit dem letzten Stand aus dem Repository. revert: Verwirft Änderungen und synchronisiert den letzten Stand aus dem Repository. branch: Anlegen einer separaten Kopie im Repository. diff/change/delta: Ermittelt anzeigen zu können. merge: Übernahme der Änderungen, ausgehend von einer Datei, in eine andere Datei. Wird genutzt, um Dateien zu aktualisieren. conflict: Tritt auf, wenn Dateien nicht aktualisiert werden können, weil überlappende Änderungen aus zwei Dateien nicht gegenseitig übernommen werden können. resolve: Lösen eines conflicts. Im Anschluss daran erfolgt ein check in der betreffenden Datei. locking: Sperren einer Dateien durch einen Benutzer, damit andere Benutzer diese Datei nicht ändern können. Differenzen zwischen zwei Dateien, um Änderungen Die englischen Begriffe haben sich in diesem Kontext herstellerübergreifend durchgesetzt. Eine Übersetzung wäre an dieser Stelle nicht sinnvoll, weil darunter die allgemeine Verständlichkeit leiden würde Konzeption Die elementare Eigenschaft eines Versionsverwaltungssystems ist die Aufzeichnung aller Dateiinhalte über die Zeit 30. Dabei entsteht nicht nur eine Dateihistorie, sondern auch eine Verzeichnishistorie. Das Versionsverwaltungssystem kann nicht nur Änderungen in Dateien selbst verwalten. Auch das Anlegen, Löschen oder auch Umbenennen von Dateien muss protokolliert werden. Erweiterte Informationen über den Bearbeiter, den Zeitpunkt der Änderung und den beschreibenden Inhalt der Änderung, aber auch interne Verwaltungsinformationen, wie Revisionsnummern oder Berechtigungen werden im Repository als Metadaten abgelegt. 30 HOFFMANN 2008:

16 Abbildung 4: Überblick Versionsverwaltung Ein Repository kann in diesem Zusammenhang als Datenspeicher für beschreibende Informationen über Dateien und Verzeichnisse und als Datenspeicher der Dateien selbst betrachtet werden. Jedes Versionsverwaltungssystem implementiert ein individuelles Repository. Zumeist werden die Repositories durch eigene Systemwerkzeuge gepflegt. Dabei muss das Repository jederzeit konsistent sein. Ein Systemabsturz oder auch Netzwerkprobleme dürfen nicht zu einem inkonsistenten Repository führen. Während der Software-Entwicklung arbeiten die Programmierer in einer Arbeitskopie ihrer Quelltexte. Diese Arbeitskopie wird aus dem Versionsverwaltungssystem heraus erzeugt. Auf die Arbeitskopie kann entweder lokal oder entfernt zugegriffen werden. Der lokale Zugriff erfolgt in einer Sandbox. In Gegensatz dazu wird der entfernte Zugriff auf die Arbeitskopie durch Einblendung eines virtuellen Dateisystems realisiert. Die Sandbox31 ist ein lokales Arbeitsverzeichnis, in das der Entwickler eine Arbeitskopie eines Entwicklungszweiges aus dem Versionsverwaltungssystem erzeugt. Nachdem der Entwickler seine Programmänderungen erfolgreich durchgeführt hat, werden die Änderungen in das Versionsverwaltungssystem zurückgeschrieben und anderen Entwicklern zur Verfügung gestellt. Bei virtuellen Dateisystemen wird die Arbeitskopie des Entwicklungszweiges über das Netzwerk auf dem lokalen Rechner eingeblendet. Das Versionsverwaltungssystem fungiert als Server. Lokal gespeichert werden dann die Änderungen des SoftwareEntwicklers. Nach erfolgreicher Änderung werden die Dateien in das Versionsverwaltungssystem zurückgeschrieben. Beim Sandbox-Konzept entsteht beim Erzeugen der lokalen Kopie eine vergleichsweise große Datenmenge auf dem Entwicklungsrechner. Anschließend könnte dann ohne Netzwerkverbindung weitergearbeitet werden. Bei Nutzung eines virtuellen Dateisystems ist hingegen eine permanente Netzwerkverbindung zum Versionsverwaltungssystem notwendig. 31 Der Begriff der Sandbox wird beispielsweise auch in Verbindung mit Sicherheitssystemen verwendet. Als Sandboxen werden isolierte Bereiche in Rechnern bezeichnet

17 Arbeitsweise Jedes Mal, wenn ein check in einer neuen oder geänderten Datei erfolgt, wird eine neue Revisionsnummer vergeben, die im Repository gespeichert wird. Die 32 Revisionsnummernvergabe kann dabei lokal oder global implementiert sein. Bei der lokalen Versionierung wird für jedes Element im Repository eine eigene Revisionsnummer verwaltet. Beim check in wird nur diese elementbezogene Revisionsnummer inkrementiert. Bei der globalen Versionierung werden alle im System enthaltenen Revisionsnummern der Repository-Elemete beim check in inkrementiert. Somit haben alle Dateien eine einheitliche Revionsnummer. Üblicherweise erfolgt vor einem check in jedoch ein check out mit anschließendem Modifizieren des Dateiinhalts. Ein normaler check out liefert die aktuellste Version des Elements aus dem Repository. Erst nach erfolgreichem Editieren erfolgt wieder ein check in. Sofern die Änderung nur temporär erfolgte, kann mittels revert die Änderung verworfen werden und von neuem mit dem Editieren begonnen werden. Abbildung 5: check in/check out/revert Aus dem Hauptentwicklungszweig können Teile in separate Zweige, sogenannte branches, 32 Die Art der Vergabe von Revisionsnummern ist herstellerspezifisch

18 kopiert werden. Diese Möglichkeit erlaubt es, die Entwicklung an einem Punkt aufzuspalten. So können beispielsweise experimentelle Änderungen ausgiebig isoliert getestet werden, ohne den Hauptentwicklungszweig zu beeinträchtigen. Abbildung 6: branching Zu einem späteren Zeitpunkt können, beim sogenannten merging, die Änderungen in den branches wieder in den Hauptzweig zurückgeführt werden

19 Abbildung 7: merging Die Einsatzzwecke der branching und merging sind nach HOFFMANN33 : Bei der Team-Koordination kann durch Anlegen von separaten branches die Entwicklung aufgeteilt werden. So können mehrere Teams in eigenen branches unabhängig und flexibel arbeiten. Letztendlich kann sogar die Hauptentwicklung selbst nicht mehr für die Weiterentwicklung genutzt werden, sondern wird nur noch durch merges modifiziert. Wegen der separaten Entwicklung bleiben die Änderungen jedes branches für die anderen Teams unsichtbar. Das kann zu Verzögerungen führen, wenn die Entwicklungsergebnisse nur zögerlich verteilt werden. Es können separate branches für die Entwicklung unterschiedlicher Produktversionen eingesetzt werden. Somit kann gleichzeitig an verschiedenen Versionen gearbeitet werden. Bei der Release-Erstellung werden Fehler bereinigt und auch neue Features integriert. Um ein neues stabiles Release zu erstellen, werden vor Veröffentlichung nur noch Änderungen übernommen, die wichtig für die Stabilität des Software-Produktes sind. Während die Hauptentwicklung weiter voran schreitet, werden die Releases kurz vor der Veröffentlichung in einem separaten branch eingefroren. Änderungen der Hauptentwicklung dürfen kurz vor Veröffentlichung nicht mehr in den Releasebranch einfließen. Um Fehlerbehebungen nicht zu verlieren, werden diese branches später in die Hauptentwicklung integriert. Versuchsreihen stellen experimentelle Entwicklungen dar. Dabei können unterschiedliche Implementierungen erzeugt, verglichen und dann bevorzugte Lösungen in die Hauptentwicklung integriert werden. 33 HOFFMANN 2008:

20 Beim merging können jedoch auch Konflikte auftreten. Sofern zwei vollständig unabhängige Teile in Dateien bearbeitet werden, können diese miteinander automatisch abgeglichen werden. Immer dann, wenn überlappende Code-Bereiche verändert wurden, können MergeKonflikte auftreten. Abbildung 8: Merge-Konflikt Ein check in ist dann nicht mehr möglich. Der Software-Entwickler könnte im Konfliktfall wie folgt vorgehen: Ein update/sync könnte die gerade aktuelle Version aus dem Repository synchronisieren und die Änderungen können durch den Software-Entwickler nochmals vorgenommen werden. Nach einem check out, gefolgt von einem Überschreiben mit den Änderungen des Software-Entwicklers, kann der Quell-Code mittels check in wieder in das Repository übertragen werden. HOFFMANN beziffert die Konfliktanzahl34 bei eigenen Projekten auf weniger als 10 Prozent der durchgeführten check in Problemfelder Einsatz und Anwendung eines Versionsmanagementsystems können zu Problemen führen, die aus teils falsch verstandenen oder nur partiell angewendeten Funktionalitäten herrühren. Zwei Problemfelder werden hier beispielhaft aufgeführt. 34 HOFFMANN 2008:

21 Versionsmanagementsysteme werden zumeist nur als Quelltextverwaltungen eingesetzt. Andere Dateien, wie Konfigurationsdateien, Pflichtenoder Lastenhefte, Dokumentationsdateien, Datenbankinhalte oder auch binäre Programmdateien, wie Compiler oder Linker, werden selten im Versionsmanagementsystem verwaltet. Häufig wird damit argumentiert, dass der Speicherplatz auf Dauer nicht ausreicht35, um beispielsweise ganze Entwicklungsumgebungen unter Versionskontrolle zu stellen36. Zudem werden branches häufig falsch eingesetzt. Ein branch wird mit dem Zweck angelegt, dass zu einem späteren Zeitpunkt eine Rückintegration der Änderungen mittels eines merge erfolgen kann. Wird jedoch das branching eingesetzt, um komplett separate Produktlinien entstehen zu lassen, ist ein späteres merge nicht mehr möglich. Es entstehen dann voneinander völlig unabhängige Entwicklungszweige Praktische Anwendung Die Firma Presse-Vertrieb Mecklenburg West GmbH & Co. KG implementiert Software mit Hilfe des Sybase37 Powerbuilder in der Version Der Sybase Powerbuilder ist eine integrierte Entwicklungsumgebung zum objektorientierten Entwickeln von Client-ServerAnwendungen für die Microsoft Windows Plattform, mit besonderem Schwerpunkt im Datenbankumfeld. Programmiert wird in der Programmiersprache Powerscript. Die Datenhaltung wird mittels Oracle Datenbanksystem 11g realisiert. Die integrierte Entwicklungsumgebung besitzt eine Schnittstelle für Versionsmanagementsysteme. Voraussetzung für die Nutzung eines Versionsmangementsystems im Powerbuilder ist, dass die dazugehörige Client-Software der Versionsverwaltung sich in in der Windows-Registry unter HKEY_LOCAL_MACHINE\SOFTWARE\SourceCodeControlProvider\InstalledSCCProviders einträgt. Gegenwärtig wird der PushOK-Client für Subversion genutzt. Das eingesetzte Versionsmangementsystem ist folglich subversion SVN. Der Powerbuilder arbeitet nach dem Sandbox-Prinzip. Die Konfiguration der Schnittstelle ist denkbar einfach. 35 Obwohl mit Hilfe der Delta-Technik (HOFFMANN 2008: ) Speicherplatz gespart werden kann, ist bei Versionierung von Binärdateien der Speicherplatzbedarf vergleichsweise hoch. 36 HOFFMANN 2008: Sybase ist ein Anbieter von Datenbank-Software, Entwicklungs- und Designwerkzeugen. Sybase wurde 2010 von SAP America übernommen

22 Abbildung 9: Konfiguration SVN-Interface im Powerbuilder Nach Auswahl des Clients, des Nutzers und des spezifischen Projektes (hier: merlin) können noch erweiterte Einstellungen bezüglich des Verhaltens bei fehlendem Server und in Bezug auf vom Powerbuilder generierte Schnittstellenobjekte vorgenommen werden, denn der Powerbuilder besitzt gegenüber aktuellen Entwicklungsumgebungen eine Besonderheit: Alle Objekte werden in sogenannten Powerbuilder Libraries (kurz: pbl) gespeichert. Diese Libraries enthalten den in den Assistenten und im Editor generierten Source Code. Auf diese Weise werden mehrere unabhängige Quell-Codes in einer einzigen Datei gespeichert. Da Versionsmanagementsysteme jedoch nur einzelne Dateien und Verzeichnisse versionieren können, muss ein Mechanismus vorhanden sein, um aus den wenigen Library-Dateien die vielen einzelnen Quell-Code-Dateien extrahieren zu können. Hierfür besitzt der Powerbuilder eine integrierte Export/Import Schnittstelle, die auch für das Versionsmanagement eingesetzt wird. Wenn ein Versionsmanagementsystem in Verbindung mit dem Powerbuilder eingesetzt wird, ist es empfehlenswert, jede Library-Datei in einem separaten Unterverzeichnis zu speichern. Ursache dafür ist die Möglichkeit, Klassen in verschiedenen Libraries mit gleichem Namen anlegen zu können. Da das Versionsmanagementsystem jedoch auch Verzeichnisse

23 versioniert, können so die einzelnen, möglicherweise gleichnamigen Klassen voneinander getrennt werden. Sobald eine Schnittstelle zu einem Versionsmanagementsystem im Workspace einer Applikation eingerichtet wurde, ist ein Speichern von Klassen nur noch nach einem zuvor erfolgtem check out möglich. Eine weitere Besonderheit des Powerbuilder ist, das Operationen gegen das Versionsmanagementsystem nur auf Klassen möglich sind, die nicht im powerbuilder-eigenen Editor geöffnet sind. Eine Klasse, die mit check out für das Bearbeiten markiert wurde, wird durch ein entsprechendes Symbol (Haken) gekennzeichnet. Alle anderen Objekte werden, sofern sie sich im Repository befinden, mit einem ausgefüllten Kreis markiert. Abbildung 10: Powerbuilder check out

24 Nach erfolgtem Editieren und Testen können die modifizierten Klassen mit einem check in in das Repository hochgeladen werden. Dabei kann es vorkommen, dass Konflikte auftreten. Diese Konflikte können angezeigt werden. Abbildung 11: Differenzen-Anzeige Möglichkeiten des Powerbuilders in Verbindung mit dem Source-Control-Interface: add to source control: Klasse dem Repository hinzufügen. remove from source control: Klasse aus dem Repository entfernen. check out: Klasse in den lokalen Arbeitsbereich kopieren. undo check out: Ursprüngliche Kopie aus dem Repository synchronisieren. check in: Änderungen in das Repository übernehmen. get latest version: Lokalen Arbeitsbereich mit den aktuellsten Versionen aus dem Repository synchronisieren. refresh status: Status der lokalen Klassen aktualisieren. show history: Protokoll der Änderungen anzeigen. show differences: Unterschiede mittels Gegenüberstellungen der Source-Codes anzeigen

25 Resümee Versionsmanagementsysteme haben mittlerweile einen festen Platz in der Team-SoftwareEntwicklung. Wegen ihrer Universalität, die ihren Ursprung in der Versionierung einfacher Dateien und Verzeichnissen hat, wird längst nicht nur Source-Code in diesen Systemen verwaltet. Neben den Programmquelltexten füllen mittlerweile auch Binärdateien und Konfigurationsdateien die Repositories. Selbst ganze Entwicklungsumgebungen mit Datenvolumina von mehreren Gigabyte lassen sich so versionieren. Durch Einbettung des Versionsmanagements in integrierte Entwicklungsumgebungen ist die Handhabung der notwendigen Schritte zur Versionierung während des Entwicklungsprozesses mit geringem Mehraufwand zu leisten. Werden nun ganze Laufzeitumgebungen in den Versionsverwaltungssystemen archiviert, wird aus dem reinen Versionsmanagement ein zentraler Bestandteil des Konfigurationsmanagements Build-Automatisierung Gerade bei großen Entwicklungsprojekten fallen nach der eigentlichen Codierung noch jede Menge zusätzlicher Arbeitsschritte an. Hierzu gehören Compilierung der Software, Post- und Pre-Processing der Quelltexte, Dokumentationserstellung oder auch die Ausführung von Tests. Das Zusammenfügen aller Komponenten eines Software-Systems wird als BuildProzess bezeichnet39. Bei kleineren Projekten genügt es bereits, den Compiler aufzurufen und mit dem Linker ausführbare Programme zu erzeugen und anschließend diese Programme zu starten. Der Erfolg des Compilierens und Linkens hängt auch davon ab, ob der Compiler, der Linker und die notwendigen Bibliotheken gefunden werden und ob dafür die notwendigen Zugriffsrechte bestehen. In größeren Projekten muss diese Arbeit optimiert werden. Wegen des Umfangs der Quelltexte können nicht immer alle Dateien frisch compiliert werden. Die benötigten Arbeitsschritte werden regelmäßig, häufig auch mehrfach täglich, durchgeführt. Die manuelle Durchführung dieser Arbeiten ist bei zyklischer Anwendung nicht zu empfehlen. Gründe dafür können sein: Fehleranfälligkeit40 Eingeschränkte Reproduzierbarkeit als Ergebnis mangelnder Kommunikation der Software-Entwickler untereinander41 Eine Arbeit im Team bei gleichzeitiger Sicherstellung einer geforderten Software-Qualität ist 38 An dieser Stelle wird auf weiterführende Literatur zum Konfigurationsmanagement verwiesen, zum Beispiel: Verstegen, Gerhard (Hrsg.), Weischedel, Guido: Konfigurationsmanagement, Springer-Verlage, Heidelberg Berlin, HOFFMANN 2008: Bei händischer Durchführung können, je nach Tagesform des Nutzers, durch unbeabsichtigtes Weglassen oder Hinzunehmen von Arbeitsschritten, fehlerhafte oder zumindest unbeabsichtigte Ergebnisse entstehen. 41 Arbeitsschritte und Konfigurationen, die für einen Software-Entwickler logisch und nachvollziehbar sind, müssen für einen anderen Software-Entwickler nicht zwingend sein

26 unter den Bedingungen eines manuellen Build-Prozesses kaum möglich. Bevor jedoch ein Build-Prozess automatisiert werden kann, muss bereits ein manueller Build-Prozess vorhanden sein. Ein Prozess, der nicht bereits vorhanden ist, kann auch nicht automatisiert werden. Im Ergebnis des Builds liegt ein Software-Produkt vor. Der Software-Entwickler kann sich in Verbindung mit dem Build letztlich zwei Fragen stellen: Compiliert es? Läuft es? In diesem Abschnitt (Build-Automatisierung) werden Methoden aufgezeigt, um auf die erste Frage eine Antwort geben zu können. Die Beantwortung der zweiten Frage erfolgt im nächsten Abschnitt (Testprozess) Build-Typen Es sind unterschiedliche Typen von Builds denkbar. OSHEROVE teilt die Build-Prozesse beispielhaft in drei Typen ein42. Dabei ist sowohl das Resultat des Builds als auch die Dauer und Periodizität der Build-Ausführung maßgeblich. Beim nächtlichen Build werden Builds mit längerer Laufzeit ausgeführt. Der nächtliche Build integriert alle implementierten Systemtests in den Build-Prozess. Ein Release-Build arbeitet das nächtliche Build ab und verteilt das Ergebnis auf andere Server. CI43- Builds werden in weniger als 10 Minuten 44 durchgeführt. Es erfolgen im Anschluss an den Build nur schnell ablaufende Tests. Der wichtigste Build-Typ ist der tägliche Build. GUCKENHEIMER/PEREZ bezeichnen diesen BuildTyp als den Herzschlag des Projektes45, der idealerweise allabendlich ausgeführt wird Inkrementelle Compilierung Um die Compile-Zeit der Quelltexte zu verkürzen, wurden auf Basis spezieller Algorithmen Methoden entwickelt, um den gesamten Quell-Code auf semantische Abhängigkeiten hin zu analysieren. Im Ergebnis werden nur diejenigen Quell-Code-Dateien gezielt compiliert, die von Änderungen direkt oder indirekt betroffen sind. Nach Meinung des Autors ist ein Compiler dann inkrementell einsetzbar, wenn dieser bereits compilierte Quelltexte nach partiellen Änderungen Code-Änderungen schneller compiliert, als beim ersten Mal. Anmerkung: HOFFMANN verwendet für die inkrementelle Compilierung den Begriff Bedingte Compilierung 47. Der Begriff Bedingte Compilierung ist in der Informationstechnik jedoch anderweitig bereits belegt. Bei der bedingten Compilierung werden mit Direktiven Quelltextabschnitte markiert, die beispielsweise nur in Abhängigkeit vorhandener Makros OSHEROVE 2010: 159. CI ist eine Abkürzung für Continuous Integration. OSHEROVE 2010: 159. GUCKENHEIMER/PEREZ 2007: 184. GUCKENHEIMER/PEREZ 2007: 251. HOFFMANN 2008:

27 compiliert werden48. Tatsächlich lässt sich die Compile-Zeit mittels inkrementeller Compilierung in realen Entwicklungsprojekten von mehreren Stunden oder Tagen auf wenige Minuten reduzieren49. Die auf den ersten Blick einfach erscheinende Compilierung von nur geändertem Quell-Code ist jedoch bei genauerer Betrachtung aufwändig. Es reicht eben nicht aus, nur die geänderten Quelltextdateien zu compilieren. Es müssen zuvor die Abhängigkeiten analysiert werden um dann auch alle abhängigen Module mitzucompilieren. Dabei wird in drei Schritten vorgegangen: Zuerst werden die Abhängigkeiten der Quelltextdateien voneinander analysiert. Der hierbei erzeugte Abhängigkeitsgraph zeigt eine Baumstruktur, in der der Vater das Ziel und der Sohn die Abhängigkeit des Ziels markiert. Im zweiten Schritt werden die Zeitstempel der bereits erzeugten Compilate 50 mit den Zeitstempeln der Quelltextdateien vergleichen. Bei Ungleichheit wird die entsprechende Datei zum Compilieren vorgemerkt. Im letzten Schritt wird der Abhängigkeitsgraph von den Blättern zur Wurzel durchlaufen. Sofern ein Blatt neu compiliert werden muss, muss die Wurzel (und deren Wurzeln) ebenso neu erzeugt werden. Abbildung 12: Beispiel eines Abhängigkeitsgraphen Wird im Beispiel (Abbildung 12) die Datei fkt.c geändert, muss fkt.o und a.out neu erzeugt werden. Wird hingegen die Datei common.h geändert, müssen main.o, fkt.o und a.out neu erstellt werden. Initial wird das Beispiel wie folgt erstellt: (a) g++ -c main.c (erzeugt main.o) 48 Ein Anwendungsbeispiel für bedingte Compilierung ist das Anpassen der Compilierung an bestimmte Plattformspezifika mittels #if, #ifdef oder #ifndef Direktiven in C/C HOFFMANN 2008: 451, Gemeint sind die vom Compiler erzeugten Objekt-Dateien

28 (b) g++ -c fkt.c (erzeugt fkt.o) (c) g++ main.o fkt.o (erzeugt a.out) Das inkrementelle Compilieren wird durch Werkzeuge unterstützt. Für C und C++ haben sich make, nmake und gnumake etabliert. Für Java hostet die Apache Group das Werkzeug ant, das auf Java und XML51 basiert Make Make ist ein klassisches Unix-Werkzeug aus den 1970ger Jahren. Es arbeitet shell-scripbasiert. Zur Steuerung wird eine Datei namens Makefile52 verwendet. Make eignet sich als allgemeine Lösung zur Verwaltung beliebiger Dateiabhängigkeiten. Die Abhängigkeiten zwischen der Datei und dem dazugehörigen Werkzeug werden in der Steuerdatei53 festgehalten. Das Makefile besteht aus einer Liste von Einträgen mit folgendem Aufbau: erzeugte Dateien: vorausgesetzte Dateien Befehlszeile Bevor die Befehlszeile ausgeführt wird, werden die Zeitstempel der beteiligten Dateien verglichen. Das Kommando in der Befehlszeile wird nur dann ausgeführt, wenn die vorausgesetzten Dateien jünger als die zu erzeugende Datei sind. Aus dem Beispiel in Abbildung 12, Seite 27, kann folgendes Makefile abgeleitet werden: a.out: fkt.o main.o g++ fkt.o main.o fkt.o: fkt.c common.h g++ -c fkt.c main.o: main.c common.h g++ -c main.c Anmerkung: Mit dem Aufruf g++ -c werden die Quelltexte nur kompiliert, jedoch nicht gelinked. Die Reihenfolge der Ziele der zu erzeugenden Dateien im Makefile ist wichtig. Make arbeitet die Einträge im Makefile sequentiell ab. Es versucht folglich den ersten Eintrag zuerst zu erzeugen. Der Make-Prozess wird durch Ausführung des Kommandos make gestartet. Im Beispiel wird die Datei a.out erzeugt. Der Vollständigkeit wegen sei an dieser Stelle erwähnt, dass make noch eine Vielzahl von Makros bereithält, die im Makefile verwendet werden können. Hierfür stellt make den Makro-Operator $ zur Verfügung. Mittels des Makro-Operators können vordefinierte Makros, 51 XML ist die Abkürzung für Extensible Markup Language. XML wird als Auszeichnungssprache für den plattformunabhängigen Austausch von Daten eingesetzt. Als Auszeichnungssprache ist XML selbst beschreibend. 52 Der Name Makefile entspricht der Grundeinstellung des make-utility. 53 Das Makefile ist eine Textdatei

29 dynamische Makros oder modifizierende Makros verwendet werden. Vordefinierten Makros liefern Umgebungsvariablen oder Systeminformationen zurück. Dynamische Makros liefern projektbezogene Werte zu Zielen und Abhängigkeiten. Modifizierende Makros können zum Verändern von Variableninhalten verwendet werden. Das Make-Utility besitzt die Möglichkeit, Unterziele zu vereinbaren. Hierbei werden alle Befehlszeilenkommandos zusammengefasst, die zur Erledigung von Wartungsarbeiten notwendig sind. So compiliert das Unterziel all für gewöhnlich alle am Projekt beteiligten Dateien neu, während das Unterziel clean alle Dateien löscht, die mit einem make all erstellt wurden. Das Unterziel clean kann beispielsweise wie folgt gestaltet sein54:... clean: find. -name '*.o' -exec rm -f {} ';' find. -name '*.s[ol]' -exec rm -f {} ';' find $(srcdir) -name '*.py[co]' -exec rm -f {} ';'... Neben der Flexibilität und der Geschwindigkeit, mit der make Projekte erzeugt, gibt es auch eine wichtige Einschränkung dieses Werkzeugs. Make nutzt Bourne-Shell kompatible ShellScrips. Damit ist make eingeschränkt plattformunabhängig. Auf Microsoft Windows Systemen kann eine Kompatibilität mittels Cygwin55 hergestellt werden Ant Das Build-Tool der Wahl für C/C++ ist make. Selbst Java-Programmierer, die unabhängig von einer integrierten Entwicklungsumgebung sein wollen, können make einsetzen. Allerdings ist das eher selten der Fall, denn Java-Quelltexte besitzen meist eine große Anzahl von direkten und indirekten Abhängigkeiten, die nicht so klar definiert sind, wie beispielsweise Verweise auf Header-Dateien in C/C++. Die Pflege dieser Abhängigkeiten im Makefile ist schwierig und kann später zu Laufzeitfehlern führen, die nur schwer nachzuvollziehen sind. Zusätzlich können Perfomance-Probleme während des BuildProzesses durch den make-typischen massenhaften Shell-Aufruf des Java-Compilers auftreten, da das Java-SDK selbst in Java programmiert wurde 56. Auch weil Java als Programmiersprache weitgehend plattformunabhängig ist, muss ein passendes Java-BuildTool diesem Anspruch ebenfalls genügen. Also wurde auf Basis von Java ein OpenSource Java-Build-Tool namens ant57 entwickelt. Der Build-Prozess von ant wird über eine XMLDatei namens build.xml58 gesteuert. 54 Das Beispiel stamm aus dem Makefile von python 2.4 und löscht alle mit make erzeugten Dateien rekursiv. 55 Cygwin stellt eine Unix-Kompatibilitätsschicht für Microsoft Windows Systeme bereit. 56 Krüger/Stark 2009: Ant ist ein Apache-Top-Level Projekt. Ant ist eine Abkürzung für Another Neat Tool. 58 Es kann ein alternativer Dateiname verwendet werden. Dafür muss ant mit der Option -buildfile aufgerufen werden

30 Voraussetzung für den Einsatz von ant sind: funktionsfähige Java-Installation Installation der ant-distribution Aufnahme des ant-bin-verzeichnisses in den Suchpfad Wird ant nach dem erstmaligen Aufruf erneut gestartet, werden nur noch Änderungen aktualisiert. Eine ant-build-datei besteht aus drei wichtigen Elementen: project (= Projekt) target (= Ziel) task (= Aufgabe) In einer einfachen XML-Build-Datei sind die Elemente project, target und task ineinander verschachtelt: <?xml version= 1.0?> <project name= Projekt default= build > <target name= build > <javac srcdir=. /> </target> </project> Das Attribut default definiert, welches <target> automatisch mit dem Aufruf von ant ausgeführt wird. Im Beispiel ist es das <target name= build >. Mit Ausführung des targets build werden mit der task javac alle Dateien des aktuellen Verzeichnisses compiliert. Neben javac existieren noch weitere vordefinierte tasks, die in die build.xml eingebunden werden können59. Weiterhin können externe Task-Bibliotheken eingebunden werden. Auch ist es möglich, in Java selbst eigene Tasks60 zu erstellen und einzubinden Integration des Versionsmanagements in den Build-Prozess Wie die vorhergehenden Abschnitte zeigen, ist das inkrementelle Erstellen eines SoftwareProduktes auf Basis vorhandener Quell-Codes mit der einfachen Anwendung von make oder ant möglich. Kommt jedoch ein Versionsmanagementsystem hinzu, müssen vor dem Compilieren die Quell-Dateien erst aus dem Versionsmanagementsystem extrahiert werden. Hierfür ist das Einbinden des Extraktions-Vorgangs in den Build-Prozess sinnvoll. Dafür müssen die Build-Tools um diese Fähigkeit erweitert werden. Das make-tool kann Versionsverwaltungssysteme über die Befehlszeile ansprechen. Wenn für ein Versionsverwaltungssystem ein Client für die Befehlszeile verfügbar ist, kann dieser 59 Eine Liste integrierter tasks ist unter ANT 2011 zu finden. 60 Durch Erweiterung der Klasse org.apache.tools.ant, Integration von Getter- und Setter-Methoden für Attribute und das Einfügen einer public void execute Methode

31 mittels Shell-Aufruf in das Makefile integriert werden. Bei Subversion ist es für gewöhnlich das Programm svn mit einer Vielzahl von Parametern zum bidirektionalen Datentransfer. Bei ant existieren spezielle externe Task-Bibliotheken, die zum Zweck des Versionsmanagements eingebunden werden können. Ein Beispiel dafür ist SVNAnt. SVNAnt erlaubt während des Build-Prozesses eine bidirektionale Kommunikation mit Subversion. Die Steuerung übernimmt wieder die Steuerdatei build.xml. Hier kommen neue Tasks, wie beispielsweise check out oder add hinzu. Mit check out können Dateien aus den Versionsmanagementsystem während des Build-Prozesses ausgelesen werden und mit add können die Ergebnisse des Build-Prozesses in das Versionsmanagementsystem initial hochgeladen werden Verteilter Build-Prozess Wenn eine große Anzahl an Quell-Code-Dateien compiliert werden müssen, nimmt die Compile-Zeit zu. Während des Build-Prozesses fallen Zwischenergebnisse an, die verarbeitet und integriert werden müssen. Wie bereits im Abschnitt Inkrementelle Compilierung (Seite 26) ausgeführt wurde, kann das Compilieren eines Projektes eine beträchtliche Zeit in Anspruch nehmen. Die Geschwindigkeit des Build-Prozesses kann durch Parallelisierung gesteigert werden. Dabei existieren zwei Möglichkeiten: Parallelisierung des lokalen make mit der Option -j n auf n verschiedene Ziele innerhalb eines Rechners. Parallelisierung des Build-Prozesses im Cluster über Rechnergrenzen hinweg. Im ersten Fall kann die Parallelisierung des make über die Option -j auf Kommandozeilenebene gesteuert werden. Dabei ist zu beachten, dass die Erstellung abhängiger Ziele schlecht parallelisiert werden kann. Die Parallelisierung im Cluster bedarf einiger Voraussetzungen. Neben einem Clusterfilesystem für den gemeinsamen Dateizugriff aller Knoten im Netzwerk müssen spezielle Werkzeuge vorhanden sein, um das Load-Balancing, die Konfiguration und das JobManagement steuern und überwachen zu können. Dabei können, je nach Implementierung, Agenten- oder Worker-Prozesse auf den einzelnen Cluster-Knoten sowohl die Compilierung selbst als auch die Überwachung der Aktvitäten und die Kommunikation mit den anderen Cluster-Knoten übernehmen. Meist ist eine zentrale Überwachung und Konfiguration der Aktivitäten des Build-Systems in Form einer Konsole (auch als Dashboard bezeichnet) implementiert. Die Builds laufen im Cluster als Batch-Jobs ohne Benutzerinteraktion ab. Die Verteilung auf die einzelnen Cluster-Knoten sorgt dafür, dass Ressourcen-Engpässe nach Möglichkeit vermieden werden. Der Workload-Manager leitet die Build-Jobs an Agenten mit freien Ressourcen weiter