Bewährte Praktiken
beim Software-Konfigurationsmanagement

Laura Wingerd und Christopher Seiwald
Perforce Software

[ English | Français ]

Kurzfassung

Bei der Einführung von neuen SCM-Werkzeugen (Software-Konfigurationsmanagement) konzentrieren sich die Implementierer manchmal darauf, einzelne Details zu perfektionieren, während andererseits wenig bewährte, aufwändige Verfahren vorheriger Aufgaben oder Werkzeuge unwissentlich beibehalten werden. Dies führt natürlich nicht zum gewünschten Ergebnis. In diesem Whitepaper werden bewährte Praktiken vorgestellt, welche die Erfahrungen der Autoren im Gebrauch von SCM-Software widerspiegeln.

1. Einführung

"Ein Werkzeug ist nur so gut, wie der Benutzer, der es verwendet", sagt man. Als Anbieter von SCM-Werkzeugen und Berater von Softwareunternehmen werden wir häufig um Rat zu bewährten Praktiken für SCM gefragt, d.h. wie SCM-Software eingesetzt werden sollte, um den höchstmöglichen Nutzen daraus ziehen zu können. Bei der Beantwortung dieser Fragen können wir uns auf weitreichende unmittelbare und mittelbare Erfahrungen, die wir mit SCM gemacht haben, beziehen. Direkte Erfahrungswerte stammen von unseren Entwicklern und Entwicklungspfad-Managern (Codeline Manager), indirekte Erfahrungswerte von Kunden-Feedback über positive und negative Erfahrungen mit den Produkten von Perforce und anderen SCM-Werkzeugen.

Die nachstehende Tabelle führt sechs allgemeine Bereiche beim Einsatz von SCM sowie einige breitgefächerte bewährte Praktiken für jeden dieser Bereiche auf. In den folgenden Abschnitten werden diese Bereiche näher erläutert.

 

Arbeitsbereiche In denen Entwickler , testen, Fehler beheben und den Produkt-Build erstellen.	Nutzen Sie Arbeitsbereiche nie gemeinsam. Arbeiten Sie nicht außerhalb verwalteter Arbeitsbereiche. Verwenden Sie keine Ansichten mit externen Abhängigkeiten ("Jello Views"). Bleiben Sie synchron mit Ihrem Entwicklungspfad. Checken Sie häufig ein.
Entwicklungspfade (Codelines) Die kanonische Menge der Quelldateien.	Weisen Sie jedem Entwicklungspfad eine Richtlinie zu. Weisen Sie jedem Entwicklungspfad einen Verantwortlichen zu. Verwenden Sie einen Hauptentwicklungspfad.
Branching Ermöglicht Entwicklungspfadvarianten.	Branchen Sie nur, wenn unbedingt erforderlich. Kopieren Sie nicht, wenn Sie eigentlich branchen möchten. Branchen Sie bei inkompatiblen Richtlinien. Branchen Sie so spät wie möglich im Entwicklungsprozess. Branchen Sie anstatt zu "freezen" (den Code sperren).
Änderungspropagierung Mit der Änderungen von einem Entwicklungspfad auf den nächsten übertragen werden.	Nehmen Sie Original-Änderungen an dem geradlinigsten Branch vor. Propagieren Sie häufig und von Anfang an. Zusammenführungen sollten nur von kompetenten Mitarbeitern vorgenommen werden.
Builds Machen aus Quelldateien richtige Produkte.	Quelle + Werkzeuge = Produkt. Checken Sie alle Original-Quelldateien ein. Trennen Sie Build-Objekte von den Original-Quelldateien. Verwenden Sie gängige Build-Werkzeuge. Führen Sie häufig Build-Vorgänge aus. Bewahren Sie Build-Protokolle und Build-Ausgaben ("Build Outputs") auf.
Prozesse Bestimmen alles oben Genannte.	Verfolgen Sie Änderungspakete. Verfolgen Sie Propagierungen von Änderungspaketen. Unterscheiden Sie zwischen Änderungsanforderungen und Änderungspaketen. Jeder Vorgang, jeder Entwicklungspfad, jede Aufgabe, jede Komponente, jede Richtlinie, jedes Dokument und jedes Produkt Ihres SCM-Systems sollte einen Verantwortlichen haben. Verwenden Sie lebendige Dokumente.

