Wer Software im Team entwickelt, muss nicht nur den Quellcode verwalten, sondern auch gewährleisten, dass alle Mitarbeiter die Abläufe einhalten. Aegis übernimmt diese Aufgabe: Es verlangt Reviews für alle Änderungen am Code und stellt sicher, dass die Entwickler für neue Features Tests schreiben.

Große Softwareprojekte stoßen schnell an die Grenzen herkömmlicher Versionskontrollsysteme. Diese verwalten zwar den Quellcode und geben mehreren Entwicklern synchronen Zugriff, auch sind alle Änderungen nachvollziehbar. Die Pakete sorgen aber nicht dafür, dass die Entwickler feste Abläufe einhalten. Will der Projektleiter sicherstellen, dass immer ein zweiter Entwickler jede Veränderung im Code begutachtet und dass für neue Features auch Tests vorhanden sind, ist er auf Unterstützung angewiesen – entweder durch alle Entwickler, oder durch ein Paket wie Aegis.

Der Projektleiter könnte die Abläufe informell festlegen. Zum Beispiel senden sich die Linux-Kernel-Entwickler ihre Patches gegenseitig per E-Mail zu und integrieren sie in ihren Kernel. Das führt fast zwangsläufig zu Reviews, da jeder Programmierer nur Code in den eigenen Kernel aufnimmt, der einwandfrei aussieht. Auch BSD-Entwickler dürfen nicht beliebig im CVS committen, sondern nur nach Absprache mit anderen.

Ein informelles System ist auf den guten Willen und die Disziplin aller Beteiligten angewiesen. Gerade bei einfachen Änderungen ist die Versuchung groß, den Review-Schritt zu überspringen. Hier hilft ein Revisionskontrollsystem, das auch Reviews und Tests durchsetzt.

Änderungs-Aufsicht

Das SCM-System (Software Configuration Management) Aegis erfüllt genau diese Forderung. Peter Miller nennt sein Programm “A Project Change Supervisor”: Aegis überwacht die Veränderungen in einem Projekt. Meist handelt es sich um Software-Entwicklung, das System eignet sich aber für alle dateibasierten Projekte, etwa Webseiten.

Bedienen lässt sich diese SCM-Software durch Kommandozeilenbefehle. Da Aegis viele Aufgaben zu bewältigen hat, kennt es mehr Kommandos als CVS. Allerdings muss nicht jeder Entwickler alle Befehle kennt. Aegis unterscheidet verschiedene Rollen für seine Anwender, nur die Administratoren benötigen ins Einzelne gehende Kenntnisse.

Die Änderungen, die ein Programmierer an einem Aegis-Projekt vornimmt, muss er in Changes unterteilen. Ein Change kann Dateien hinzufügen, verändern oder löschen. Aegis unterscheidet zwischen Dateien in der Baseline und im Change: Die Baseline enthält den aktuellen Stand des Projekts, während im Change alle Files liegen, an denen der Entwickler gerade arbeitet.

Jeder Programmierer sieht das Gesamtprojekt anders: Vorrang haben die Dateien in seinem Change. Falls sie dort nicht existieren, scheinen die Files der Baseline durch. Das gilt nicht für Löschaktionen: Falls der Change das Löschen einer Datei beinhaltet, dann bleibt auch das (noch vorhandene) Original in der Baseline verdeckt. Da sich alle Änderungen auf ihren lokalen Change beschränken, können mehrere Entwickler gleichzeitig eine Datei bearbeiten.

Im Gegensatz zu reinen Revisionskontrollsystemen erlaubt es Aegis dem Entwickler nicht, Dateien nach Belieben zu verändern. Es zwingt ihn, mit Changes zu arbeiten. Ein Change fasst alle Änderungen zusammen, die einem gemeinsamen Zweck dienen. Das vereinfacht den weiteren Prozess: Weil er alle Einzelschritte zusammenhängend sieht, kann der Reviewer besser beurteilen, ob die Entwicklung korrekt ist. Hat er ihn für gut befunden, wird er den Change als Ganzes akzeptieren. Der Lebenszyklus eines Change unterteilt sich damit in die Abschnitte Entwicklung, Review und Integration (siehe Abbildung 1).

