Ivan Bogicevic 1 Prüfer: Prof. Dr. Frank Leymann Betreuer: Tammo van Lessen, Stephanie Mauchart

Transkript

1 Seminar: Implementierungswerkzeuge von Workflow Systemen im Rahmen des StuPro SWoM2 Wartung und Entwicklung existierender Software: Entwicklungsmanagement mit Fokus auf Versionsmanagement mit Subversion Ivan Bogicevic 1 Prüfer: Prof. Dr. Frank Leymann Betreuer: Tammo van Lessen, Stephanie Mauchart Institut für Architektur von Anwendungssystemen Universität Stuttgart 1 bogicein@studi.informatik.uni-stuttgart.de Zusammenfassung. In dieser Ausarbeitung des Seminars von SWoM2, dem Studienprojekt zur Erweiterung und Verbesserung der Stuttgarter Workflow Maschine SWoM, wird auf Problematiken und Lösungsmöglichkeiten bei der Entwicklung von bestehenden Systemen eingegangen. Im Mittelpunkt dabei stehen das Versionsmanagementsystem Subversion, seine grundlegenden Konzepte, sowie damit verbundene Techniken wie Branching und Merging. Insbesondere findet eine Erörterung der möglichen Branching-Szenarios für SWoM2 statt. Kurz vorgestellt werden die Tools Subclipse und Trac, welche bei SWoM2 sehr wahrscheinlich zum Einsatz kommen. 1 Entwicklungsmanagement Beim Entwicklungsmanagement geht es unter anderem um die Planung, Organisation und Durchführung der einzelnen Entwicklungsschritte. Im Zusammenhang dazu steht die zentrale Rolle des Librarian, der für das Configuration Management (CM) zuständig ist. 1.1 Grüne-Wiese -Entwicklung Bei der Entwicklung auf einer grünen Wiese entwickelt man neue Software ohne Altlasten. Struktur- und Architekturentscheidungen können frei getroffen werden. Entwickler verstehen das System viel leichter, da sie es von Grund auf neu entwickeln müssen. Code, den man verstehen muss, hat man selbst geschrieben oder mitgeschrieben. Zu Beginn des Projektes gibt es gibt keine Fehler aus bestehender Software, da es noch keine Software gibt. Es gibt also relativ wenig Abhängigkeiten und Störfaktoren, deshalb das Symbol der grünen Wiese (Abb.1).

2 Abb. 1. Grüne-Wiese -Entwicklung Abb. 2. Entwicklung existierender Software

3 1.2 Entwicklung existierender Software Im Gegensatz dazu steht die Entwicklung existierender Software. Dabei handelt es sich um ein System, hier z.b. SWoM, welches durch ein Folgeprojekt verbessert oder verändert, also weiterentwickelt werden soll. Das Folgeprojekt wird meistens nicht von den selben Personen durchgeführt, wie das ursprüngliche Projekt. So wird es auch bei SWoM2 der Fall sein. Die Konsequenzen für das Folgeteam bestehen darin, dass sie zunächst einmal das bestehende System verstehen müssen. Dies ist im Normalfall nicht von vorherein gegeben. Der existierende Code, die Dokumentation, die Qualität, bestehende Strukturen und Architekturen sind unbekannt. Hinzu kommt, dass es sowohl am bestehenden System SWoM, sowie am neuen System SWoM2 auch schon während der Entwicklung Benutzer (z.b. Diplomanden) geben wird, die ihrerseits Änderungswünsche haben. Da SWoM2 auf SWoM aufsetzt, ist es vollständig abhängig davon. Ein bisher unbemerkt gebliebener Fehler in SWoM kann unerwaretete Konsequenzen für SWoM2 haben. Auf den Punkt gebracht: Es gibt eine ständige Störung von außerhalb (Abb. 2). Lösungsvorschläge, die dieser Problematik entgegenwirken, sind: eine umfangreiche Analyse des Ist-Zustandes in Form von z.b. Code- Inspektionen, Dokumentations-Inspektionen und Architektur-Analysen, um das bestehende System besser kennenzulernen. Aufgrund der Abhängigkeiten bieten sich sehr kleine Integrationszyklen an, es könnte sinnvoll sein, sehr oft, z.b. einmal im Monat, zu integrieren. Ein ständiger Regressionstest, der sicherstellt, dass alle bisherigen Funktionen immer noch funktionieren ist sicher auch sinnvoll. Schließlich kann die Störung auch als Hilfe angesehen werden. Denn was schon besteht, muss nicht neu geschrieben werden. Ein gutes SWoM erleichtert viel bei der Weiterentwicklung und bildet eine solide Basis zu SWoM Wartung Bei SWoM wird es eine dauernde Wartung während der Entwicklung geben (Abb. 3). Da sowohl SWoM1, als auch Teile von SWoM2 während der Entwicklung von SWoM2 eingesetzt werden, wird es Änderungswünsche von außen geben. Zugleich werden Fehler sowohl bei den alten Funktionen, wie auch bei den neuen Funktionen auftreten. Die dazu nötigen Fixes müssen aufgrund der vielen Abhängigkeiten zueinander und zu den alten und neuen Funktionen besonders gut sein. Das betrifft natürlich insbesondere die behobenen Fehler von SWoM1. Aber auch in Hinblick auf eine mögliche Erweiterung von SWoM2 (SWoM3) ist die hohe Qualität der Fixe wichtig. Mögliche Techniken bzw. Regeln hierzu sind z.b.: vom Entwickler verlangen, zu jedem Fix einen Testcase mitzuliefern zusätzliche separate Dokumentation für Fixe verlangen mehrere Entwickler suchen parallel nach Lösungen für ein Problem, die Lösungsvorschläge werden dann diskutiert und verglichen z.b. bei Trac mit einem commit-hook eine Referenz zu einem Bug-Ticket ertellen; ein hook ist ein Programm (z.b. bei Trac in Phyton), welches durch ein Ereignis im Subversion-Repository ausgelöt wird, wie z.b. ein commit