2. Der Arbeitsbereich

Im Arbeitsbereich bearbeiten Entwickler Quelldateien, erstellen Softwarekomponenten, testen und beheben Fehler. Die meisten SCM-Systeme verfügen über einen Arbeitsbereich in der einen oder anderen Form. Dieser wird gelegentlich auch als "Sandbox" (wie bei Source Integrity) oder "Views" (wie bei ClearCase und Perforce) bezeichnet. Änderungen an verwalteten SCM-Repository-Dateien beginnen als Änderungen an Dateien in einem Arbeitsbereich.

Bewährte Praktiken für Arbeitsbereiche:

• Nutzen Sie Arbeitsbereiche nie gemeinsam. Jeder Arbeitsbereich sollte nur einen einzigen Zweck haben, beispielsweise der Bereich, in dem ein einziger Entwickler den Quellcode bearbeitet, den Produkt-Build durchführt und testet oder ein Bereich, in dem Produkt-Build, Test und die Release Freigabe stattfindet. Das gemeinsame Nutzen von Arbeitsbereichen erzeugt ein Durcheinander, genauso wie die gemeinsame Nutzung des Schreibtisches. Außerdem wird dadurch die Funktion des SCM-Systems beeinträchtigt, Aktivitäten nach Benutzern oder Aufgaben zu verfolgen. Arbeitsbereiche und der dadurch verwendete Festplattenspeicher sind nicht teuer. Sparen Sie also nicht am falschen Ende.
• Arbeiten Sie nicht außerhalb verwalteter Arbeitsbereiche. Ihr SCM-System kann Abläufe nur dann prüfen, wenn diese in verwalteten Arbeitsbereichen ausgeführt werden. Benutzer, die außerhalb von Arbeitsbereichen arbeiten, sind von dieser Fülle an Informationen abgeschnitten und können diese nicht nutzen. Beispielsweise verwenden SCM-Systeme generell Arbeitsbereiche, um die Kommunikation zwischen Entwicklern, die an ähnlichen Aufgaben arbeiten, zu erleichtern. Sie sehen, was in anderen Arbeitsbereichen geschieht und die anderen Entwickler sehen, was in Ihrem Arbeitsbereich geschieht. Sind Sie beispielsweise im Urlaub, ist möglicherweise Ihr optimal verwalteter Arbeitsbereich alles, was die anderen nutzen können. Grenzen Sie Arbeitsbereiche klar ab.
• Verwenden Sie keine Jello Views (Ansichten mit externen Abhängigkeiten). Eine Datei in Ihrem Arbeitsbereich sollte nur geändert werden, wenn Sie die Änderung ausdrücklich durchführen möchten. Eine Jello View ist ein Arbeitsbereich, in dem Änderungen an Dateien durch externe Ereignisse verursacht werden, auf die Sie keinen Einfluss haben. Ein typisches Beispiel dafür ist ein Arbeitsbereich, der auf einen Baum symbolischer Links zu Dateien in einem anderen Arbeitsbereich aufbaut. Werden die Basisdateien aktualisiert, ändern sich die Dateien Ihres Arbeitsbereichs. Jello Views verursachen häufig große Probleme bei der Softwareentwicklung. Debug-Symbole in ausführbaren Programmen stimmen nicht mit den Quelldateien überein, es entstehen unerklärliche Neukompilationen bei angeblich trivialen Rebuilds, und Fehlerbehebungs-Zyklen sind nie aufeinander abgestimmt - um nur ein Paar der auftretenden Probleme zu nennen. Sorgen Sie dafür, dass Ihre Arbeitsbereiche immer fehlerfrei und stabil sind, und richten Sie sie so ein, dass Benutzer die Kontrolle darüber haben, wenn sich deren Dateien ändern.
• Bleiben Sie synchron mit Ihrem Entwicklungspfad. Als Entwickler hängt die Qualität Ihrer Arbeit davon ab, wie gut sie mit der Arbeit anderer abgestimmt ist. Anders ausgedrückt bedeutet das, dass Sie, wenn Änderungen in den Entwicklungspfad eingecheckt werden, Ihren Arbeitsbereich aktualisieren und diese Änderungen mit Ihrer Arbeit abstimmen sollten.

