Software- Konfigurationsmanagement

Software- Konfigurationsmanagement Ausarbeitung zum Referat im Projekt Softwaretechnik WS 07/08 Martin Kasparick Mat-Nr: 221737 sparr@cs.tu-berlin.de

Inhaltsverzeichnis 1) Einleitung 1.1)Definition 1.2)Motivation 1.3)Geschichte 2) Planung des Konfigurationsmanagements 2.1) Einleitung 2.2) Definitionen 2.3) Identifikation der Konfigurationselemente 2.4) Konfigurationsdatenbank 3) Change Management 3.1) Einleitung 3.2) Ablauf 4) Konfigurationsprüfung 5) Versions- und Releaseverwaltung 5.1) Einleitung 5.2) Grundbegriffe 5.3) Versionskontrolle 5.3.1) Versionsidentifikation 5.3.2) Versionsverwaltungstools 5.4) Releasekontrolle 6) System Building 6.1) Einleitung 6.2) System-Building-Tools 6.3) Continuous Build 7) Quellenangabe

1) Einleitung 1.1) Definition W. Tichy: Software-Konfigurationsmanagement (SKM) ist die Disziplin zur Verfolgung und Steuerung der Evolution von Software. [4] 1.2) Motivation Große Softwaresysteme setzen sich aus zahlreichen Komponenten zusammen, welche in der Regel unabhängig voneinander existieren. Weiterhin können solche Systeme in verschiedenen Konfigurationen nebeneinander existieren. So kann es beispielsweise Konfigurationen für verschiedene Hardware geben, oder auch für verschiedene Betriebssysteme (Linux-Version, Windows-Version,...). Es muss daher irgendwie gewährleistet sein, dass solche komplexen und langlebigen Softwaresysteme entwickelbar und wartbar bleiben. Das leistet das Konfigurationsmanagement. Es ist verantwortlich den Überblick über die Unterschiede in Softwareversionen zu behalten und sicherzustellen,dass Versionen in einer kontrollierten Art und Weise erzeugt werden und Chaos vermieden wird. Typische Symptome von 'Entwicklungschaos', die durch SKM bekämpft werden sollen sind: Schon längst korrigierte Bugs (Fehler) tauchen in späteren Versionen wieder auf Ältere Releases können nicht wieder gebaut werden, da bestimmte Komponenten schon verändert worden sind Es gehen Dateien verloren oder ändern sich auf für den Entwickler nicht nachvollziehbare Weise Es existiert gleicher oder ähnlicher Code mehrfach in verschiedenen Projekten Es kommt zu Problemen wenn mehrere Entwickler die selbe Datei gleichzeitig verändert Es ist daher sinnvoll, dass die Entwicklung größerer Softwaresysteme auf festgelegten Standards beruht. Diese können sollten idealerweise in einer Art Konfigurationsmanagement-Handbuch festgehalten und so für jeden Beteiligten einsehbar sein. Konfigurationsmanagement hält die Software z.b. dadruch in einem wohldefinierten Zustand, dass die Entwicklungsgeschichte rückverfolgbar gemacht wird, sich überschneidende Änderungen verhindert oder abgeglichen werden, der Zustand von Konfigurationen und Releases überwacht wird, Fehlermeldungen und resultierende Korrekturen systematisch verwaltet werden und Versionsselektion automatisiert werden kann.