4 Abb. 3. Wartung bei SWoM 1.3 Rolle des Librarian Der Librarian ist der Bibliothekar bei der Entwicklung. Er ist für das Configuration Management (CM) zuständig. Er koordiniert die Releases, das Bug Fixing, die Testskripte. Er muss wissen, wer was wann an welcher Datei ändern darf. Er behält den Überblick über den Code, über die interne und externe Dokumentation, auch wenn Benutzer A und B gleichzeitig an der selben Datei arbeiten. Seine zentrale Aufgabe ist die Arbeitsvorbereitung, also z.b. Werkzeuge bereitzustellen, die unter anderem genau das unterstützen (z.b. Subversion svn). Der Librarian bildet das Interface zu allen Teilnehmern des Projektes. Dabei müssen auch so banale Dinge wie Erreichbarkeit berücksichtigt werden. Vor allem bei SWoM2, wo nicht immer alle Entwickler gemeinsam in einem Büro sitzen werden, ist es notwendig, das die Arbeit nicht stillsteht, nur weil der Librarian seit einigen Tagen nicht mehr in sein Postfach schaut. Seine Arbeit ist meist unbemerkt. An ihn muss eine Meldung gehen, wenn ein Entwickler eine Teilaufgabe für erledigt hält. Auf den Punkt gebracht: Der Librarian sorgt für Infrastruktur. Der Librarian ist die Spinne, die mitten im Netz sitzt (Abb. 4). Abb. 4. Der Librarian ist die Spinne, die mitten im Netz sitzt.

5 2 Subversion (svn) Subversion ist ein relativ neues Programm zur Konfigurationsverwaltung. Version 1.0 ist von 2004, die derzeit aktuellste Version ist Subversion soll das 2 Jahrzehnte alte CVS ersetzen, deshalb ähneln sich die zwei Programme in vielen Punkten. Besonders bei den Kommandozeilenparametern ist vieles ähnlich. Subversion bietet jedoch mehr Funktionen, es heißt, svn sei besser und effektiver. Subversion ist als time machine bekannt, denn ein grundlegendes Konzept ist es, keine Informationen zu verlieren. Alles, was jemals Subversion anvertraut wurde, ist wiederherstellbar. Subversion ist open source. Die Bedienung kann per Kommandozeile erfolgen, es gibt aber auch grafische Oberflächen wie SmartSVN (klassische Darstellung mit Verzeichnisbaum) oder TortoiseSVN (Integration im Windows-Explorer) oder, was wahrscheinlich bei SWoM2 eingesetzt wird, Subclipse als Plugin für Eclipse. Weitere Informationen unter: Warum überhaupt Subversion Es stellt sich die Frage, weshalb überhaupt ein solches Programm nötig ist. Zwei Hauptgründe springen ins Auge: Zum Einen ist es beinahe unmöglich, in einem größerem Projekt den Überblick über alle Dateien in ihren verschiedenen Versionen und Konfigurationen zu behalten. Selbst mit einem Versionsverwaltungs-Tool ist es schwierig genug. Zum Zweiten kann der klassische Mehrbenutzer-Konflikt auftreten (Abb. 5). Abb. 5. klassischer Mehrbenutzer-Konflikt Hierbei kopieren sich A und B die gleiche Datei von einer zentralen Stelle. Sowohl A als auch B verändern diese Datei. B schreibt seine veränderte Datei wieder zurück. Etwas später macht A das Gleiche und überschreibt somit die geänderte Datei von B. Es gibt folgende zwei Lösungen für dieses Problem: Lock-Modify-Unlock Solution Hierbei wird die Datei an der zentralen Stelle gesperrt, sofern jemand Änderungen an ihr durchführen möchte. Also z.b. A und B lesen die Datei,