• Checken Sie häufig ein. Für die Integration Ihrer Entwicklungsarbeiten mit der Arbeit anderer müssen auch Sie Ihre Änderungen einchecken, sobald diese fertig sind. Haben Sie eine Entwicklungsaufgabe abgeschlossen, checken Sie Ihre geänderten Dateien ein, damit Ihre Arbeit auch von anderen genutzt werden kann.

3. Der Entwicklungspfad

In diesem Zusammenhang ist der Entwicklungspfad die kanonische Menge der Quelldateien, die für das Erstellen von Software erforderlich sind. Entwicklungspfade sind normalerweise verzweigt. Die Verzweigungen (Branches) bilden verschiedene Entwicklungspfade, die verschiedene Versionen darstellen.

Bewährte Praktiken für Entwicklungspfade:

• Weisen Sie jedem Entwicklungspfad eine Richtlinie zu. Eine Richtlinie gibt die passende Verwendung und zulässige Eincheckregeln für den Entwicklungspfad an. Sie stellt im Prinzip das Benutzerhandbuch für Entwicklungspfad-SCM dar. Beispielsweise sollte die Richtlinie für einen regulären Entwicklungspfad angeben, dass er nicht für ein Release bestimmt ist. Andererseits sollte die Richtlinie für einen Release-Entwicklungspfad Änderungen auf genehmigte Fehlerbehebungen beschränken1. Die Richtlinie kann auch festlegen, wie Änderungen in einem Dokument eingecheckt werden, welche Prüfungen erforderlich sind, welche Tests durchgeführt werden müssen und welche Anforderungen bezüglich der Entwicklungspfadstabilität nach dem Einchecken bestehen. Eine Richtlinie ist eine kritische Komponente für einen dokumentierten, durchsetzbaren Software-Entwicklungsprozess. Ein Entwicklungspfad ohne Richtlinie ist aus der Sicht des SCM ein außer Kontrolle geratener Vorgang.
• Weisen Sie jedem Entwicklungspfad einen Verantwortlichen zu. Haben Sie erstmal eine Richtlinie für einen Entwicklungspfad definiert, werden Sie bald mit Sonderfällen konfrontiert, in denen die Richtlinie nicht zutreffend oder nicht eindeutig ist. Entwickler, die diesen Unklarheiten gegenüber stehen, wenden sich an die dafür zuständige Person, um dieses Hindernis zu beseitigen. Ist niemand dafür verantwortlich, versuchen Entwickler häufig, das Problem eigenständig zu lösen, ohne dass dies dokumentiert wird. Oder sie schieben das Problem vor sich her, da ihnen nicht genügend Informationen über den Entwicklungspfad zur Verfügung stehen, um eine vernünftige Lösung zu konzipieren. Sie können diese Probleme vermeiden, indem Sie dem Entwicklungspfad während der gesamten Nutzungsdauer einen Verantwortlichen zuweisen. Mit diesem Ziel vor Augen kann der Verantwortliche des Entwicklungspfads Hindernisse bei der Software-Entwicklung beseitigen, indem er Entwickler auf Richtlinien-Ausnahmen hinweist und diese auch dokumentiert.
• Verwenden Sie einen Hauptpfad. Ein Hauptpfad (mainline) - auch Stamm (trunk) genannt - ist der dauerhaft bestehende Branch eines Entwicklungspfads welcher sich immer weiterentwickelt. Ein Hauptpfad ist das letzte Ziel für fast alle Veränderungen - sowohl für Wartungsarbeiten als auch neue Funktionen. Er ist die erste lineare Entwicklung eines Softwareproduktes. Release-Entwicklungspfade und auch reguläre Entwicklungspfade zweigen vom Hauptpfad aus ab. Arbeiten in den Branches werden zurück an den Hauptpfad propagiert.