Zwischen diesen drei Abschnitten liegen einige Zwischenschritte. Zunächst fügt der Entwickler Dateien aus der Baseline in seinen Change ein. Jetzt kann er ihn verändern: Bugs korrigieren oder neue Funktionen integrieren sowie Dateien als gelöscht markieren oder neu anlegen. Wenn er seine Änderungen für abgeschlossen hält, erklärt er diese Entwicklung für beendet. Danach überprüft Aegis einige Dinge, etwa ob sich der neue Zustand überhaupt übersetzen lässt, denn andere Changes, die inzwischen integriert wurden, könnten Konflikte verursachen. Dann muss der Entwickler erst die Probleme beseitigen.

Review sorgt für Qualität

Anschließend durchläuft der Change den Review-Prozess: Ein unabhängiger Reviewer prüft die Änderungen. Falls ihm Codestellen auffallen, die nicht funktionieren könnten oder schlecht implementiert sind, weist er den Change zurück. Der Entwickler muss dann nachbessern und seinen Change nochmals begutachten lassen.

Sollte der Reviewer der Meinung sein, dass alles korrekt ist, überführt er den Change in den dritten und letzten Zustand: Der Change wird jetzt in die Baseline integriert. Dazu übersetzt der Integrator die Quellen nochmals und kopiert die neuen Dateien in die Baseline. Wenn alles erfolgreich verläuft, löscht Aegis den gesamten Change, da die neue Version nun in der Baseline steht.

Aegis verwendet intern ein herkömmliches Versionskontrollsystem, in der Regel RCS (Revision Control System), um seine Dateien zu verwalten. So lassen sich später alle Änderungen nachvollziehen, die ein Change verursacht hat.

Abbildung 1: Ein Change durchläuft die Stationen Entwicklung, Review und Integration. Ist sein Code nicht einwandfrei, muss der Entwickler nachbessern.

Nur guter Code kommt in die Baseline

Die Integration in die Baseline ist eine atomare Aktion. Während es die Dateien kopiert, blockiert Aegis alle Funktionen, die auf die Baseline zugreifen – sie befindet sich gerade in einem inkonsistenten Zustand, jeder Zugriff würde Verwirrung stiften. Ein Entwickler kann währenddessen seinen Change nicht übersetzen, da er dabei auch Files benötigen könnte, die Aegis gerade in der Baseline austauscht. Bei CVS sind Commits dagegen nicht atomar. Während ein Entwickler seine Dateien eincheckt, kann ein anderer beim Checkout ein inkonsistentes Abbild des Repository erhalten.

Passend zum Change-Lebenszyklus sind die beteiligten Personen nach Rollen eingeteilt. Neben den Administratoren gibt es Entwickler, Reviewer und Integratoren. Die Rollen sind nicht zwangsweise disjunkt, eine Person kann mehrere annehmen. Die Administratoren verteilen die Aufgaben, etwa das Recht, Aegis zu administrieren oder Changes zu integrieren. Eine Regel könnte festlegen, dass alle Entwickler die Changes der anderen reviewen dürfen, aber nur einer zusätzlich Changes integrieren darf – vorausgesetzt er war nicht selbst der Reviewer.

Automatische Tests

Zusätzlich zu den Reviews prüfen automatisierte Tests den Code. Aegis selbst überwacht, ob der Entwickler zu seinem Change auch einen Test-Case geschrieben hat. Dabei handelt es sich um ein Shellskript oder ein Programm, das eine bestimme Funktion der Software prüft. Anhand des Exit-Codes stellt Aegis fest, ob der Test erfolgreich war. Tests werden in drei Situationen aufgerufen:

• Zu jedem Change gibt es mindestens einen Test, der
  überprüft, ob das neue Feature oder der Bugfix
  überhaupt funktionieren.
• Im Baseline-Test führt Aegis den gleichen Test mit Dateien
  der Baseline aus. Dort muss er fehlschlagen. Weil der Test mit den
  Dateien im Change funktioniert, in der Baseline jedoch scheitert,
  ist sichergestellt, dass der Test mindestens eine relevante
  Änderung des Change abdeckt.
• Die dritte Variante ist der Regression-Test. Dabei laufen alle
  Tests, die in der Baseline vorhanden sind, mit den neuen Dateien im
  Change ab. Das garantiert, dass alle Teile, die in der Baseline
  erfolgreich getestet wurden, nach der Integration des neuen Change
  weiterhin funktionieren.