1.3) Geschichte Die Disziplin des Software-Konfigurationsmanagements (SKM) hat sich aus dem klassischen Konfigurationsmanagement entwickelt. Dieses wurde ca. 1950 für die US- Luft- und Raumfahrt entwickelt. Die Anfänge des SKM waren eher bescheiden, vieles wurde zunächst manuell durchgeführt. So wurde z.b. ein gleichzeitiges Arbeiten an bestimmten Modulen dadurch verhindert, dass diese an einer Tafel aufgelistet waren. Wenn ein Programmierer an einem dieser Module etwas verändern wollte, schrieb er einfach seinen Namen neben das entsprechende Modul. Nach Beendigung der Arbeit wischte er seinen Namen wieder weg und gab damit das Modul wieder frei. Die Anfänge des SKM wie wir es heute kennen, also automatisiert durch Tools, liegen in den 1970er Jahren mit Tools wie SCCS (Source Code Control System, 1972) und MAKE (1977). Im Jahre 1986 wurde der quasi-standard im Bereich der Versionsverwaltung, CVS, entwickelt. Heute sind SKM-Tools ein wichtiger und erfolgreicher Teil des Software- Werkzeugemarktes. Auch wenn sich SKM aus dem klassischen Konfigurationsmanagement entwickelt hat, gibt es jedoch wichtige Unterschiede. So muss SKM wesentlich schneller reagieren, da Software viel einfacher und billiger zu ändern ist und sich dadurch auch schneller ändert. Ein großer Vorteil des SKM gegenüber dem klassischen KM ist, dass es in weiten Teilen automatisierbar ist, was darauf zurückzuführen ist, dass Software komplett im Rechner gespeichert werden kann. 2) Planung des SKM 2.1) Einleitung Das Planen des Managementprozesses muss bereits während der Entwicklungsphase eines Systems beginnen. Ein wichtiger Teil des globalen Planungsprozesses ist es einen sog. CM-Plan aufzustellen. Dabei sollten u.a. folgende Aspekte berücksichtigt werden ([1]): Entscheiden welche Elemente überhaupt verwaltet werden sollen Ein formelles Identifikationsschema für diese Elemente erstellen Verantwortlichkeiten innerhalb des Projektes im Zusammenhang mit Konfigurationsmanagement klären Richtlinien für die Versions- und Änderungskontrolle erstellen Eine genaue Beschreibung wie Aufzeichnungen und Protokolle (Logs) des SKM-Prozesses aussehen sollen erstellen Entscheiden welche Werkzeuge (Tools) verwendet werden sollen und Festlegen wie die Konfigurationsdatenbank aussehen soll

Ein besonders wichtiger Punkt innerhalb des Planes ist es, die Verantwortlichkeiten zu klären. Es sollte definiert werden, wer für die Lieferung jedes Dokumentes oder jeder Softwarekomponente an das Konfigurationsmanagement und Qualitätssicherung zuständig ist. Dies muss nicht notwendigerweise der Autor des Dokumentes sein. In der Praxis werden oft die Leiter der einzelnen Entwicklungsteams mit solchen Aufgaben betraut. 2.2) Definitionen Wichtige Begriffe im Zusammenhang mit dem Planungsprozess sind 'Configuration Item' (Konfigurationselement, Softwareelement) und Baseline. Konfigurationselement (Software Configuration Item) Unter einem Konfigurationselement versteht man jede maschinenlesbare Informationseinheit ( Dokument ), die im Laufe eines Softwareprojektes entsteht. [4] Ein Softwaresystem ist daher eine Sammlung von verschiedenen Konfigurationselementen. Baseline Unter einer Baseline versteht man einen Referenzpunkt in der Entwicklung eines Systems, also ein bestimmter festgelegter Zustand aller Konfigurationselemente. Eine Baseline ist oft Startpunkt für die kontrollierte Entwicklung des Systems. 2.3 Identifikation der Softwareelemente Während der Entwicklung eines umfangreichen Softwaresystems werden mitunter tausende Dokumente produziert. Dies können z.b. technische Arbeitsdokumente, Memos, Protokolle von Gruppentreffen, Vorschläge, etc. sein. Es muss daher zunächst entschieden werden welche dieser Dokumente überhaupt in den SKM-Prozess mit einbezogen, d.h. verwaltet, werden sollen. Dies ist eine Kernaufgabe des SKM Planungsprozesses. Typischerweise werden Projektpläne, Spezifikationen, Entwürfe, Programme und zugehörige Testfälle als Konfigurationselemente verwaltet. Ist diese Entscheidung gefällt muss gewährleistet werden, dass jedes der verwalteten Softwareelemente innerhalb des Projektes eindeutig identifizierbar ist. Daher sollte ein eindeutiges Namensschema / Identifikationsschema festgelegt werden. Das am weitesten verbreitete Namensschema ist ein hierarchisches Schema. Hier werden die Dokumente in einer hierarchischen Struktur entsprechend ihrer Funktionalität geordnet. In einem solchen Schema könnten Namen z.b. wie folgt aussehen [1]: 1) PCL-Tools/Edit/Forms/Display/Code 2) PCL-Tools/Edit/Help/Query/HelpFrames Der erste Teil des Namen steht hier für den Projektnamen (PCL-TOOLS), der nächste Teil gibt an das es sich um einen Editor handelt, usw.. Dies spannt einen