Abbildung 1 zeigt einen Hauptpfad ("main"), von dem verschiedene Versionsentwicklungspfade ("ver1", "ver2" und "ver3") und Funktions-Entwicklungspfade ("projA", "projB", und "projC") abgezweigt sind. Entwickler arbeiten im Hauptpfad oder in einem Pfad zur Funktionsentwicklung. Die Versions-Entwicklungspfade sind für das Testen und kritische Problembehebungen vorgesehen und sind von den übrigen Entwicklungsarbeiten abgeschnitten. Schließlich werden alle Änderungen in den Versions-Entwicklungspfaden und den Funktions-Entwicklungspfaden in den Hauptpfad integriert.

Die andere Möglichkeit besteht darin, die Entwicklungspfade zu verästeln und ihnen eine neue Verwendungsmöglichkeit zuzuweisen. Beispielsweise kann ein Entwicklungspfad zu einem Release-Entwicklungspfad weiterentwickelt werden. Dann wird ein neuer Entwicklungspfad abgezweigt. So zeigt Abbildung 2 z.B. einen Entwicklungspfad, der zu einem Versionsentwicklungspfad ("ver1") weiterentwickelt wurde, der in einen anderen Entwicklungspfad ("projA") "brancht". Jeder Versions-Entwicklungspfad beginnt als Entwicklungspfad, und die Entwicklung setzt sich über die einzelnen Entwicklungspfade fort.

Das Verästelungsschema hat zwei eindeutige Nachteile: (1) die Richtlinie für einen Entwicklungspfad muss sich ändern. Dies allen mitzuteilen, stellt fast immer ein Problem dar, und (2) Entwickler müssen in Bearbeitung befindliche Arbeiten einem anderen Entwicklungspfad zuweisen. Das führt häufig zu Fehlern und ist auch zeitaufwändig. 90% des SCM-Vorgangs umfasst das Verästeln von Entwicklungspfaden, um die Tatsache auszugleichen, dass kein Hauptpfad vorhanden ist.

Die Abläufe werden optimiert und vereinfacht, wenn Sie ein Hauptpfad-Modell verwenden. Mit einem Hauptpfad sind die Arbeitsbereiche der Mitarbeiter und Umgebungen für die Dauer ihrer Aufgaben stabil. Es ist kein zusätzlicher administrativer Aufwand erforderlich, wenn die Softwareprodukte weiterentwickelt werden.

4. Das Branching

Branching ist das Erstellen abweichender Entwicklungspfade aus anderen Entwicklungspfaden. Dies ist der problematischste Bereich beim SCM. Verschiedene SCM-Tools unterstützen Branching auf unterschiedliche Weise. Für die verschiedenen Richtlinien sind ganz verschiedene Branches (Verzweigungen) erforderlich. Beim Branching waren uns vor allem folgende Hinweise äußerst hilfreich (manchmal auch dabei, Branching zu vermeiden):