6 A sperrt die Datei und verändert sie, B möchte die Datei sperren, kann aber nicht (da bereits gesperrt), A schreibt die Datei und löst die Sperre, jetzt kann B lesen und sperren. Hier könnte z.b. der Librarian Rechte verteilen, wer wann welche Datei verändern darf. Lock-Modify-Unlock funktioniert zwar auch mit Subversion, ist aber nicht üblich. Es ein ein erheblicher Nachteil, dass nur einer gleichzeitig eine Datei verändern kann. Copy-Modify-Merge Solution Diese Methode ist in Subversion implementiert und wird auch häufig in der Praxis verwendet. Die Lösung: A liest die Datei, B liest die Datei, B schreibt seine veränderte Datei, A versucht seine veränderte Datei zu schreiben, bekommt aber einen out of Date -Error. Daraufhin liest A die Datei von der zentralen Stelle, vergleicht diese (evtl. automatisch) mit seiner eigenen und versucht diese beiden Dateien zusammenzufügen (zu mergen). Danach schreibt A die kombinierte Datei. Der Nachteil liegt darin, dass das Mergen nicht funktionert, wenn z.b. die Änderungen überlappen, oder die Dateien prinzipiell nicht mergeable sind. Auch bei dieser Lösung sollte koordiniert werden, wer wann welche Datei verändern soll und darf. Mehr dazu im Abschnitt über Merging und Branching. 2.2 Subversion Konzept Für ein einzelnes Projekt sieht der prinzipielle Aufbau eines Subversion-Systems folgendermaßen aus (Abb. 6): An einer zentralen Stelle gibt es den Subversion-Server, auf dem ein Repository (rep) liegt. Dies ist ein kompletter versionierter Verzeichnisbaum. Von außerhalb können die Subversion-Clients mithilfe der svn-befehle schreibend oder lesend auf das Repository zugreifen. Jeder Client hat eine lokale Arbeitskopie, die working copy (wc), auch wieder ein kompletter Verzeichnisbaum. Abb. 6. Subversion Konzept 2.3 Subversion Befehle

7 Es folgen die wichtigsten Subversion Kommandozeilenbefehle und -parameter. Help. Allgemeine Hilfe oder Hilfe zu einem speziellen svn-kommando: $ svn help $ svn help <subcommand> Checkout. Kopiert (kompletten) Baum vom rep zur wc: $ svn checkout A SWoM/MyFirstFile.java A SWoM/AnotherFile.java Checked out revision 34. Kurzform: $ svn co rep wc Commit. Überträgt eine (geänderte) Datei der wc an das rep: $ svn commit -m "MyMessage" BPEL_Parser.java Sending BPEL_Parser.java Transmitting file data. Committed revision 35. rep Kurzform: $ svn ci wc Revision. Eine Revision ist fortlaufende Versionnummer ab 0, die automatisch bei jedem commit um 1 erhöht wird und dabei angezeigt wird. Sie bezieht sich auf einen ganzen Baum. Dieser Parameter kann mit fast allen anderen Befehlen kombiniert werden, wenn sich der Befehl nur auf spezielle Revisionen beziehen soll: svn --revision 35 [..] (bezieht sich auf eine Revision) svn -r 35 [..] (Kurzform) svn -r 35:38 [..] (Bereich von Revisionen) svn -r HEAD [..] (neueste Version) svn -r PREV [..] (direkter Vorgänger davon) svn -r {" :30"} [..] (Selektion mittels Zeit) Update. Aktualisiert die wc anhand der Dateien im rep: $ svn update U MyFirstFile.java rep wc Updated to revision 35. Der angezeigte Buchstabe in jeder Zeile bedeutet: Was ist mit der Datei in der wc passiert (beim Updaten mit dem rep)? U updated (Repository hatte neuere Version, jemand hat die Datei verändert) A added (jemand hat die Datei hinzugefügt) D deleted (jemand hat die Datei gelöscht) R replaced (jemand hat die Datei ersetzt) G merged (jemand veränderte die Datei, Dateien konnten gemergt werden) C conflict (jemand veränderte die Datei, Dateien konnten nicht gemergt werden) Kurzform: $ svn up Modify. Verzeichnisstruktur im Repository verändern: rep