hierarchischen Baum auf, dessen Blätter die eigentlichen Dokumente sind. Ein solches Schema hat jedoch den Nachteil, dass es projektspezifisch ist. Wenn Komponenten in mehreren Projekten verwendet werden sollen kann die hierarchische Struktur meist nicht ohne weiteres übernommen werden. Die Beschreibung dieses formellen Identifikationsschemas ist selbst ein kritisches Dokument und sollte daher unter Konfigurationskontrolle gestellt werden. 2.4 Konfigurationsdatenbank Die Konfigurationsdatenbank ist ein fundamentales Element des SKM. In ihr werden alle KM-relevanten Informationen eingepflegt und aufbewahrt. Ihre Hauptaufgabe ist es, bei der Einschätzung welchen Einfluss Systemänderungen haben zu helfen und Managementinformationen bereitzustellen. Neben den verwalteten Konfigurationselementen und deren Abhängigkeiten untereinander gibt die Datenbank z.b. Auskunft darüber: welche Kunden welche Version des Systems haben welche Voraussetzungen (Hardware, Betriebssystem, etc.) eine bestimmte Version benötigt welche Versionen es gibt und wann sie erstellt wurden, usw. welche Versionen von der einer Änderung einer bestimmten Komponente betroffen wären was für Änderungsanträge an eine Komponente ins System eingegeben wurden und deren Bearbeitungsstatus sowie welche Fehler einer bestimmten Version bisher gemeldet worden sind. Die KM-Datenbank kann entweder ein alleinstehendes System sein, oder in das Versionsverwaltungs- und -kontrollsystem integriert werden, wobei typischerweise eher der erste Fall umgesetzt wird. 3) Change Management 3.1) Einleitung Änderungen sind untrennbar mit der Evolution von Softwaresystemen verknüpft. Es wird daher ein Mechanismus benötigt, der sicherstellt, dass diese Änderungen in kosteneffizienter Weise umgesetzt werden. Ein weiteres Ziel des Change Management ist es Änderungschaos zu vermeiden. Wenn der Änderungsprozess nicht formal geregelt ist und jeder Entwickler nach gutdünken Änderungen vornehmen kann führt das unweigerlich zu Chaos. Change Management beinhaltet technische Analyse, Kosten-Nutzen-Analyse sowie Überwachen der Änderungen.