• Branchen Sie nur, wenn dies unbedingt erforderlich ist. Jedes Branching bedeutet mehr Arbeit - weitere Builds, mehr Änderungen, die bei den Entwicklungspfaden propagiert werden müssen, und mehr Zusammenführungen von Quelldateien. Wenn Sie dies jedes Mal im Auge behalten, wenn Sie ein Branching erwägen, lässt sich unnötiges Branching leicht vermeiden.
• Kopieren Sie nicht, wenn Sie eigentlich branchen möchten. Eine Alternative zur Branching-Funktion Ihres SCM-Tools ist es, eine Menge von Quelldateien von einem Entwicklungspfad zu kopieren und diese als neue Dateien in einen anderen Entwicklungspfad einzuchecken. Sie können die negativen Auswirkungen des Branching durch das Kopieren jedoch nicht vermeiden. Das Kopieren verursacht dieselben Probleme wie das Branching: zusätzliche Entitäten und komplexere Strukturen. Jedoch können Sie die Vorzüge für die Unterstützung der Branching-Funktion des SCM-Systems nicht nutzen. Machen Sie sich nichts vor: selbst schreibgeschützte Kopien für eine andere Entwicklergruppe kommen oft geändert zurück. Verwenden Sie das SCM-System zum Branching, wenn Sie den ganzen Entwicklungspfad oder Teile davon abspalten möchten.
• Branchen Sie bei inkompatiblen Richtlinien. Es gibt eine Faustregel dafür, ob ein Entwicklungspfad abgespaltet werden soll oder nicht. Das Branching empfiehlt sich, wenn Benutzer unterschiedliche Richtlinien zum Einchecken benötigen. Beispielsweise ist für eine Produktversionsgruppe möglicherweise eine Richtlinie zum Einchecken erforderlich, für die striktes Testen notwendig ist, wobei ein Entwicklungsteam möglicherweise eine Richtlinie benötigt, mit der teilweise getestete Änderungen häufig eingecheckt werden können. Für diese unterschiedlichen Richtlinien ist ein Branching der Entwicklungspfade erforderlich. Sollen die Änderungen der einen Gruppe für die andere nicht sichtbar sein, ist dies auch eine Art inkompatible Richtlinie: Jede Gruppe sollte über einen eigenen Branch verfügen.
• Branchen Sie so spät wie möglich im Entwicklungsprozess. Um die Anzahl von Änderungen die von einem Branch zum anderen propagiert werden müssen möglichst gering zu halten, sollten Sie ein Branching erst möglichst spät vornehmen. Enthält der Hauptpfad-Branch alle neuen Funktionen für ein neues Release, testen Sie diese ausgiebig und beheben Sie Probleme, bevor Sie einen Release-Branch erstellen. Jedes Problem, das im Hauptpfad vor dem Branching behoben wird, ist eine Änderung weniger, die zwischen den Branches propagiert werden muss.
• Branchen Sie, anstatt zu "freezen" (den Code sperren). Ist jedoch für das Testen das Freezen eines Entwicklungspfads erforderlich, müssen Entwickler mit ihren Änderungen warten, bis die Testphase abgeschlossen ist. In diesem Fall sollten Sie den Entwicklungspfad früh genug branchen, damit Entwickler einchecken und mit ihrer Arbeit fortfahren können.

5. Die Änderungspropagierung

Nach dem Branching müssen Sie die Dateiänderungen auf alle dazugehörigen Entwicklungspfade propagieren. Das ist selten einfach, aber es gibt Maßnahmen, mit denen Sie den Aufwand im Rahmen halten können.

• Nehmen Sie Original-Änderungen an den geradlinigsten Branches vor. Es ist viel einfacher, eine Änderung aus einer Datei zu integrieren, die nahe am gemeinsamen Ausgangspunkt ist, als eine Änderung aus einer Datei, die viele Verzweigungen hat. Das liegt daran, dass die Änderung in einer Datei, die oft gebrancht wurde, auf Änderungen aufbauen kann, welche nicht propagiert wurden. Diese unerwünschten Änderungen können den Zusammenführungsvorgang erschweren. Sie können die Komplexität der Zusammenführung gering halten, indem Sie Original-Änderungen am stabilsten Branch vornehmen. Wurde beispielsweise ein Release-Entwicklungspfad von einem Hauptpfad abgezweigt, sollten Sie das Problem erst im Release-Entwicklungspfad beheben und diese Lösung dann in den Hauptpfad integrieren. Beheben Sie das Problem zuerst im Hauptpfad, müssen Sie möglicherweise andere, inkompatible Änderungen, die nicht im Release-Entwicklungspfad erscheinen sollen, zurücknehmen, wenn Sie die Problemlösung anschließend in den Release-Entwicklungspfad integrieren.
• Propagieren Sie häufig und von Anfang an. Kann eine Veränderung von einem Branch zum anderen propagiert werden (d.h. wenn die Änderung die Richtlinie des Ziel-Branch nicht verletzt), sollten Sie dies so bald wie möglich ausführen. Änderungspropagierungen die aufgeschoben wurden und sich ansammeln können zu äußerst komplizierten Zusammenführungen von Dateien führen.
• Zusammenführungen sollten nur von kompetenten Mitarbeitern vorgenommen werden. Die Probleme mit Änderungspropagierung können vermindert werden, indem Sie dem Ingenieur, der für die Lösung von Dateikonflikten am kompetentesten ist, diese Aufgabe zuweisen. Änderungen können (a) vom Verantwortlichen der Zieldateien, (b) demjenigen, der die Original-Änderungen ausgeführt hat oder (c) von einem anderen Mitarbeiter durchgeführt werden. Es versteht sich von selbst, dass (a) und (b) besser dafür geeignet sind als (c).

