Configuration Management

Configuration Management Software Engineering Projekt WS 06/07 Fachbereich Softwaretechnik (IV) Technische Universität Berlin Oliver Frank

1 Einleitung...3 2 Version Management... 4 2.1 Lagerung der Dateien...4 2.1.1 Zentraler Ansatz...4 2.1.1.1 Lock-Modify-Write...4 2.1.1.2 Copy-Modify-Merge...5 2.1.2 Dezentraler Ansatz...6 2.2 Versionierung...6 2.3 Branches und Tags... 7 2.3.1 Tags...7 2.3.2 Branches...7 3 Change Management...8 4 Build Management...10 4.1 Buildtools...10 4.1.1 Ant...10 4.1.2 Maven2...10 4.2 Continuous Integration...12 4.2.1 CruiseControl...13 5 Dependency Management...16 5.1 Arten von Abhängigkeiten... 16 5.2 Verwaltung der Abhängigkeiten im Build-Prozess... 17 5.3 Verwaltung der Abhängigkeiten beim Release Management...17 6 Release Management... 18 6.1 Definition Release...18 6.2 Termin/Umfang eines Releases... 18 6.3 Releasenotes...18 6.4 Versionsnummer des Releases...19 6.5 Archivierung von Releaseständen...19 7 Quellen...19 8 Abbildungsverzeichnis...19

1 Einleitung Diese Arbeit soll einen Überblick über die verschiedenen Disziplinen des Configuration Managements geben. Es sollen hier Anworten auf die Fragen Was ist Configuration Management? Warum ist Configuration Management nötig? Wie kann man die Ziele des Configuration Managements am besten erreichen? gegeben werden. Um den Begriff Configuration Management etwas näher zu beschreiben soll hier die folgende Definition für diesen Begriff vom ANSI (American National Standardization Institute) erwähnt werden: Configuration Management... is a management process for establishing and maintaining consistency of a product's performance, its functional and physical attributes, with its requirements, design and operational information, throughout its life. Die Hauptaufgabe des Configuration Managements also ist es die Konsistenz des Produkts herzustellen und zu erhalten und es in Einklang zu bringen mit den verschiedenen Anforderungen die an das Produkt gestellt. Es sind verschiedene Techniken, Prozesse und Tools nötig, um diese Aufgabe zu erfüllen. Einige von ihnen werden im folgenden vorgestellt.

2 Version Management Die Aufgabe des version managements ist es dafür zu sorgen, dass mehrere Entwickler zusammen an einem Projekt arbeiten können. Das schließt natürlich insbesondere ein, dass mehrere Entwickler auch gemeinsam an einer Datei arbeiten können, ohne dass vorher abgesprochen werden muss, wer wann an dieser Datei arbeitet. Natürlich muss auch nachvollziehbar sein, wer welche Änderungen an einer Datei vorgenommen hat, z.b. wenn Fragen zu diesen Änderungen aufkommen oder wenn diese Änderung Fehler enthält. Gerade für den letzteren Punkt ist es weiterhin notwendig, dass Änderungen auch rückgängig gemacht werden können. Alle diese Aufgaben muss also ein version mangement tool erfüllen. Allerdings existieren verschiedenste Konzepte, wie diese Augaben erfüllt werden können. 2.1 Lagerung der Dateien 2.1.1 Zentraler Ansatz In den meisten Fällen sind versions management tools als Client-Server-Systeme realisiert. Dabei stellt der Server das so genannte Repository bereit, in dem alle zum Projekt gehörigen Dateien verwaltet werden. Die Dateien können dabei entweder in einem bestimmten Filesystem oder auch in einer Datenbank gespeichert sein. Die Frage ist jetzt natürlich, wie Änderungen an Dateien genau vorgenommen werden. Auch dazu gibt es zwei Verfahrensweisen: 2.1.1.1 Lock-Modify-Write Bei diesem Ansatz wird eine Datei, bevor Änderungen durchgeführt werden, durch den Benutzer gesperrt (lock), d.h. dass zu diesem Zeitpunkt nur dieser Benutzer die Datei verändern kann. Nach der Sperrung nimmt er seine Änderungen an der Datei vor (modify), und überträgt sie ins Repository (write) (s. Abbildung 1).