3.2) Ablauf Alle gewünschten Änderungen müssen zunächst als Änderungsantrag (Change Request) ins System eingegeben. Die Änderungsverwaltung stellt die Verbindung zwischen Änderungsanträgen, betroffenen Versionen und Korrekturen her. Eine Änderungsanfrage kann von jedem in irgendeiner Weise am Projekt Beteiligten (Entwickler, Kunde, Management, usw.) erstellt werden. Sie ist selbst Konfigurationselement und wird in der Konfigurationsdatenbank archiviert. Eine Anfrage sollte initial zumindest den Autor (Ersteller der Anfrage), eine Beschreibung der Änderung, den Grund der Änderung sowie die Dringlichkeit / Priorität enthalten. Nach Eingang der Anfrage muss entschieden werden ob sie überhaupt gültig ist. Dies ist nötig um Missverständnisse (z.b. das Fordern einer neuen Funktionalität welche schon implementiert nur evtl. schlecht dokumentiert ist) oder das mehrfache Eingeben bereits bekannter Fehler zu verhindern. Ist die Anfrage gültig muss der Aufwand der Änderung abgeschätzt werden. Dabei soll auch beurteilt werden, wie sich die Änderung auf das Gesamtsystem auswirkt. Zunächst wird eine technische Analyse erstellt, welche beinhaltet wie die Änderung umzusetzen / zu implementieren ist. Ebenfalls müssen die Kosten der Änderung sowie eventuell notwendig werdender Änderungen anderer Komponenten abgeschätzt werden. Nach erfolgter Aufwandsschätzung werden die Ergebnisse in die Änderungsanfrage (und damit in die Konfigurationsdatenbank) eingetragen. Die letztendliche Entscheidung ob eine Änderung umgesetzt wird liegt jedoch nicht beim KM sondern beim sog. Change Control Board (auch Configuration Control Board), CCB. Dieses ist eine 'externe' Gruppe die nicht aus Personen besteht die an der Softwareentwicklung teilnehmen. Dadurch ist es ihnen möglich die Entscheidung aus einer strategischen, das gesamte Projekt einbeziehenden, Sichtweise zu treffen, nicht aus einer technischen. Die Größe des CCB ist sehr unterschiedlich und hängt maßgeblich von der Größe des Softwareprojektes selbst ab. Jede Änderung an Softwarekomponenten sollte aufzeichnet werden. Die Menge der Aufzeichnungen einer Komponente stellt deren Änderungshistorie dar. 4) Konfigurationsprüfung Eine Konfigurationsprüfung sollte in reglemäßigen Abständen durchgeführt werden um sicherzugehen, dass die Entwicklung des Systems nicht 'auseinander läuft'. Dabei wird geprüft inwieweit der Zustand des überprüften (Sub-) Systems, dem in den dokumentierten Baselines oder Anforderungen entspricht. Dabei gibt es mehrere Arten von Prüfungen: Bei einer physischen Prüfung wird untersucht, ob das System mit der Spezifikation überein stimmt. Bei einer strukturellen Prüfung wird untersucht, ob das fertig-gebaute System

mit seiner technischen Dokumentation konsistent ist. Um diese Prüfungen durchführen zu können werden natürlich zahlreiche Informationen benötigt. Diese Informationen zusammenzutragen leistet das sog. Status Accounting. Hierbei werden alle für den Managementprozess notwendigen Informationen gesammelt, wozu ständig der Zustand aller kontrollierten Konfigurationselemente überwacht werden muss. Das Status Accounting trägt also auch dazu bei die Entwicklungsgeschichte der Systemkomponenten nachvollziehbar zu machen. 5) Versions- und Releasekontrolle 5.1) Einleitung Die Versions- und Releasekontolle beschäftigt sich mit der Identifikation und Beobachtung von verschiedenen Versionen und Releases eines Systems. Insbesondere die Versionskontrolle ist eines der bekanntesten und am weitesten verbreiteten Techniken des Software- Konfigurationsmanagements. Typische Fragen mit denen sich die Versions- und Releasekontrolle auseinandersetzt sind z.b.: Wie schließe ich fehlerhafte Änderungen wieder aus? Welche Änderungen wurden in einem bestimmten Release umgesetzt? Welche Konfiguration wurde an den Kunden geliefert? Was passiert wenn wir dem Kunden das neue Release liefert, er ein altes aber noch nicht installiert hat? 5.2) Grundbegriffe Für das Verständnis der eingesetzten Techniken ist es nötig zunächst einige Grundbegriffe zu klären. Version Eine Version ist eine Instanz eines Systems die sich von anderen Instanzen in irgendeiner Art unterscheidet. Unterschiede können z.b. in Performance, Funktionalität, Zielplattform oder der erfolgten Beseitigung von Fehlern liegen. Es sollte erwähnt werden, dass nicht nur Systeme, sondern auch Untersysteme (Komponenten) oder gar einzelne Konfigurationselemente in einer bestimmten Version vorliegen können. Release Ein Release ist eine bestimmte Version eines Systems, welche an Kunden ausgeliefert wird. Sie ist also eine installierbare und ausführbare Zusammenstellung (Konfiguration) von Konfigurationselementen. Sie enthält jedoch nicht bloß das eigentliche Programm sondern ebenso Konfigurationsdateien, Datendateien, ein Installationsprogramm welches die Installation auf der entsprechenden Zielplatform erleichtert sowie die Dokumentation des Gesamtsystems.