6. Builds

Ein Build ist das Erstellen verwendbarer Software aus Original-Quelldateien. Builds können einfacher verwaltet werden und führen seltener zu Problemen, wenn diese wichtigen Hinweise beachtet werden:

• Quelle + Werkzeuge = Produkt. Ein Produkt-Build sollte nur auf Quelldateien und den nötigen Build-Werkzeugen basieren. Auswendig gelernte Verfahren und Notizen sind hier fehl am Platz. Bei denselben Quelldateien und Build-Tools sollten die Endprodukte auch identisch sein. Sind Routine-Setup-Verfahren vorhanden, sollten diese in Skripts automatisiert werden. Sind manuelle Setup-Schritte vorhanden, dokumentieren Sie diese in Build-Anweisungen. Dokumentieren Sie auch alle technischen Daten zu Werkzeugen, wie das Betriebssystem, Compiler-Programme, Dateien, Link-Bibliotheken, Make-Programme und ausführbare Pfade.
• Checken Sie alle Original-Quelldateien ein. Kann Ihre Software nicht mit denselben Eingaben zuverlässig reproduziert werden, sind wohl nicht alle nötigen Quellen eingecheckt. Häufig werden Make-Dateien, Setup-Skripts, Build-Skripts, Build-Anweisungen und technische Daten von Tools übersehen. Doch mit diesen Quellinformationen konzipieren Sie die Software. Denken Sie daran: Quelle + Werkzeuge = Produkt.
• Trennen Sie Build-Objekte von den Original-Quelldateien. Sie sollten Ihre Builds so organisieren, dass die Verzeichnisse mit den Original-Quelldateien keine Build-Objekte enthalten. Original-Quelldateien sind Dateien, die Sie "mithilfe eines originellen Gedankenprozesses", mit einem Texteditor, einem Anwendungsgenerator oder einem anderen interaktiven Tool erstellen. Zu den Build-Objekten zählen alle Dateien, die während des Build-Vorgangs erstellt werden, beispielsweise auch generierte Quelldateien. Build-Objekte sollten nicht in den Quellcode-Verzeichnissen erscheinen. Sie sollten in einem eigenständigen Verzeichnisbaum aufgebaut werden. Diese Trennung ermöglicht es den Umfang von SCM-verwalteten Verzeichnissen auf die benötigten Quelle zu beschränken. Das vermindert auch die Anzahl großer Dateien und/oder Dateien die an einem bestimmten Ort nicht unbedingt benötigt werden. Außerdem wird das Speichermanagement beim Produkt-Build vereinfacht.
• Verwenden Sie gängige Build-Werkzeuge. Entwickler, Testingenieure und Release-Ingenieure sollten alle dieselben Build-Tools verwenden. Es nimmt viel Zeit in Anspruch, wenn ein Entwickler ein beim Testen aufgetretenes Problem nicht reproduzieren kann oder das freigegebene Produkt sich von dem getesteten unterscheidet. Denken Sie daran: Quelle + Werkzeuge = Produkt.
• Führen Sie häufig Build-Vorgänge aus. Häufige komplett Builds mit Regressionstests ("Sanity Builds") haben zwei Vorteile: (1) Sie zeigen Integrationsprobleme auf die durch das Einchecken entstehen, und (2) erzeugen Link-Bibliotheken und andere Build-Objekte, die von Entwicklern verwendet werden können. Idealerweise werden "Sanity Builds" nach jedem Einchecken ausgeführt. In einem aktiven Entwicklungspfad ist es jedoch praktischer, diese in Intervallen, normalerweise über Nacht, zu erstellen. Bei jedem Branching des Entwicklungspfades sollten regelmäßig umfassende Build- und Regressionstests durchgeführt werden, auch wenn die Produktfreigabe noch in weiter Ferne liegt.
• Bewahren Sie Build-Protokolle und Build-Ausgaben ("Build Outputs") auf. Sie sollten für alle von Ihnen erstellten Build-Objekte die genauen Vorgänge (beispielsweise vollständige Compiler-Schalter und Link-Befehlstexte) finden können, mit denen die letzte gültige Version erstellt wurde. Archivieren Sie Build-Ausgaben und Build-Protokolle mit den Quelldatei-Versionen (z.B. einem Label), Tools und Betriebssystem-Versionen, Compiler-Ausgaben, Zwischendateien, Build-Objekten und Testergebnissen für die zukünftige Verwendung. Bei großen Softwareprojekten werden im Laufe der Entwicklung Komponenten von einer zur nächsten Gruppe weitergereicht. Die neue Gruppe kann möglicherweise nicht sofort Builds neuer Komponenten erstellen. Werden neue Komponenten gebaut, benötigen Sie Zugang zu älteren Build-Protokollen, um eventuelle Integrationsprobleme zu lösen.