Abbildung 1: Lock-Modify-Merge Strategie Diese Strategie wird auch Pessimistic Revision Control genannt, da sie am worst case ausgerichtet ist. Dieser worst case tritt dann auf, wenn zwei Benutzer etwas an derselben Stelle in einer Datei verändern, was natürlich zu Konflikten führt. Diese kann bei diesem Verfahren nicht passieren. Allerdings tritt dieser Fall doch eher selten auf. Viel wahrscheinlicher dagegen ist es, dass zwei Benutzer an unterschiedlichen Dateien oder an unterschiedlichen Stellen in einer Datei arbeiten. Dann ist das Lock-Modify-Merge-Verfahren im Nachteil, da es einen für diese Fälle unnötigen Verwaltungsoverhead hat und außerdem auch die Gefahr besteht, dass ein Nutzer vergisst eine Datei wieder freizugeben, woraufhin kein Anderer mehr an dieser Datei arbeiten kann. Deshalb verfahren die meist benutzten version management tools nach einer anderen Strategie: 2.1.1.2 Copy-Modify-Merge Bei diesem Verfahren muss der Benutzer zuerst eine lokale Arbeitskopie des Repositories angelegen (copy). Darauf folgend werden die Änderungen durchgeführt (modify) und an das Repository übertragen. Da die Datei, die gerade bearbeitet wird, hierbei für andere Benutzer nicht gesperrt ist, kann es allerdings passieren, dass inzwischen ein anderer Benutzer diese Datei ebenfalls bearbeitet hat und seine Änderung zum Repository übermittelt hat. In diesem Fall bekommt der Benutzer eine Meldung beim Übertragen, dass seine lokale Arbeitskopie nicht mehr auf dem neuesten Stand ist. Wenn dann die neueste Version abgerufen wird, werden im Normalfall, die Änderungen, die ein anderer Benutzer vorgenommen hat, mit den

eigenen automatisch zusammengeführt (merge). Im oben beschriebenen worst case, dass genau die selbe Stelle bearbeitet wurde, muss der Benutzer manuell die beiden Versionen zusammenführen und dann ans Repository übermitteln (s. Abbildung 2). Abbildung 2: Copy-Modify-Merge Strategie mit Konflikt Abbildung 3: Copy-Modify- Merge Strategie ohne Konflikt 2.1.2 Dezentraler Ansatz Die Arbeitsweise bei Systemen, die mit einem dezentralen Ansatz arbeiten, unterscheidet sich meist nicht wesentlich von dem zentralen Ansatz. Allerdings ist es hierbei nötig, dass sich alle Benutzer kennen, also wissen wer an einem Projekt arbeitet, da es ja kein zentrales Repository gibt. Die aktuellste Version liegt dann immer bei dem Benutzer, der als letztes Änderungen durchgeführt hat und die anderen Benutzer können sich diese Version von ihm herunterladen. 2.2 Versionierung Allen Systemen gemein ist, dass, wenn Änderungen durchgeführt wurden, eine neue Version erstellt wird. Entweder wird für die Dateien, die gerade bearbeitet wurden, eine neue Version erstellt oder aber für das gesamte Repository, d.h bei jeder Änderung wird die Versionsnummer für das gesamte Repository inkrementiert. Der naive Ansatz die verschiedenen Versionen der Dateien zu speichern wäre, die Datei zu kopieren, jedes Mal wenn Änderungen vorgenommen werden. Wenn dieser Ansatz vefolgt werden würde, würde das Repository natürlich schon nach kurzer Zeit eine enorme Menge Speicherplatz benötigen. Deshalb speichern versions management tools nicht die gesamte Datei bei einer Änderung, sondern nur den Teil, der sich geändert hat. Das heißt die Datei wird einmal komplett im Repository gespeichert und jede Änderung wird nur inkrementell zu dieser kompletten Variante festgehalten. Die komplette Variante entspricht dabei entweder dem ersten oder letzten also aktuellsten Stand der Datei.