Alte Fehler vermeiden

Diese drei Tests sind ein mächtiges Werkzeug. Sie erleichtern die Code-Entwicklung und verhindern viele Fehler. Eine häufige Falle sind Bugfixes, durch die alte Fehler erneut auftreten. Wer bei einem Bug nur so lange den Code korrigiert, bis er diesen einen Fehler behoben hat, bemerkt nicht, dass er damit vielleicht an anderer Stelle ein neues Problem schafft. Mit Aegis kann er dies zuverlässig vermeiden.E

Als Erstes legt der Entwickler einen Change an und schreibt einen Test, der den Bug provoziert, also aufgrund des Fehlers fehlschlägt. Dann nimmt er die Files in den Change auf, die er verändern muss, um den Bug zu beheben. Er korrigiert den Code, bis der Test erfolgreich verläuft. Bemerkt er, dass der Test den Bug nicht genau genug erkennt, sollte der Programmierer den Test um neue Prüfroutinen erweitern. Ein Lauf als Baseline-Test stellt sicher, dass der neue Test den alten Fehler noch findet. Ist der Bug behoben, führt der Entwickler noch einen Regression-Test durch und weiß, dass alle bisher getesteten Features noch funktionieren.

Aegis allein kann jedoch nicht alle Schritte überwachen. Schreibt der Entwickler einen Test, der nur einen Teil seiner Änderungen abdeckt, im Change erfolgreich läuft und als Baseline-Test scheitert, dann würde er ungetesteten Code in die Baseline einschmuggeln. Der Reviewer muss darauf achten, dass der Test alle Änderungen erfasst. Ist dies nicht der Fall, muss er vom Entwickler weitere Tests fordern oder den Change in unabhängige Teile aufspalten lassen.

Tests als Belohnung

Setzt ein Projekt dieses Vorgehen konsequent ein, dann wird es mit immer mehr Tests belohnt, welche die gesamte Funktionalität der Software abdecken. Es ist gewährleistet, dass der Code in der Baseline jederzeit alle Test erfüllt. In manchen Situationen muss ein Team aber von dieser Idealvorstellung abweichen. Eine neue Formatierung des Quelltextes ändert das Verhalten nicht, sie lässt sich also nicht testen. Die syntaktische Korrektheit wird von Aegis ohnehin vor dem Ende der Entwicklungsphase sichergestellt.

Ein Regression-Test ist dennoch auch bei trivialen Änderungen sinnvoll, um sicher zu sein, dass sich wirklich nur die Formatierung geändert hat. Daher ist es möglich, für einzelne Testarten Ausnahmen zu gewähren. Das darf nicht jeder Entwickler, der Aegis-Administrator kann diese Rolle etwa dem Teamleiter oder speziellen QA-Mitarbeitern (Quality Assurance) zuweisen. Es kann auch globale Ausnahmen für bestimmte Tests geben. Wenn die vollständige Regression-Testsuite zu lange dauert, ist es nicht mehr sinnvoll, sie bei jedem Change laufen zu lassen. Dann ist es besser, sie nachts automatisiert zu starten.

Die Entwicklung verzweigt in Branches

Keine Entwicklung schreitet immer gradlinig voran, oft sind auch ältere Fassung weiterzupflegen. Die unterschiedlichen Zweige verwaltet Aegis in Branches. Alle Branches sind – wie die Changes – durchlaufend nummeriert. Um Konflikte zu vermeiden, kann der Administrator den Changes Nummern ab 100 zuweisen, während er für Branches Nummern von 1 bis 99 verwendet. Er sollte diese Bereiche beim Anlegen des Projekts großzügig wählen. Aegis funktioniert zwar auch mit gemischten Branch- und Change-Nummern, es empfiehlt sich aber, diese getrennt zu halten. So lassen sie sich auf Anhieb unterscheiden.

Ein Branch ist in Aegis als Unterverzeichnis realisiert, das parallel zur Baseline liegt und den Namen »branch. Nummer« trägt. Das Verzeichnis enthält eine eigene Baseline und eventuell weitere Unter-Branches. Der Begriff der Baseline verschiebt sich dadurch etwas: Die Baseline eines Branch besteht aus allen Dateien der übergeordneten Branches und des Projekts. Die Baseline eines Change enthält die Dateien des Branche, in dem der Change angelegt wurde, sowie alle Dateien der übergeordneten Branches und des Projekts.