5.3) Versionskontrolle 5.3.1) Versionsidentifikation Um einzelne Versionen voneinander unterscheiden zu können ist eine Versionsidentifikation nötig. Dabei gibt es mehrere Varianten/ Schemata. 1 Lineares Schema Das lineare Schema zur Versionsidentifikation ist sicherlich das bekannteste. Es ordnet bestimmten Versionen eines Systems Versionsnummern zu, die linear ansteigen. So könnte z.b. das erste veröffentlichte Release die Nummer 1.0 haben, eine Nachfolgeversion, in der Fehler behoben worden sind oder neue Funktionalität nachgereicht wird, die Nummer 1.1 usw. Ein nächstes Release in der die Funktionalität entscheidend erweitert bzw. geändert wurde, könnte dann die Nummer 2.0 tragen. Versionsverwaltungstools unterstützen ein solches Schema. Ein solches Schema hat jedoch auch einige Nachteile. So ist es nicht eindeutig wann ein neues Release anstatt einer neuen Version erstellt werden soll. Auch führt es zu Problemen wenn, wie es oft der Fall ist, die Entwicklung eines Systems nicht linear verläuft (vgl. Abblidung 1). So könnte z.b. die Version 1.2 von der Version 1.1 abstammen, genau wie auch Version 1.1a von der wiederum Version 2.0 abgeleitet ist. Version 2.2 jedoch stammt wieder von 1.2 ab, usw. Eine solche 'Vererbungsstruktur' lässt sich mit einem linearen Schema nicht abbilden. Ein weiteres Problem kann auftreten wenn für jeden Kunden spezifische Versionen produziert werden. Das kann natürlich auch nicht mit einem liearen Schema wie oben beschrieben werden. Diese Probleme treten auf weil das Schema eine lineare Ableitung von Versionen impliziert, tatsächlich ist die Ableitungsstruktur jedoch eine Netzwerkstruktur. Abbildung 1 Quelle: http://www.cs.odu.edu/~zeil/cs451/lectures/04mgmt/config/config_ht2x.gif

2 Symbolisches Namensschema Ein symbolisches Schema ordnet Versionen nicht Nummern sondern symbolische Bezeichnungen zu. So könnte zum Beispiel eine Version einer Datenbank die für das Betriebssystem Windows ausgelegt ist, den Namen DB/V1/Win tragen. Das Problem ist, dass ein solches Schema ebenfalls nicht die wahre Ableitungsstruktur repräsentiert. 3 Identifikation durch Attribute Ein Weg um oben genannte Probleme zu beseitigen kann die Identifikation von bestimmten Versionen durch eine Menge von Attributen sein. Mögliche Attribute sind z.b. Kunde, Programmiersprache, Entwicklungsstatus, Hardwareplattform oder Erstellungsdatum. Da jede Version von einer einzigartigen Menge von Attributen identifiziert wird, ist es einfach neue Versionen hinzuzufügen, welche von existierenden Versionen abgeleitet sind. Um solch ein Schema umzusetzen kann man beispielsweise innerhalb der Konfigurationsdatenbank Versionensnummern (die z.b. von einem Versionsverwaltungstool wie CVS oder Subversion generiert werden) mit Mengen von Attributen verknüpfen anhand derer die Version identifiziert werden kann. 5.3.2) Versionsverwaltungstools Methoden der Versionskontrolle kommen sehr häufig zum Einsatz und erfreuen sich großer Beliebtheit. Gründe dafür sind, dass die Versionskontrolle: durch den Einsatz von Tools automatisierbar ist den gleichzeitigen mehrerer Entwickler auf die selben Softwareelemente ermöglicht Änderungen die an Softwareelementen durchgeführt werden protokolliert alte Revisionen wiederherstellbar macht die Lagerung der Entwicklungsdaten an einem zentralen Ort (Repository auf Server) fördert sowie den einfachen Zugriff auf Vorgängerversionen des Systems ermöglicht Insbesondere die automatische Versionsverwaltung durch Versionskontrolltools wird sehr häufig eingesetzt. Solche Tools bieten eine automatische Versionierung/Versionsidentifikation (lineares Schema, s.o.), ein effizientes Speichermanagement (es werden nur Änderungen gegenüber Vorgängerversionen gespeichert) und eine automatische Aufzeichnung der Änderungshistorie. Der wichtigste Vorteil jedoch ist, dass sie das parallele Arbeiten mehrerer Entwickler/Programmierer an den selben Elementen, bzw. das Lösen von dadurch auftretenden Konflikten ermöglicht. Ein typischer Ablauf bei der Arbeit mit solchen Werkzeugen ist in Abbildung 2 dargestellt.