Es existiert also die komplette Änderungshistorie für jede Datei. So können z.b. Dateien in älteren Versionen wieder abgerufen werden oder auch Vergleiche zwischen zwei Versionen einer Datei durchgeführt werden. Der Ansatz nicht einzelne Dateien zu versionieren bietet dabei den Vorteil, dass man immer genau weiß, wie der Rest des Repositories aussah als eine bestimmte Änderung an einer Datei durchgeführt wurde. Wenn z.b. Änderungen an zwei Dateien vorgenommen wurden, die beide rückgängig gemacht werden sollen, muss man sich im Fall, dass jede Datei einzeln versioniert wird, merken welche Dateien bearbeitet wurden. Allerdings bieten version managemnet tools eine Möglichkeit dieses Merken zu automatisieren. 2.3 Branches und Tags 2.3.1 Tags Mit Hilfe eines Tags kann man den Stand von einer beliebigen nicht leeren Menge von Dateien sichern und, wenn man ihn braucht, später wieder abrufen. Man kann sich ein Tag als Punkt auf dem Zeitstrahl vorstellen, zu dem man immer wieder zurückspringen kann (s. Abb //TODO). Eine wirklich wichtige Rolle spielen Tags allerdings nur bei Systemen, die Dateien einzeln versionieren (s.o.), bei Systemen, die das gesamte Repository versionieren sind sie lediglich ein Label für einen bestimmten Stand, da ja sowieso jeder Stand wieder abgerufen werden kann. 2.3.2 Branches Ein Branch ist eine Verzweigung des Zeitstrahls, auf der parallel gearbeitet werden kann. Abbildung 4: Tags und Branches

Ebenso wie ein Tag kann man einen Branch für eine beliebige Menge von Dateien ziehen. Wenn jetzt Änderungen auf dem Hauptzweig (trunk) durchgeführt werden, haben diese keine Auswirkungen auf den Branch und genauso andersherum. Branches werden z.b. dafür genutzt an mehreren Versionen eines Programms zu arbeiten. So werden z.b. an einer älteren Version, die schon veröffentlicht wurde, nur noch bugfixes durchgeführt, wogegen auf dem Trunk neue Funktionalität eingebaut wird. Wenn Änderungen, die an einem Zweig durchgeführt werden, auch in anderen Zweigen erscheinen sollen, müssen diese mit einem speziellen Kommando in die anderen Zweige überführt werden, was allerdings sehr aufwendig werden kann, wenn sich diese Zweige stark unterscheiden. 3 Change Management Eine wichtige Frage in Sofwareprojekten ist, wie man auf Änderungswünschen verfährt. Hierbei sind natürlich in erster Linie größere Änderungen zu beachten, z.b. wenn Anforderungen geändert werden, aber auch kleinere im Programm gefundene Fehler bedürfen eines festgelegten Prozesses, wie mit ihnen zu verfahren ist. Schließlich sind auch bei kleinen Änderungen Resourcen einzuplanen und die Ergebnisse zu überprüfen. Nun ist es schwer einen exakten Prozess vorzugeben, der alle Probleme löst, wenn man sich nur an ihn hält. Der im Folgenden vorgestellte Prozess ist deswegen nur als Schablone zu verstehen und nicht als absolute Lösung: Änderungsanfrage erstellen Änderungsanfrage überprüfen Gültig? Änderungsanfrage an CCB übermitteln Änderungsanfrage in Datenbank aufnehmen Implementierung und Aufwand schätzen Genehmigt? Änderungsanfrage verwerfen Implementieren und testen der Änderung Neue Version des Programms erstellen

1. Änderungsanfrage erstellen Zuerst ist natürlich nötig eine Änderungsanfrage zu erstellen. Dieses kann von versieden Personen durchgeführt werden. Änderungen der Anforderungen werden meist von Kunden gewünscht, gefundene Fehler dagegen werden (im besten Fall) von Testern oder auch von Entwicklern gemeldet. Um Missverständnisse und daraus folgend zu viel oder zu wenig geleistete Arbeit zu vermeiden, muss diese gewissen Ansprüchen genügen. Erst einmal sollte klar sein, wer diese Änderungsanfrage erstellt hat, um Rückfragen an den richtigen Ansprechpartner richten zu können. Auch wenn es eigentlich selbstverständlich ist, soll hier darauf hingewiesen werden, dass es von höchster Wichtigkeit ist, den Änderungswunsch exakt zu beschreiben. In jeder Änderungsanfrage sollte die Programmversion enthalten sein, in der die Änderung vorgenommen werden soll. Weiterhin muss bei gefundenen Fehler genau beschrieben sein, in welcher Situation, mit welchen Daten, welcher Fehler aufgetreten ist, damit dieser auch reproduziert und dann behoben werden kann. So kann z.b. mit der Erklärung Wenn ich den Button OK anklicke, stürzt das Programm ab. niemand etwas anfangen. Wenn dagegen beschrieben ist Wenn ich einen neuen Benutzer xyz anlegen will und in diesem Dialog auf OK klicke, stürzt das Programm ab kann der Fehler leicht nachvollzogen werden. 2. Änderungsanfrage überprüfen Wenn eine Änderungsanfrage erstellt wurde, ist zu überprüfen, ob sie den o.g. Kriterien genügt. Wenn das nicht der Fall ist muss sie geändert oder zurückgenommen werden. 3. Implementierung und Aufwand abschätzen Natürlich ist es für die Planung sehr wichtig eine Abschätzung zu haben, wie lange es dauert diese Änderung zu implementieren. Um den Aufwand realistisch abschätzen zu können, ist es vorher nötig ein konzeptuelles Design durchzuführen, wie diese Änderung implementiert werden kann. Mit Hilfe dieses Designs kann man dann relativ genau den Aufwand schätzen. 4. Änderungsanfrage in Datenbank aufnehmen Um die durchgeführte Änderung später auf ihre Richtigkeit hin überprüfen zu können und um den aktuellen Entwicklungsstatus überwachen zu können, ist es nötig die Änderung elektronisch zu speichern. Das ist am besten in einer Datenbank möglich. 5. Änderungsanfrage an das Change Control Board übermitteln Nach der Speicherung der Anfrage, wird diese an das Change Control Board übermittelt. Die genaue Zusammensetzung und Größe dieses Gremiums hängt sehr von der Größe des Projekts ab, seine Aufgabe jedoch ist es die Änderungsanfrage von einem organisatorischen anstatt eines entwicklungstechnischen Standpunkts zu bewerten. Dieses Gremium sollte aus Mitgliedern bestehen, die nicht in die Entwicklung involviert sind. Bei großen Projekten können ihm auch Vertreter des Kunden angehören. 6. Implementieren und testen der Änderung Nach erfolgreicher Überprüfung durch das CCB wird die Änderung implementiert und anschließend getestet. Auch hierfür ist es sehr wichtig, dass die Anfrage gespeichert wurde, um die Anforderungen mit dem IST-Zustand vergleichen zu können.

7. Neue Version des Programms erstellen Wurden die durchgeführten Änderungen erfolgreich getestet, können sie nun in die neue Version des Programms einfließen. 4 Build Management Zu einem Softwareprojekt gehören normalerweise viele Dateien die in eine ausführbare Datei integriert werden müssen. Erstmal müssen alle Quellcode Dateien übersetzt werden, es müssen Resourcedateien (z.b. Grafiken) integriert werden und es muss aus diesen Dateien ein Programm erstellt werden, welches dann auch ausführbar ist. Bei kleinen Projekten ist es ohne Probleme möglich diese Aufgabe manuell bzw. mit Unterstützung der Entwicklungsumgebung zu lösen. So ist es z.b. ohne großen Aufwand möglich, eine Menge von class-dateien in ein ausführbares jar-archive zu packen oder aus C++-Dateien eine exe-datei zu erstellen. Wenn allerdings zusätzliche Bibliotheken oder mehrere ausführbare Dateien erstellt werden müssen, wird dieser Vorgang schnell sehr aufwändig und unübersichtlich und damit natürlich auch fehleranfällig. Deswegen ist es spätestens, wenn die Dateien eines Projekts nicht mehr in einem Projekt einer Entwicklungsumgebung verwaltet werden können oder sollen, notwendig ein Tool einzusetzen, welches den Build-Vorgang automatisiert ausführt. 4.1 Buildtools 4.1.1 Ant Es gibt diverse Tools, die diese Aufgabe erledigen. Eines der bekanntesten Programme ist ant. Ant wird über eine Xml-Datei konfiguriert, in der man einstellt welche Tasks zum Bauen des Programms ausgeführt werden sollen. Zum Beispiel gibt es einen Task über den das Kompilieren der Source-Dateien gesteuert wird. Für diesen gibt man das Quell- und das Zielverzeichnis und den Compiler an, welcher bei Aufruf dieses Tasks gestartet wird und dann die angegebenen Dateien übersetzt. Allerdings setzt ant auf einer niedrigen Ebene an. Letztendlich bietet ant nicht viel mehr Funktionalität als ein Skript oder eine Sammlung von Skripten, wenn es natürlich auch deutlich komfortabler zu konfigurieren ist. 4.1.2 Maven2 Auf einer höheren Ebene setzt dagegen das Tool maven an. Maven basiert auf der Idee, dass jedes Projekt letztendlich die gleichen Anforderungen an ein Buildtool stellt. So ist es bei (fast) jedem Projekt notwendig Dateien zu kompilieren, automatisch Unit-Tests laufen zu lassen und die Dateien zu einer ausführbaren Datei zusammenzupacken. Das heißt, dass die Tasks, die man in ant definieren muss, für

sehr viele Projekte die gleichen oder sich zumindest sehr ähnlich sind. Deswegen ist es für den Einsatz von maven nicht nötig Tasks zu definieren, sondern nur die Projektstruktur. In Maven2 sind je nach Art des Projekts (Jar, War, Ear o.ä.) die übichen Tasks (bei Maven2 Phasen genannt) schon vordefiniert. So existieren z.b. für ein Jar-Projekt folgende Phasen: process-resources Verarbietet die Ressourcen compile Übersetzt die Quellcode-Dateien process-test-resources Verarbietet die Test-Ressourcen test-compile Übersetzt die Quellcode-Dateien für die Tests test Führt die JUnit-Tests durch package Erstellt eine Jar-Datei aus den kompilierten Sourcen install Legt die Jar-Datei in einem lokalen Repository ab (s.u.) deploy Legt die Jar-Datei in einem globalen Repository ab (s.u.) Jede Phase baut dabei auf den vorangegangenen auf, d.h. der Aufruf mvn package verarbeitet die Ressourcen, überstzt alle Klassen und führt die Tests aus. Da alle diese Phasen vordefiniert sind, ist leicht möglich, ein Projekt aufzusetzen, auf dem die Phasen ausgeführt werden können: Konfiguriert wird maven ebenso wie ant über eine Xml-Datei, die standarmäßig pom.xml heißt (POM = Project Object Model). Eine pom.xml für maven könnte z.b. so aussehen: <project xmlns="http://maven.apache.org/pom/4.0.0" xmlns:xsi="http://www.w3.org/2001/xmlschema-instance" xsi:schemalocation="http://maven.apache.org/pom/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd"> <modelversion>4.0.0</modelversion> <groupid>com.mycompany.app</groupid> <artifactid>my-app</artifactid> <packaging>jar</packaging> <version>1.0-snapshot</version> <name>maven Quick Start Archetype</name> <url>http://maven.apache.org</url> <dependencies> <dependency> <groupid>junit</groupid> <artifactid>junit</artifactid> <version>3.8.1</version> <scope>test</scope> </dependency> </dependencies> </project> Bei Einhaltung der richtigen Ordnerstruktur genügt diese pom.xml, um alle o.g. Phasen ausführen zu können. Standardmäßig setzt Maven2 folgende Ordnerstruktur voraus:

my-app -- pom.xml `-- src -- main -- java `-- resources `-- test -- java `-- resources In dem Projektverzeichnis liegt die entsprechende pom-datei und der Ordner src. In diesem finden sich zwei Unterverzeichnisse main und test. In main liegen alle Dateien, die für die Ausführung des Programms erforderlich sind. Dies sind zum einen Quellcode-Dateien, die sich im Unterordner java befinden. Außerdem existiert noch ein Verzeichnis resources, in dem die notwendigen Resource-Dateien zu finden sind. Die gleiche Struktur findet sich im Ordner test, hier allerdings liegen die Dateien, die für JUnit-Test benötigt werden. Auch Abhängigkeiten lassen sich sehr leicht definieren. Anzugeben ist nur der Name, die Gruppe, die Version und, wenn es sich nicht um eine Jar-Datei handelt, der Typ des Projekts, zu dem eine Abhängigkeit besteht, Ein Pfad, wo diese Datei zu finden ist, muss nicht angegeben werden. Maven2 benutzt einen speziellen Ordner (Repository) dazu sämtliche Artefakte, die durch Maven2 erstellt wurden, zu verwalten. Durch den Befehl mvn install erreicht man, dass ein Projekt in dieses Repository übernommen wird. Für Libraries oder Frameworks, die in vielen Projekten eingesetzt werden (z.b. JUnit), gibt es auch diverse globale Repositories, die über http erreichbar sind. Durch diverse Plugins, die für Maven2 existieren, sind fast sämtliche Aufgaben, die in einem Projekt anfallen zu automatisieren und leicht zu konfigurieren. 4.2 Continuous Integration Heutzutage existieren kaum noch Softwareprojekte, deren Umfang so gering ist, dass eine Person das gesamte Projekt alleine bewältigen kann. Wenn allerdings mehrere Leute an einem Projekt arbeiten. Dies kann zu Problemen führen. Wenn z.b. Entwickler A an einer Library arbeitet und Entwickler B an einem Teilprojekt, dass diese Library verwendet, kann es vorkommen, dass A Änderungen an der Library vornimmt, ohne dass Person B diese mitbekommt. Das kann zum Releaseschluss dazuführen, dass sämtliche zum Projekt gehörenden Komponenten nicht zusammenpassen. Dies würde zu einem unkalkulierbaren Aufwand am Ende eines Projekts/Releases führen, den man nicht in Kauf nehmen will.

Daher ist es notwendig zu jedem Zeitpunkt die Integration der einzelnen Komponenten überwachen zu können. Es existieren diverse Tools, die die Aufgabe der kontinuierlichen Integration bewerkstelligen. Im weiteren wird exemplarisch als ein Vertreter dieser Continuous Integration Tools CruiseControl vorgestellt. 4.2.1 CruiseControl CruiesControl bietet die Möglichkeit ein Repository oder einen Teil des Repositories zu überwachen, bei Änderungen einen Build zu starten und anschließend die Ergebnisse des Builds zu veröffentlichen. CruieControl übernimmt also nur administrative Aufgaben, d.h. es wird weiterhin ein Versionskontrollsystemen wie Subversion und ein Buildtool wie Maven2 benötigt. Abbildung 5: Funktionsweise von CruiseControl

In Abbildung 5 ist das Verhalten von CruiseControl exemplarisch für die Zusammenarbeit mit CVS und Ant abgebildet. Sobald die Entwickler Änderungen an CVS übermittelt haben, registriert CC diese. Es wird jetzt nicht zwangsläufig ein Build angestoßen, da es bei großen Projekten, deren Build vielleicht mehrere Stunden dauert, zu einer enormen Belastung der Hardwareressourcen führen würde, wenn bei jeder Änderung im Repository ein Build gestarten wird. Daher kann in CC flexibel konfiguriert werden zu welchem Zeitpunkt, bzw. in welchen Intervallen gebaut werden soll. Zu diesem Zeitpunkt wird dann überprüft, ob Änderungen stattgefunden haben. Wenn dies der Fall ist, wird Ant aufgerufen, welches dann das Projekt baut. Nach Abschluss des Builds übermittelt Ant dann die Buildresultate zurück an CC, welches sie entsprechend veröffentlich kann. Standardmäßig werden die Ergebnisse auf einer Website veröffentliche, es können aber auch Mails verschickt oder diverse Aktionen durchgeführt werden. Konfiguriert wird CC über eine Xml-Datei (config.xml), die z.b. so aussehen kann: <cruisecontrol> <project name="sampleccproject"> <bootstrappers> <currentbuildstatusbootstrapper file="../logs/currentbuild.txt" /> <svnbootstrapper file="build-cc.xml" localworkingcopy="../../../workarea/sampleccproject" /> </bootstrappers> <modificationset quietperiod="60" > <svn LocalWorkingCopy="../../../WorkArea/SampleCCProject"/> </modificationset> <schedule interval="60" > <ant antworkingdir="../../../workarea/sampleccproject" buildfile="build-cc.xml" /> </schedule> <log dir="../logs/sampleccproject"> <merge dir="../../../workarea/sampleccproject/reports/junit/data"/> </log> <publishers> <currentbuildstatuspublisher file="../logs/currentbuild.txt" /> <artifactspublisher dir="../../../workarea/sampleccproject/dist" dest="../logs/sampleccproject" /> <email mailhost="smtp.yourdomain.com" returnaddress="buildmaster@yourdomain.com" skipusers="true" reportsuccess="fixes" subjectprefix="[cruisecontrol]" buildresultsurl="http://buildserver:8080/cruisecontrol/results"> <failure address="developers@yourdomain.com" /> <success address="developers@yourdomain.com" /> </email> </publishers> </project> </cruisecontrol>

Im Folgenden möchte ich die hier verwendeten Tags kurz vorstellen: <cruisecontrol> Dies ist das Wurzeltag. Innerhalb dieses Tags werden die einzelnen Projekte definiert. <project> In diesem Element wird die Konfiguration für ein Projekt vorgenommen. Da CC auch mehrere Projekte unterstützt, ist es nötig, dass die Projekte einzeln konfiguriert werden können. <bootstrappers> Hier können Aktionen definiert werden, die ausgeführt werden sollen, bevor der Build beginnt. Es kann z.b. definiert werden, dass ein Log-Eintrag für jeden gestarteten Build erzegt wird oder es können die letzten Änderungen aus einem Subversion-Repository geholt werden. <modificationset> Mit Hilfe dieses Tags kann ein Repository auf Änderungen überwacht werden, die dann zum gegebenen Zeitpunkt einen Build auslösen. Es ist auch möglich einzustellen, dass CC nicht auf eine Änderung warten soll, um das Projekt zu bauen. <schedule> Über dieses Element wird eingestellt, in welchem Intervall ein Build gestartet werden soll und welches Buildtool aufgreufen wird. <log> Über dieses Tag wird konfiguriert, welche Ergebnisse des Builds veröffentlicht werden sollen. So können hier z.b. noch die Ergebnisse der JUnit-Tests die Ant produziert in die Standardausgabe von CC eingefügt werden. <publishers> Hier wird definiert wie die Ergebnisse veröffentlicht werden sollen. Es können E-Mails zur Benachrichtigung verschickt werden oder auch bestimmte Dateien in angegebenes Verzeichnis verschoben werden. Standardmäßig werden die Ergebnisse des Builds auf einer Website veröffentlicht, die dann z.b. so aussehen kann:

Abbildung 6: Webausgabe von CruiseControl 5 Dependency Management Es ist aus verschiedenen Gründen wichtig zu wissen, welche Abhängigkeiten zu anderen Projekten in einem Projekt bestehen. 5.1 Arten von Abhängigkeiten Man kann Abhängigkeiten anhand verschiedener Kriterien klassifzieren: 1. Sind es externe oder interne Abhängigkeiten? Interne Abhängigkeiten bestehen zu anderen Projekten der gleichen Firma oder des gleichen Entwicklungsteams. Dagegen müssen externe Abhängigkeiten von anderen Firmen o.ä. geholt werden. 2. Zu welcher Art von Artefakt besteht eine Abhängigkeit. Meistens werden von Projekten diverse Libraries vorrausgesetzt, die vom eigenen Programm verwendet werden. Es können aber genauso gut Abhängigkeiten zu bestimmten Ressourcen oder auch zu anderen ausführbaren Programmen bestehen. 3. Zu welchem Zeitpunkt werden Abhängigkeiten benötigt? Libraries werden meistens schon beim Build benötigt. Bei Ressourcen oder externen Programmen kommt es dagegen häufig vor, dass diese erst zur Laufzeit des Programms benötigt werden.

5.2 Verwaltung der Abhängigkeiten im Build- Prozess Um ein Projekt oder ein Teilprojekt desselben zu bauen, ist es natürlich notwendig zu wissen, welche Abhängigkeiten bestehen, zu welchem Zeitpunkt diese Abhängigkeiten aufgelöst werden und ob es sich um externe oder interne Abhängigkeiten handelt. Es muss sichergestellt werden, dass die Artefakte, zu denen Abhängigkeiten bestehen, auch zum Zeitpunkt des Builds bereitstehen. Hierfür bietet Maven2 eine komfortable Möglichkeit an dieses sicherzustellen. Name und Version der von einem Projekt benötigten Artefakte werden in die Maven2- Konfigurationsdatei dieses Projekts eingetragen. Dadurch findet Maven2 diese Artefakte, solange sie sich in einem der konfigurierten Maven2-Repositories befinden (s. 4.1.2). Interne Abhängigkeiten werden, wenn sie in den Repositories nicht vorhanden sind, automatisch erzeugt, wenn es sich bei beiden Projekten um Teilprojekte desselben Projekts handelt. Außerdem kann Maven2 auch transitive Abhängigkeiten verwalten: Projekt A benötigt die Abhängigkeit B, Projekt C benötigt das Projekt A und B als Abhängigkeit. Mit Maven2 ist dann nicht nötig Projekt B im Projekt C als Abhängigkeit zu definieren, da dies bereits im Projekt A geschehen ist. 5.3 Verwaltung der Abhängigkeiten beim Release Management Allerdings ist dieser Weg der Abhängigkeitsverwaltung beim Erstellen eines Releases oder bei der Auslieferung eines Teilprojekts nicht praktikabel. Wenn man diesen Weg wählen würde, wäre es nötig die Abhängigkeiten aus den Maven2- Konfigurationsdateien für dieses Projekt und, da Maven2, wie gesagt, transitive Abhängigkeiten unterstützt, rekursiv für sämtliche Projekte, zu denen Abhängigkeiten bestehen, abzulesen. Daher ist es für das Release Management notwendig an einer zentralen Stelle (z.b. in einer Datenbank) nicht transitiv alle Artefakte, die ein Projekt benötigt, aufzulisten. So kann sichergestellt werden, dass bei der Erstellung eines Releases keine benötigte Datei vergessen wird.

6 Release Management Um einen Plan erstellen, wann ein Release erstellt wird und welche Änderungen in diesem Release veröffentlicht werden, ist es notwendig zu wissen, was ein Release überhaupt ist. 6.1 Definition Release Ein Release ist die installierbare und ausführbare Zusammenstellung aller zum Projekt gehörigen Source und Resource Dateien in einer bestimmten Konfiguration. 6.2 Termin/Umfang eines Releases Da die Version natürlich installierbar und ausführbar sein soll, ist es wichtig, dass eher zu wenig als zu viele Änderungen für ein Release einzuplanen. Wenn sich zum Releaseschluss oder kurz vorher herausstellt, dass die eingeplanten Entwicklungen nicht beendet werden konnten oder können, müssen entweder die angefangen Änderungen für eine bestimmte Entwicklung rückgängig gemacht werden, was u.u. mit großem Aufwand verbunden sein kann oder der Zeitpunkt, zu dem ein Release freigegeben wird, muss verschoben werden. Wenn Lieferungen an Kunden zu einem bestimmten Termin schon zugesagt wurden und dieser nicht eingehalten werden kann, kann dies u.u. zu hohen Kosten und/oder zu Imageverlust führen. Neben der übermäßigen Einplanung von Änderungen kann auch die Integration der einzelnen Komponenten die Releasefreigabe verzögern. Wenn die Komponeneten erst kurz vor Releaseschluss in ein Gesamtsystem integriert werden, ist es wahrscheinlich, dass diese nicht, wie gewünscht, zusammenarbeiten. Das hat im Allgemeinen einen erheblichen Zeitaufwand zur Folge, durch den der geplante Termin oft nicht mehr eingehalten werden kann. Daher sollte man zu jedem Zeitpunkt sicherstellen, dass die Komponenten auch in einem System problemlos zusammenarbeiten (s. 4.2). 6.3 Releasenotes Genauso so wichtig wie eine gute Dokumentation der Arbeiten, die in einem Release enthalten sein sollen, ist eine Dokumentation der Änderungen, die tatsächlich in einem Release enthalten sind. Nun ist es höchstwahrscheinlich nicht durchführbar kurz vor Releaseschluss jede(n) EntwicklerIn zu fragen, welche Änderungen er/sie in diesem Release implementiert hat. Daher ist es notwendig ein strukturiertes Vorgehen zu finden, wie die Releasenotes erstellt werden. Eine Möglichkeit für ein solches Vorgehen besteht darin ein Ticketsystem zu benutzen, in welchem Änderungsanfragen gespeichert sind. Wenn dort für jede Änderungsanfrage beschrieben ist, ob/wie sie umgestzt wurde, kann man daraus automatisch Releasenotes generieren.

6.4 Versionsnummer des Releases Jedes Release sollte jederzeit eindeutig identifizierbar sein. Daher sollte man für jedes Release eine eindeutige Versionsnummer vergeben. Diese sollte einer gewissen Gesetzmäßigkeit folgen, die z.b. so aussehen kann: Versionsnummer besteht aus drei Zahlen X.Y.Z wobei X für ein Release erhöht wird, in dem große funktionale Änderungen durchgeführt wurden, Y dann erhöht wird, wenn kleine funktionale Änderungen stattgefunden haben und Z inkrementiert wird, wenn nur Bugs gefixed wurden (Service Pack). 6.5 Archivierung von Releaseständen Wenn ein Release freigegeben wurde, heißt das nicht, dass nie wieder Änderungen an diesem Release vorgenommen werden. Sobald dort Fehler gefunden werden, müssen diese natürlich auf diesem Stand des Programms behoben werden, auch wenn vielleicht schon ein oder zwei weitere Releases danach freigegeben wurden. Diese Möglichkeitet bietet das Anlegen von Branches im Versionskontrollsystem (s. 2.3.2). Dort können dann Fehler behoben werden, ohne dass andere Versionen des Programms davon betroffen sind. Außerdem hat man so sichergestellt, dass die Sourcen von jeder Version des Programms zu jedem Zeitpunkt wieder abrufbar sind. 7 Quellen [1] http://de.wikipedia.org/wiki/versions verwaltung [2] http://de.wikipedia.org/wiki/release_management [4] http://de.wikipedia.org/wiki/ant [3] http://swe.fhso.ch/modules/ch13-confmgmt/scm%20lecture%20notes.pdf [4] Ian Sommerville Software Engineering 5. Auflage [5] http://www.phys.uu.nl/~glebbeek/cvs.html [6] http://ant.apache.org/index.html [7] http://cruisecontrol.sourceforge.net/index.html [8] http://www.oio.de/cruisecontrol.htm 8 Abbildungsverzeichnis Abbildung 1: Lock-Modify-Merge Strategie...5 Abbildung 2: Copy-Modify-Merge Strategie mit Konflikt...6 Abbildung 3: Copy-Modify-Merge Strategie ohne Konflikt... 6 Abbildung 4: Tags und Branches...7 Abbildung 5: Funktionsweise von CruiseControl...13 Abbildung 6: Webausgabe von CruiseControl... 16