7. Prozesse

Ganze Bücher wären nötig, um das Konzept und die Implementierung von SCM abdecken zu können, und es wurde bereits viel über dieses Thema geschrieben. Ihr Unternehmen hat bestimmte Ziele und Anforderungen, die sich in den von Ihnen implementierten Prozessen zeigen, und die uns nicht bekannt sind. Unserer Erfahrung nach sind einige Abläufe für eine SCM-Implementierung aber äußerst wichtig:

• Verfolgen Sie Änderungspakete. Obwohl jede Datei in einem Entwicklungspfad einen Revisionsverlauf hat, ist jede Revision in seiner Historie nur im Rahmen von im Zusammenhang stehenden Dateien sinnvoll. Die Frage "Welche Quelldateien wurden neben der Quelldatei foo.c noch geändert?" kann nur beantwortet werden, wenn Sie Änderungspakete oder die Menge von Dateien verfolgen, die durch logische Änderungen miteinander in Verbindung stehen. Nicht die individuellen Dateiänderungen sondern Änderungspakete sind ein sichtbares Zeichen der Softwareentwicklung. Manche SCM-Systeme verfolgen Änderungen für Sie. Wenn Ihr System diese Funktionalität nicht beinhaltet, entwickeln Sie Ihre eigene Schnittstelle, welche diese Funktionalität bietet.
• Verfolgen Sie Propagierungen von Änderungspaketen. Ein eindeutiger Vorteil des Verfolgens von Änderungspaketen ist, dass logische Änderungen (z.B. Fehlerbehebungen) ganz einfach von einem Entwicklungspfad-Branch zum anderen propagiert werden können. Es reicht jedoch nicht aus, diese Änderungspakete über die Branches zu propagieren. Sie müssen auch verfolgen, welche Änderungspakete propagiert wurden, welche Propagierungen noch ausgeführt werden müssen, und welche Entwicklungspfad-Branches möglicherweise Propagierungen erhalten oder an andere Entwicklungspfade weitergeben. Sonst können Sie die Frage "Löst dies das Problem X im Entwicklungspfad für die Version Y?" nie beantworten. Manche SCM-Systeme verfolgen das Propagieren von Änderungspaketen für Sie, andernfalls müssen Sie diese Funktionalität selbst bereitstellen. Sie sollten jedoch nie einen Dateivergleich vornehmen müssen, um herauszufinden, ob ein Änderungspaket zwischen zwei Entwicklungspfaden propagiert wurde.
• Unterscheiden Sie zwischen Änderungsanforderungen und Änderungspaketen. "Noch zu erledigen" und "Bereits erledigt" sind zwei verschiedene Entitäten. Ein Fehlerbericht gehört beispielsweise in die Kategorie "Noch zu erledigen" und eine Fehlerbehebung in die Kategorie "Bereits erledigt". Ihr SCM-Ablauf sollte zwischen diesen unterscheiden, denn es können mehrdirektionale Beziehungen zwischen Änderungsanforderungen und Änderungspaketen bestehen.
• Jeder Vorgang, jeder Entwicklungspfad, jede Aufgabe, jede Komponente, jede Richtlinie, jedes Dokument und jedes Produkt Ihres SCM-Systems sollte einen Verantwortlichen haben. Die zuständige Person repräsentiert die jeweilige Entität. So können sich diese Entitäten sinnvoll weiterentwickeln. Entitäten ohne einen Verantwortlichen sind Hindernisse, die die Mitarbeiter umgehen, aber nicht überwinden.
• Verwenden Sie lebendige Dokumente. Die von Ihnen implementierten Richtlinien und Verfahren sollten in einem lebendigen Dokument beschrieben werden. Die Prozessdokumentation sollte genauso zur Verfügung stehen und aktualisiert werden wie verwaltete Quelldateien. Dokumente, auf die nicht zugegriffen werden kann, sind genauso nutzlos wie solche, die nicht aktualisiert werden. Prozessdokumente sollten von allen Entwicklungsumgebungen aus gut erreichbar sein: in Ihrem eigenen Arbeitsbereich oder dem eines Mitarbeiters und auch von Ihrem Computer zu Hause aus. Prozessdokumente sollten leicht aktualisierbar sein und Änderungen sollten sofort zur Verfügung stehen.