1) 2) 5) 6) 3) 4) 7) 8) Abbildung 2 Quelle: [6] Zwei Entwickler, Harry und Sally, wollen Änderungen an der gleichen Komponente durchführen, welche in Version A vorliegt. Dazu sind folgende Schritte notwendig: 1) Beide Entwickler holen sich die gewünschte Komponente von einem zentralen Ort, dem Repository, in ihren lokalen Arbeitsbereich. Dieser Vorgang wird als Check-out bezeichnet. 2) Beide Entwickler nehmen nun die von ihnen geplanten Änderungen an der Komponente vor. Harry besitzt nun Version A', Sally A''. 3) Sally ist mit ihren Änderungen zuerst fertig und schreibt die von ihr vorgenommenen Änderungen zurück ins Repository. Dieser Vorgang wird als Commit bezeichnet. Im Repository wird eine neue Version (Revision genannt) erstellt, welche identisch mit der in Sally's Arbeitsbereich, A'', ist. 4) Harry ist nun ebenfalls fertig und versucht auch einen Commit durchzuführen. Dieser misslingt jedoch. Aus der Fehlermeldung erfährt Harry, dass er nicht die aktuellste Version (A'') im Arbeitsbereich hat. 5) Daher führt er um an die aktuellste Revision zu gelangen ein Update durch. Er erhält A'' zusammen mit der Meldung, dass sich konkurrierende Änderungen in A' und A'' befinden. 6) Diese muss er nun manuell zusammenführen, was als Mergen bezeichnet wird. Die neu erstellte Version A* enthält sowohl Harry's als auch Sally's Änderungen. 7) Nun kann Harry ein Commit durchführen wobei im Repository eine neue Revision, A*, erstellt wird. 8) Wenn schließlich noch Sally ein Update durchführt und sich somit auch A* in ihren Arbeitsbereich holt, haben beide die Änderungen des jeweils anderen. Neben den bereits erwähnten Begriffen sind weitere bei der Arbeit mit Versionsverwaltungssoftware wichtige Grundbegriffe in Abbildung 3 gezeigt.

Abbildung 3 Quelle: https://eclipse-tutorial.dev.java.net/eclipse-tutorial/part2.html Tags Ein Tag ist ein Textbezeichner, welcher zur Identifikation einer bestimmten Version bzw. Revision verwendet wird. Dieser Bezeichner kann also alternativ zur Revisionsnummer genutzt werden, was die Identifikation bestimmter Versionen erleichtert. In Abblidung 3 ist z.b. Release1-4-0 ein Tag. Branches Als Branch bezeichnet man einen Entwicklungszweig innerhalb eines Repositories. Branches werden erzeugt in dem an einem bestimmten Zeitpunkt (in Abbildung3 z.b. bei Release1-4-0) der Inhalt des Repositories kopiert wird und ein neuer Entwicklungszweig erstellt wird. An jedem dieser Zweige kann nun unabhängig voneinander weiterentwicklelt werden. So kann z.b. ein neues, experimentelles Feature getestet werden, ohne den Hauptzweig zu beeinflussen. Branches können auch wieder zusammengeführt werden, was als Mergen bezeichnet wird. Trunk Als Trunk bezeichnet man den Hauptenwicklungszweig eines Projektes (zentraler Strang in Abblidung 3).