Für Dateien ergibt sich eine leicht veränderte Suchstrategie: Als Erstes findet Aegis die Files im aktuellen Change. Existiert die Datei dort nicht, schaut das System in den untersten Unter-Branch. Von da aus durchläuft es die Branch-Hierarchie nach oben bis zur Projekt-Baseline. Ist die Datei dort auch nicht vorhanden, existiert sie nicht.

Störend an diesem Konzept ist, dass Änderungen an übergeordneten Branches eventuell auf die Unter-Branches durchscheinen. Wenn eine Datei in einem Branch modifiziert wurde, dann liegt dort eine lokale Version und Änderungen an der übergeordneten Fassung wirken sich nicht aus. Wurde die Datei nicht modifiziert, gibt es keine lokale Kopie und alle Änderungen in übergeordneten Branches gelten auch für den lokalen Branch.

Abbildung 2: Von der Projektseite des Aegis-Webinterface aus kann der Programmierer Informationen über die einzelnen Changes abrufen. Im Bild zu sehen ist das Webinterface des Aegis-Projekts auf Sourceforge.

Gut isolierter Branch

Um dies zu verhindern, empfiehlt es sich, neue Branches zu isolieren. Dabei kopiert man alle Dateien aus der Baseline in den Branch, um Änderungen zu verdecken. Ein Problem bleibt aber bestehen: Fügt jemand in der Baseline eine neue Datei ein, ist diese in allen Branches sichtbar. Wenn dies zu Fehlern führt, etwa weil der Make-Prozess alle vorhandenen Dateien beachtet, dann muss man die neue Datei im entsprechenden Unter-Branch extra löschen.

Um das Projekt mit den Änderungen in einem Change neu zu übersetzen, genügt es nicht, einfach nur »make« aufzurufen. Zunächst muss der Entwickler die internen Abläufe von Aegis darüber informieren, dass er die generierten Dateien neu erzeugen will, also die Quellen neu übersetzen möchte. Dazu gibt es das Aegis-Build-Kommando.

Abbildung 3: Die History-Seite zeigt alle Changes eines Branch an. Ein Link führt zu den Detailinfos (Spalte »History«), die rechte Spalte bietet jeden Change zum Download an.

Automatischer Build: Wie üblich mit Make

Dieses Kommando startet den Make-Prozess und vermerkt einen erfolgreichen Ablauf in den Change-Attributen. Falls zuvor die Tests schon einmal absolviert wurden, entfernt der Aegis-Build diese Information: Die Tests müssen nochmals mit den neuen Executables durchlaufen. Dieser Mechanismus stellt sicher, dass der Entwickler einen Build durchgeführt, die Tests absolviert und danach keine Dateien mehr verändert hat, bevor er den Change beendet.

Um die Abhängigkeiten aufzulösen und den Compiler zu starten, ist Aegis auf das bekannte Make angewiesen. Es könnte alternativ auch andere Tools verwenden, etwa Cook. Dies ist besser auf die Bedürfnisse von Aegis zugeschnitten, da es ebenfalls von Peter Miller entwickelt wird. Cook ist aber weit weniger verbreitet als Make.

Die Integration in den Build-Prozess ist bei Aegis bei weitem nicht so fortgeschritten wie etwa bei der kommerziellen Entwicklungsumgebung Clearcase von Rational[2]. Dort zeigt ein NFS-ähnlicher Mechanismus dem Entwickler immer genau die Dateien im Filesystem, die zu seiner aktuellen View gehören. Da Clearcase keine Changes kennt, besteht eine View im Wesentlichen aus einer Spezifikation, welche Branches eingeblendet werden sollen.

Auch aus Sicht des Compilers befinden sich im Clearcase-Filesystem immer die richtigen Versionen der Source- und Objektdateien. Statt Make benutzt es Clearmake, das auf Dateisystemebene überwacht, welche Files vom Compiler gelesen werden. Damit erkennt Clearmake Abhängigkeiten von Zwischendateien. Eine Optimierung verzichtet sogar auf den Compilerlauf, wenn ein anderer Benutzer aus denselben Quelldateien das gleiche Objekt erzeugt hat. In diesem Fall kopiert Clearmake das Objekt einfach in die aktuelle View.

