Aegis: Toolgestützte Abläufe in der Software-Entwicklung

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.