Versionsverwaltungstool - Beispiel: Subversion Das in diesem Semester verwendete Tool Subversion bietet einige Vorteile gegenüber anderen Tools, darunter: Der gesamte Zustand des Repository wird mit einer Revisionsnummer gekennzeichnet (nicht jede Datei einzeln, wie z.b. bei CVS ) Die Änderungshistorie bleibt beim Kopieren des Repositorys erhalten. Commits sind atomar. D.h. wenn mit einem Commit mehrere Änderungen gleichzeitig durchgeführt werden sollen, werden entweder alle Änderungen oder keine übertragen. Das beugt Inkonsistenzen vor. Es gibt ein Apache Plugin für Subclipse Es können sowohl Text (Quellcode), als auch binäre Daten verwaltet werden. Branching und Taggen werden effizient (mit konstantem Aufwand) durchgeführt. 5.4 Releaseverwaltung Die Releaseverwaltung hat gegenüber der Versionsverwaltung einige bedeutende Unterschiede. Da zu einem Release mehr als nur das bloße Programm gehört, ist die Erstellung eines Releases meist teurer als die Erstellung einer neuen Version. Änderungen an einem System werden normalerweise ziemlich regelmäßig vorgeschlagen und vorgenommen. Die Aufgabe des Konfigurationsmanagers ist es nun zu entscheiden, wie oft Komponenten die von solchen Änderungen betroffen sind in neuen Releases veröffentlicht werden. Auch sollten bei der Veröffentlichung von Releases einige weitere Zusammenhänge in Betracht gezogen werden. Änderungen an Komponenten führen fast immer zu Fehlern. Diese müssen dann in einem späteren Release korrigiert werden. Nun stellt sich die Frage, wann man ein Release in dem die Funktionalität erweitert wird und wann man ein Release zur Fehlerkontrolle veröffentlichen sollte. Ein Mischen dieser beiden Möglichkeiten ist in der Regel ungünstig, da sich ein Fehlerreport immer auf eine bestimmte Version bezieht, und wenn dich diese durch Einführen neuer Funktionalität geändert hat, ist nicht eindeutig wie sich das auf den Fehler auswirkt. Es bietet sich daher an, Releases zur Fehlerkontrolle und Releases mit neuer Funktionalität abzuwechseln. Auch muss ein Release nicht immer vom Kunden gewünscht sein. Daraus ergibt sich ein weiteres Problem bei der Veröffentlichung von Releases das in Betracht gezogen werden muss. Ein neues Release sollte nicht auf die Existenz vergangener Releases angewiesen sein, da der Kunde nicht automatisch eine neue Version direkt nach Veröffentlichung installiert, sondern nur wenn er darin einen Nutzen für sich sieht.