Verstreute Files sammeln

Von solch starken Eingriffen in das Betriebssystem ist Aegis ein gutes Stück entfernt. Unter “Further Work” weist die Dokumentation zwar darauf hin, dass etwas Ähnliches geplant ist, derzeit liegen die Files jedoch verstreut in den Baselines des Projekts und der Branches sowie im Change.

Um die richtige Datei zu benutzen, gibt es zwei Mechanismen. Die erste Variante erstellt beim Anlegen eines Change für jede Datei einen symbolischen Link. Dann liegen im Change alle Files und ein normales Makefile kann diese bearbeiten. Die Links zeigen auf die Datei im Branch, falls sie dort existiert, andernfalls auf die Datei in der Baseline des Projekts. Um ein File im Branch zu modifizieren, ersetzt Aegis den Link durch eine Kopie. Beim Integrieren wandert die modifizierte Datei vom Change zurück in die Baseline des Branch.

Die zweite Methode kommt ohne symbolische Links aus. Dazu muss der Entwickler seine Makefiles so anpassen, dass sie selbst die richtige Version der Datei aus Change, Branch oder Projekt finden. Aegis stellt ihm die notwendigen Werkzeuge zur Verfügung: Das Aegis-Substitute-Kommando ersetzt Schlüsselwörter in einem Pfadnamen und liefert den absoluten Pfad zur gesuchten Datei. Diesen kann Make benutzen, um Abhängigkeiten aufzulösen und den Compiler aufzurufen.

Die erzeugten Dateien, im Wesentlichen Objekt-Files und ausführbare Dateien, landen beim Build immer im Change. Beim Integrieren verschiebt Aegis sie in die Baseline. Wenn der Linker eine ausführbare Datei aus mehreren Objektdateien erstellt, werden einige Objekte im Change liegen, anderen aber in der Baseline. Arbeitet ein Projekt mit symbolischen Links, dann müssen diese auch für Dateien existieren, die nicht im Change erzeugt wurden.

Für die im Change generierten Files darf kein Link vorhanden sein, sonst würden Compiler und Linker ihre Ausgabedatei nicht lokal im Change ablegen, sondern in die Baseline schreiben. Makefiles, die ohne Links funktionieren, müssen Dateien zum Lesen immer in Change, Branch und Projekt suchen, geschriebene Files jedoch im Change ablegen.

Verteilte Umgebung dank NFS

In der Regel wird Aegis in einer verteilten Umgebung laufen. Im einfachsten Fall sendet jeder Entwickler seine Changes per E-Mail an das zentrale Repository. Dort nimmt ein lokaler User den Review vor und integriert den Change. Für Entwicklerteams, die nicht über das Internet verteilt sind, empfiehlt sich ein anderer Weg: Ein zentraler Server exportiert Repository und Working Directory per NFS. Im Repository befinden sich die Baselines, im Working Directory legen die Entwickler ihre Changes ab.

Alle Aegis-Prozeduren können nun auf jeder der beteiligten Maschinen ablaufen. Die Last bleibt damit verteilt, auch ist das Entwickeln für und unter verschiedenen Betriebssystemen möglich. Aegis stellt mit Hilfe von File-Locks sicher, dass die Kommandos, die auf den einzelnen Maschinen laufen, sich nicht gegenseitig korrumpieren. Während der Integrator gerade Files in die Baseline kopiert, können die Entwickler keine Builds beginnen. Erst wenn das Integrieren beendet ist, laufen die angehaltenen Aegis-Build-Prozesse weiter.

Dieses Vorgehen setzt eine recht enge Kopplung der Rechner voraus. Zum einen merkt sich Aegis bei der Change-Verwaltung die Uhrzeit, wann bestimmte Schritte erfolgt sind. Da diese Schritte eventuell auf verschiedenen Maschinen ablaufen, muss deren Uhrzeit synchronisiert sein. Außerdem funktioniert Make auf NFS-gemounteten Dateisystemen nur richtig, wenn NFS-Server und -Client dieselbe Uhrzeit haben. Das File-Locking muss auch über NFS funktionieren, was bei einigen Betriebssystemen Probleme bereitet.

Flexible Konfiguration

Aegis ist kein starres System, dem sich der Entwicklungsprozess zwangsläufig unterwerfen muss. Vielmehr kann der Administrator an fast jeder Stelle in das System eingreifen, um etwa auf Reviews völlig zu verzichten oder globale Ausnahmen für die Tests zu erteilen. Statt die Entwicklermaschinen per NFS zu verbinden, lassen sich Aegis-Projekte zum Beispiel auch per E-Mail verwalten. Listing 1 zeigt, mit welchen Attributen Aegis für einen Alleinentwickler handhabbar wird – er darf dann alle Schritte selbst ausführen.

Der Build-Prozess ist ebenfalls wählbar. Ob Make, Cook, Ant oder andere zum Einsatz kommen, bleibt dem Administrator überlassen. Aegis verwaltet die Quelldateien nicht selbst, sondern benutzt normalerweise RCS, kann aber auch mit anderen Revisionskontrollsystemen umgehen. Bei RCS bietet es sich an, das bekannte CVS-Webinterface aufzusetzen, das die Änderungen an den Dateien grafisch aufbereitet.

Wie sich die einzelnen Befehle (siehe Kasten “Aegis-Kommandos”) verhalten, ist in einer Konfigurationsdatei in der Baseline festgelegt. Dort steht, welches Tool bei einem Aegis-Build zu starten ist, wie die Tests aufzurufen sind oder wie Aegis Dateien mergen soll. Da das System seine Konfiguration wie eine normale Quelldatei verwaltet, kann es unterschiedliche Versionen für verschiedene Projekte und Branches geben. Änderungen an der Konfiguration müssen ebenfalls durch einen Reviewer geprüft und dann integriert werden.

Abbildung 4: Von den verschiedenen Zustände eines Change führen Undo-Befehle zurück zu einem früheren Schritt. (Darstellung aus User-Guide [3], ergänzt).

Aegis-Kommandos selbst modifizieren

Die Abkürzungen der Aegis-Befehle sind meist als Shellskript implementiert. Das kann der Admin nutzen, um die Kommandos zu modifizieren. Es bietet sich auch an, Befehle zu ergänzen, um etwa aus einer Bug-ID von Bugzilla einen neu-en Change anzulegen. Dieses Kommando sollte Querverweise in den Change-Attributen und in der Bugzilla-Beschreibung automatisch eintragen. Sehr praktisch ist auch »aereport«, das verschiedene Zusammenfassungen generiert. Es gibt etliche vorgegebene Reports, mit einer Report-Skriptsprache sind aber auch eigene Auswertungen möglich.

Außer dem Kommandozeilen-Tool erzeugt auch ein Webinterface Reports (siehe Abbildungen 2 und 3). Ein solcher Report zeigt zum Beispiel alle Changes, die eine spezielle Datei verändert haben. Ein anderer zeigt alle Changes, die derzeit dieselbe Datei verändern, was möglicherweise zu Konflikten führen kann. Es gibt sogar einen Report, der anzeigt, wie lange es im Durchschnitt gedauert hat, die Changes zu entwickeln.

Dokumentation

Aegis ist ausführlich dokumentiert[3] – wegen der vielen Möglichkeiten ist das auch notwendig. Jeder Befehl versteht eine Reihe von Optionen, die in seiner Manpage beschrieben sind. Der User Guide führt den Leser anhand von Beispielen an Aegis heran, auf 126 Seiten stellt er alles Wissenswerte vor. Das Reference Manual fasst alle Manual Pages in einem PDF-Dokument zusammen, es umfasst stolze 378 Seiten. Außerdem gibt es ein Howto mit Lösungen für viele Aegis-Aufgaben.

Die Software steht unter der GNU General Public License und wird seit über zehn Jahren von Peter Miller aktiv entwickelt. Auf[1] ist das Projekt beheimatet. Dort sind Software und Dokumentation erhältlich, auch das Webinterface[4] ist live zu sehen: Aegis wird selbst mit Aegis entwickelt. (fjl)

description = "Ein-Mann-Projekt";
developer_may_review = true;
developer_may_integrate = true;
reviewer_may_integrate = true;
developers_may_create_changes = true;
umask = 022;