8. Schlussfolgerung

Bewährte Praktiken für SCM, oder für jeden anderen Bereich, erscheinen offensichtlich sobald Sie sie einmal angewandt haben. Die hier behandelten Verfahren haben sich für uns bewährt. Natürlich kann eine einzige kurze Abhandlung wie diese nicht alle Verfahren abdecken. Wir haben uns daher auf diejenigen beschränkt, die sich für uns am nützlichsten erwiesen haben und die trotzdem häufig nicht eingehalten werden.

Wir sind beständig bestrebt, dieses Dokument zu verbessern. Kritik sowie weitere inhaltliche Ansätze sind jederzeit willkommen.

9. Referenzen

Berczuk, Steve. "Configuration Management Patterns", 1997. Erhältlich unter http://www.bell-labs.com/cgi-user/OrgPatterns/OrgPatterns?ConfigurationManagementPatterns.

Compton, Stephen B, Configuration Management for Software, VNR Computer Library, Van Nostrand Reinhold, 1993.

Continuus Software Corp., "Work Area Management", Continuus/CM: Change Management for Software Development. Erhältlich unterhttp://www.continuus.com/developers/developersACE.html.

Dart, Susan, "Spectrum of Functionality in Configuration Management Systems", Software Engineering Institute, 1990. Erhältlich unter http://www.sei.cmu.edu/technology/case/scm/tech_rep/TR11_90/TOC_TR11_90.html

Jameson, Kevin, Multi Platform Code Management, O'Reilly & Associates, 1994

Linenbach, Terris, "Programmers' Canvas: A pattern for source code management" 1996. Erhältlich unter http://www.rahul.net/terris/ProgrammersCanvas.htm . .

Lyon, David D, Practical CM, Raven Publishing, 1997

McConnell, Steve, "Best Practices: Daily Build and Smoke Test", IEEE Software, Vol. 13, Nr. 4, Juli 1996

van der Hoek, Andre, Hall, Richard S., Heimbigner, Dennis, and Wolf, Alexander L., "Software Release Management", Proceedings of the 6th European Software Engineering Conference, Zürich, Schweiz, 1997.

Hinweise:

1.

Bewährte Richtlinien für Entwicklungspfade: Funktions-Entwicklungspfad: Vorläufige Codeänderungen können eingecheckt werden, betroffenen Komponenten müssen erzeugbar sein (buildable). Release-Entwicklungspfad: Die Software muss Build- und Regressionstests vor dem Einchecken bestehen; Check-Ins sollten auf Fehlerbehebungen beschränkt werden; es sollten keine neuen Funktionen oder Funktionalitäten eingecheckt werden; nach dem Einchecken wird der Branch "gefreezt", bis der Qualitätssicherungszyklus abgeschlossen ist. Hauptpfad: Alle Komponenten müssen kompiliert und verbunden werden und Regressionstests bestehen; abgeschlossene, getestete neue Funktionen können eingecheckt werden.