6) System Building 6.1 Einleitung Unter System Building versteht man das Kompilieren und Verlinken von Softwarekomponenten zu einem Programm, welches auf einer bestimmten Zielplattform ausführbar ist. Dieser Vorgang ist automatisierbar, was zu einer Vielzahl an vorhandenen Werkzeugen führte, die dem Entwickler mehr oder weniger Arbeit abnehmen. Das System-Building ist gerade bei größeren Projekten ein teurer, da zeitaufwändiger, Prozess. Das resultiert aus der Tatsache, dass oft mehrere hundert Softwareelemente (Dateien) involviert sind. Typische Fragen mit denen man sich beim System-Building beschäftigt sind u.a.: Sind alle Komponenten in den Build- Anweisungen enthalten? Wird die richtige Version aller Komponenten in den Anweisungen verwendet? Sind alle Datendateien vorhanden? Bleiben bei der Kompilierung für ein anderes System, die Namen auf dem Zielsystem die gleichen? Sind die richtigen Versionen von Compiler und verwendenden Tools vorhanden? 6.2) System Building Tools Um diesen rechenaufwändigen Prozess zu unterstützten und vereinfachen wurden zahlreiche Tools entwickelt. Der 'Klassiker' unter diesen Tools ist zumindest für Unix Systeme, MAKE (1979). Es überwacht die Abhängigkeit zwischen Sourcecode und Objektcode und re-kompiliert automatisch die Sourcen welche nach dem Erstellungsdatum des zugehörigen Objektcodes verändert wurden. Die Abhängigkeiten zwischen den Dateien in denen die Systemkomponenten enthalten sind werden in sog. 'Makefiles' angegeben. Maven ([8]) Im diesjährigen Projekt wird von uns u.a. Maven verwendet. Neben klassischem Build-Management, wie es auch von Tools wie MAKE geboten wird, bietet Maven auch: Spezifikation, Ausführung, und Report von Unit-Tests als Teil des normalen Build-Zyklus Abstraktion von den Details des Build-Prozesses Vereinfachte Verwaltung von Multi-Projekten durch ein einheitliches Build- System Projektinformationen Maven wird konfiguriert durch sog. POM- Dateien (Project Object Model).

6.3 Continuous Build Eine wichtige Frage im Zusammenhang mit Build-Management ist, wie oft ein Build durchgeführt werden soll. Dies muss für jedes Softwareprojekt individuell entschieden werden. Auf der einen Seite, wird der 'Build' immer komplizierter je seltener er durchgeführt wird, da mit der Zeit die Entwicklung einzelner Komponenten auseinander laufen kann und da mehr Fehler beseitigt werden müssen. Auf der anderen Seite ist wie schon erwähnt ein Build sehr aufwändig, speziell bei großen Projekten. Je öfter dieser durchgeführt wird je mehr Ressourcen konsumiert das Build-Management. Die optimale Strategie muss hierbei für jedes Softwareprojekt einzeln gefunden werden. Ein Extrem ist es, nach jeder Änderung einen Build durchzuführen. Dieses Verfahren wird als Continuous Integration bezeichnet. Dabei kann durch Tools (wie z.b. Cruise Control, s.u.) die Überwachung der Sourcen und der Aufruf des Build-Tools automatisiert werden aber auch nach dem erfolgten Build automatisch getestet werden. Cruise Control ( [7]) Das von uns verwendete Cruise Control ist ein System das den Continuous Build Prozess unterstützt. Es beinhaltet u.a. Plugins zur Email- Benachrichtigung von Benutzern, für Ant und verschiedene andere Source-Kontrolltools. Cruise Control besteht aus drei Hauptmodulen, dem Build Loop, dem Legacy Reporting und dem Dashboard. Der Build Loop ist der Kern des Systems. Er löst Build-Zyklen aus und benachrichtigt dann Benutzer mittels verschiedener Techniken. Der Auslöser kann intern (geplant oder bei Änderungen der Quelldateien) oder extern sein. Er wird konfiguriert durch eine XML-Datei und produziert abhängig von der Konfigurarition Artefakte. Das Legacy Reporting erlaubt den Benutzern die Ergebnisse der Builds durchzusehen und bietet Zugriff auf die Artefakte. Das Dashboard gibt eine visuelle Repräsentation des Status aller Projekt-Builds.

7) Quellenangabe [1] I. Sommerville Software Engineering, 8th Ed. [2] Dorfman, A. Ackerman Software Engineering [3] Bersoff, Henderson, Siegel, Software Configuration Management, ACM SIGMETRICS Performance Evaluation Review, Volume 7 [4] http://www.ipd.uni-karlsruhe.de/~tichy/scm/ [5] http://en.wikipedia.org/wiki/software_configuration_management/mee [6] http://svnbook.red-bean.com/ [7] http://cruisecontrol.sourceforge.net/index.html [8] http://maven.apache.org/