8 $ svn add... (Datei hinzufügen) $ svn delete... (Datei löschen) $ svn copy... (Datei kopieren) $ svn move... (Datei verschieben) Intern werden beim Kopieren nicht alle Daten kopiert, der Speicherverbrauch also nicht verdoppelt. Dies wird durch Ausgeklügelte Differenz-Algorithmen ermöglicht. Info. Informationen über ein Item (Verzeichnis oder Datei) ausgeben: $ svn info... Status. Ausführlichen Status der Dateien im wc anzeigen: rep $ svn status M + SWoM.java wc O trunk/bpel_parser.java Bei diesem wichtigen Befehl werden alle Dateien im aktuellen Verzeichnis (mit Subdirectories) aufgelistet. Bei Bedarf können auch einzelne Dateinamen als zusätzliche Parameter angegeben werden, um die angezeigte Liste zu verkürzen. In 5 Spalten werden über jede Datei ausführliche Informationen über Status, Properties, Locked-Zustand,... angezeigt. Die genaue Erklärung hierzu umfaßt im Subversion Manual 3 DINA4 Seiten. Details auch siehe: $ svn help status Diff. Änderungen von Dateien im udf-format anzeigen (Unified Diff Format): Vergleich zwischen wc und Revision seit letztem Update: $ svn diff Vergleich wc mit angegebener Revision: $ svn diff -r 34 SWoM.java Vergleich der angegebenen Revisionen: $ svn diff -r 32:34 SWoM.java ein Redirecten der Ausgabe in eine Datei ist möglich: $ svn diff > file Beispiel für udf nach svn diff (Auszug aus svn-book): $ svn diff -r 343:344 Index: integer.c =========================================== --- integer.c (revision 343) +++ integer.c (revision -147,7 case 6: sprintf(inf->os, "HPFS"); break; case 7: sprintf(inf->os, "Macintosh"); break; case 8: sprintf(inf->os, "Z-System"); break; - case 9: sprintf(inf->os, "NTES"); break; + case 9: sprintf(inf->os, "NTFS"); break; case 10: sprintf(inf->os, "TOPS-20"); break; Hier ist im udf-format schön zu erkennen, dass 'NTES' durch 'NTFS' ersetzt wurde. Cat. Anzeige einer älteren Revision:

9 $ svn cat -r 34 SWoM.java $ svn cat -r 34 SWoM.java > SWoM.java.v2 List. Anzeige Repository ohne Download: $ svn list Revert. Uncommittete Änderungen der working copy verwerfen: $ svn revert Dieser Befehl benötigt, ebenso wie auch svn diff und svn status, keinen Zugriff auf das Repository. Dies ist nur möglich, weil Subversion beim update Zusatzinformationen in die wc schreibt, und zwar in Form eines.svn-verzeichnisses. Dieses wird darf keinesfalls verändert oder gelöscht werden, es hat lediglich administrative Bedeutung. rep wc Log. Anzeige, wer was wann verändert hat: $ svn log r3 don Mon, 22 May :03:54 1 line Added parsebpel()-method r2 john Mon, 22 May :17:87 1 line Added main()-method r1 don Mon, 22 May :10:43 1 line Initial import nur spezielle Revisions: $ svn log -r 34:30 nur spezielle Dateien: $ svn log SWoM.java Allgemeines. Es sollte noch beachtet werden, dass jeder Zugriff auf das Repository automatisch mitprotokolliert wird. Desweiteren ist zu empfehlen, unmittelbar vor jedem commit immer ein update auszuführen. Beim committen selbst darf eine Message über vollzogene Änderungen (mit -m) nicht fehlen. Allgemein sollte nicht zu viel geändert werden bis zum nächsten commit, denn ansonsten könnte das mergen Probleme bereiten. Anders ausgedrückt, es sollte öfters committet werden, jedoch immer so, dass das Repositoy konstistent und compilierbar bleibt. Falls das nicht möglich sein sollte, muss ein Branch eingebaut werden.

10 2.4 Branching und Merging Konzept. Branching und Merging sind fundamentale Techniken beim Version Management. Wichtig zum Verständnis ist der Unterschied zwischen Version und Variante. Eine Version eines Programms erstetzt eine andere. Die alte Version wird im Normallfall nicht mehr verwendet. Dagegen existieren Varianten von Programmen zeitlich nebeneinander. Eine Version entspricht bei Subversion einer Revision. Jedesmal, wenn comitted wird, wird eine neue Version (Revision) erzeugt. Das Erzeugen von Varianten geschieht dagegen durch abzweigen, also branchen (Abb. 6). Abb. 6. Subversion Konzept Gründe für Varianten, also für das Erzeugen von "Zweigen", die zeitlich nebeneinander her laufen, gibt es mehrere. Einer davon wären unterschiedliche Kunden, die auf sie zugeschnittene Varianten wünschen. Dies wird bei SWoM2 wahrscheinlich nicht der Fall sein. Der zweite, weit häufigere Grund ist der, dass ein Unter-Team (oder auch ein einzelner Entwickler) Änderungen vornehmen möchte, welche sich mit Änderungen anderer Entwickler gegenseitig stören. Die Lösung in diesem Fall ist der private branch, also eine private Abzweigung einer Entwicklungslinie. In Subversion heißt die Hauptentwicklungslinie trunk (Stamm). Während der Änderungen im branch können andere Entwickler weiterhin problemlos in den trunk committen. Sind einige oder alle Änderungen im branch abgeschlossen, kann dieser wieder mit dem trunk zusammengeführt (gemergt) werden, oder aber er bleibt als Variante bestehen. Folgendes Repository-Layout ist Standard: /trunk (enthält die Hauptrevision) /branches (Zweige, z.b. private Branches) /tags (Konfigurationen) /releases In Subversion wird ein Branch durch das Kopieren eines Ordners realisiert. Möchte man Konfigurationen (Sätze von Dateien in bestimmten Versionen) speichern, so wird genauso verfahren. Sogar beim Herausgeben von Releases, wird einfach der trunk z.b. in den /releases/1.0/-ordner kopiert. Subversion unterscheidet nicht zwischen Branches, Tags, Releases und kopiertem Directory! In SWoM2 werden Branches wahrscheinlich deshalb nötig werden, weil es mehrere Unter-Teams gibt. Beispielsweise könnten die Änderungen des Performance-Teams zu den Änderungen des Funktionserweiterungs-Teams in Konflikt stehen. Aber selbst wenn sie das nicht tun, kann eine Trennung der Entwicklungslinien sinnvoll sein, da dann z.b. Fehler leichter lokalisiert werden können.

11 Branchen mit svn copy. Um einen Branch, einen Tag oder eine Revision zu erstellen, wird einfach der entsprechene Ordner kopiert, wobei einmal erstellte Release-Kopien natürlich nicht mehr verändert werden sollten: $ svn copy -m "Creating a private branch of /SWoM/trunk." Committed revision 35. Beim Branchen ist es wichtig, sich die Revisions-Nummer zu merken bzw. zu dokumentieren, da man diese später beim mergen angeben muss. Branchen mit svn switch. Eine elegante Alternative zum Branchen mit copy ist das Branchen mit switch. Hierbei wird einfach zwischen Zweigen "umgeschalten". Auf den Punkt gebracht entspricht switch fast genau der direkten Kombination aus den Befehlen svn copy und svn checkout. In beiden Fällen kann man sich auf einzelne Unterverzeichnisse, wie auch auf einzelne Dateien beziehen. $ svn switch U SWoM.java Updated to revision 35. Kurzform: $ svn sw Konflikte beim Mergen. In genau zwei Fällen kann beim Mergen ein Konflikt auftreten: Entweder überlappen die Änderungen, also wenn zwei Entwickler an der selben Stelle einer Datei verschiedene Änderungen vorgenommen haben, oder die Dateien sind grundsätzlich nicht mergeable, z.b. Binaries oder Windows-Executable. Tritt ein Konflikt auf, so wird dies bei svn status mit dem Buchstaben c angezeigt. In diesem Fall erfolgt eine automatische Erzeugung der Konflikt auslösenden Dateien mit den entsprechenden Endungen, welche in die working copy gespeichert werden. Beispielsweise SWoM.java (welche sogenannte conflict marker >>>>>>>.r3 im Text enthält), SWoM.mine (der eigenen Datei), SWoM.r3 (Datei der Revision 3), SWoM.r7 (Datei der Revision 7). Jetzt kann man den Konflikt manuell lösen, also die gewünschten Änderungen vornehmen. Wichtig dabei ist, Kontakt zum anderen Entwickler zu halten, um Überschreibungen und Missverständnisse zu vermeiden. Die veränderte Datei kann (und muss sogar) eingecheckt werden. Jetzt muss noch der Konflikt explizit als aufgelöst markiert werden. Dies geschieht mit: $ svn resolved SWoM.java Resolved conflicted state of 'SWoM.java' Mergen mit svn merge. Das explizite Mergen zweier Pfade im Repository mit anschließendem Schreiben der Differenzen in eine working copy funktiert mit svn merge. Der Befehl ähnelt sehr dem Befehl svn diff. Mit der folgenden Schreibweise kann man einfach spezielle Revisionen (hier 35 und 46) von Pfaden bzw. Dateien selektieren: $ svn merge U SWoM_1.java U SWoM_2.java

12 $ svn status M SWoM_1.java (Dateien konnten automatisch gemergt werden) C SWoM_2.java (Manuell zu lösender Konflikt. Diesmal Dateien mit anderen Endungen: SWoM_2.left, SWoM_2.right, SWoM_2.mine) Achtung! Jetzt ist noch ein commit nötig, denn an dieser Stelle existiert die Änderung nur als lokale Modifikation in der working copy. Also: svn commit -m "added my_branch r34:42 to trunk" 2.5 Branching und Merging bei SWoM2 Die Aufgabenstellung für SWoM2 (Abb. 7) läßt sich recht deutlich in drei relativ unabhängige Bereiche einteilen. Zum Einen sind neue Funktionen zu implementieren, wie z.b. BPEL 2.0. Zum Zweiten soll parallel dazu die Gesamtperformance verbessert werden, was sich sowohl auf den neuen wie auch auf den alten Teil von SWoM bezieht. Der dritte Aspekt soll Verbesserungen bei der Administration, beim Monitoring, bei der Sicherheit und bei der Installation bringen. Bei dieser relativ deutlichen Trennung bietet es sich wahrscheinlich an, drei Unterteams zu bilden, von denen jedes einen Teil übernimmt. Zusätzlich kommen noch die Wartungsaufgaben für SWoM1 hinzu. Bei dieser Fülle von verschiedensten Änderungen am selben System gilt es, eine Branching-Struktur zu finden, bei der sich möglichst wenig gegenseitig blockiert. Einige der Änderungen bzw. Ergänzungen werden sich eher auf das bestehende System beziehen, also z.b. bestehende Dateien werden ergänzt. Dagegen wird es wahrscheinlich auch Änderungen geben, bei denen nicht so tief ins bestehende System eingegriffen werden muss, z.b. bei der Verbesserung der Installation. Abb. 7. Aufgabenstellung für SWoM2

13 Mögliche Branch-Struktur für SWoM. Es folgt ein Vorschlag für eine mögliche Branch-Struktur für SWoM (Abb. 8), welcher auf die eben erläuterten Problematiken eingeht und versucht diese zu vermeiden. Dies ist nur ein Vorschlag, eine endgültige vollständige Entscheidung kann sinnvollerweise erst nach den ersten Phasen des SWoM2-Projektes erfolgen, also nach der Architekturanalyse, der Codeinspektion und der Einarbeitung in die bestehende Dokumentation. Abb. 8. Mögliche Branch-Struktur für SWoM Der obere horizontale große Pfeil stellt die Entwicklungslinie von SWoM1 dar. Zu Beginn des SWoM2-Projektes, wird SWoM1 komplett kopiert. Das bedeutet, ein Branch entsteht, nämlich der SWoM2-Branch (in welchem SWoM1 enthalten ist). Ab hier laufen beide "Streams" nebeneinander her (zeitlich parallel). Dies ist notwendig, da sowohl auf SWoM1, als auch auf SWoM2 Diplomarbeiten laufen bzw. laufen werden. Wartungsarbeiten an SWoM1, wie etwa Bug Fixing, können über einen kurzlebigen private branch getätigt werden, der relativ bald wieder mit dem Hauptstream von SWoM1 gemergt wird. Parallel dazu kann SWoM2 entwickelt werden (Ellipsen in Abb. 8). Sind sowohl ein Block von Aufgaben für SWoM2, als auch ein Block von Wartungsarbeiten von SWoM1 erledigt, dann muss der SWoM1- Zweig mit in den SWoM2-Zweig gemergt werden. Dies ist aus mehreren Gründen sehr wichtig und notwendig. Ein Grund dafür ist das Auseinanderdriften der Zweige, welches ohne eine ständige Synchronisation unweigerlich auftreten würde. Die Folge wäre, das ein Mergen immer schwerer oder gar unmöglich wird. Ein weitere wichtiger Grund für das Mergen zum unteren Stream ist, das über diesen Weg die Fixes von SWoM1 auch in SWoM2 ihre Anwendung finden. Sind die Linien gemergt, dann beginnt der Zyklus von neuem. SWoM1 kann weiter gefixt werden, während SWoM2 (z.b. von den drei Unter-Teams) weiterentwickelt wird. Auf beiden Streams muss ständig ein Regressionstest laufen, der sicherstellt, dass alle bisherigen Funktionen weiterhin einwandfrei laufen. Dieser Zyklus wiederholt sich bis zur Fertigstellung von SWoM2. Nach einem finalen Merge von SWoM1 in den SWoM2 Stream kann dann der SWoM1 Stream aufgegeben werden. Ab diesem Zeitpunkt gibt es dann wieder nur noch eine Entwicklungslinie, in der z.b. auch die Wartung des neuen Systems stattfinden kann.

14 Im Folgenden werden Lösungsvorschläge für eine Branching-Struktur für den SWoM2-Stream vorgestellt (blaue Ellipsen in Abb. 8). Hierbei wird davon ausgegangen, dass es, wie oben beschrieben, drei Unter-Teams aus jeweils mehreren Entwicklern, welche für das selbe Projekt, jedoch in teilweise unterschiedlichen Bereichen, arbeiten. Lösung 1: Release Branches (Abb. 9): Alle Entwickler committen immer in den trunk. Der Librarian stellt regelmäßig Releases bereit. Diese Lösung bewirkt eine gewisse Unordnung. Fehler sind schwerer zu finden. Überschneidungen sind unkontrollierter und chaotischer. Kommt für SWoM2 kaum in Frage. Abb. 9. Lösung 1 - Release Branches Lösung 2 und 3: Feature Branches (Abb. 10): Jedes der Unter-Teams hat einen extra branch, in welchem nur Mitglieder desselben Unter-Teams Änderungen einfügen dürfen. In regelmäßigen Abständen werden die branches gemergt und vom Librarian als Releases bereitgestellt. Es müssen nicht immer alle branches gleichzeitig gemergt werden, es kann z.b. sinnvoll sein, dass das Performance-Team einen Merge ausläßt und erst beim übernächsten Merge seine Änderungen einbringt (Abb. 11). Abb. 10. Lösung 2 - Feature Branches Abb. 11. Lösung 3 - kontrollierte Kombination

15 3 Spezielle Tools Folgende Tools werden sehr wahrscheinlich bei SWoM2 zum Einsatz kommen. 3.1 Trac Trac ist ein separates web-basiertes Software Managing Tool. Trac kann und wird als Bugtracker verwendet. Es unterstützt auch das Verwalten der Dokumentation und bildet ein Netzwerk von Links zwischen Bugs, Issues, Tasks. Zu Subversion besteht ein sehr gutes Interface. Das Tool ist relativ einfach zu bedienen. Bug reports, project tasks und feature requests werden in Form von Tickets dokumentiert, das sind Einträge ähnlich die in einem Web-Forum, denen man auch Zusatzattribute wie "erledigt" oder "wichtig" geben kann. 3.2 Subclipse Subclipse ist ein Plugin für die Eclipse IDE. Es bietet eine grafische Bedien- Oberfläche für Subversion. Viele weitere Funktionen, die den Entwickler und vor allem den Lbrarian unterstützen sind implementiert. Beispielsweise kann man mit Subclipe sehr schön Konflikte auflösen oder durch das Repository browsen. Quellen Ideen auch aus: