DCVS Snapshots und Change Sets in der Praxis verteilter Softwareentwicklung

Wenn Sie ein erfahrener CVS-Benutzer sind, wundern Sie sich vielleicht, warum Snapshots und Change Sets für Configuration Management -- insbesondere für Configuration Management im Rahmen verteilter Softwareentwicklung -- eine besondere Errungenschaft sein sollen. "Schließlich gibt es bereits Tags um Konfigurationen zu kennzeichnen und der Unterschied zwischen zwei Tags beschreibt doch indirekt ein Change Set", werden Sie denken.

Der folgende Text wird die erheblichen Vorteile dieser Konzepte und ihre effiziente Anwendung im Configuration Management verteilter Enwicklungsszenarien erläutern.

Der Text soll auch für diejenigen Leser verständlich und interessant sein, die sich noch nicht als (D)CVS-Experten betrachten.

Was ist der besondere Vorteil von Snapshots gegenüber Tags?

Tags in CVS bilden für eine Menge von Dateien symbolische Namen auf Revisionsnummern ab. Branch Tags unterscheiden sich in dieser Hinsicht nicht von einfachen Tags; sie weisen lediglich auf eine bestimmte Sorte Revisionsnummern hin.

Die folgenden Punkte verdienen jedoch besondere Aufmerksamkeit:

  1. Tags können sich im Laufe der Zeit ändern (es gibt keinen Schutzmechanismus).
  2. Tags sind auf eine große Anzahl Dateien verteilt.

Das heißt, dass sie keine eigene Existenz haben und daher nicht unveränderlich sind hinsichtlich unterschiedlicher Dateimengen.

Aus der Sicht des Release Managements und des zuverlässigen Configuration Managements sind Tags daher keine wirklich angemessene Methode, um geschlossene Konfigurationen zu erstellen. Geschlossene Konfigurationen sind das grundlegende Konzept für das Einfrieren bekannter und funktionierender Versionen eines Systems, z.B. für Releases oder interne Referenzkonfigurationen. Aus diesem Grunde ist die wichtigste Anforderung zur Umsetzung dieses Konzepts aus der Sicht des Configuration Managements, dass sie über lange Zeit stabil sind und sich nicht verändern.

Verwendet man Tags zur Darstellung geschlossener Konfigurationen, kann man nicht wirklich garantieren, dass sie sich nicht verändern (es gibt kein Konzept für Zugangskontrolle und für die Sperrung von Tags bei CVS). Darüber hinaus kann man einem Tag nicht entnehmen, welche Dateien zu der Konfiguration gehören, es sei denn, man fügt ihnen eine Liste aller betroffenen Dateien bei (Manifest).

Das Erstellen von Manifesten und Listen, die wichtige Bestandteile und Voraussetzungen aufführen, ist eine der Hauptaufgaben des Configuration Managements. Es ist nur ein kleiner, aber äußerst nutzbringender Schritt, diese Listen durch die konkrete Version jeder betroffenen Datei zu ergänzen und das ganze als unabhängiges Objekt, bei DCVS Snapshots genannt, zu speichern.

Was ist der besondere Nutzen von Change Sets für Configuration Management?

Während unserer Arbeit bei Kunden trafen wir meist auf Change Management Prozesse, die auf dem Modell von Referenzkonfigurationen und Change Sets basierten. Das überrascht nicht besonders, da dieses Modell ziemlich überschaubar und intuitiv ist. Referenzkonfigurationen sind stabile Konfigurationen, die als Grundlage für jede Art von Entwicklung dienen. Es kann sich hierbei um angestrebte neue Eigenschaften und Funktionalität handeln, oder aber um eine Verbesserung der Stabilität und Robustheit oder um die Verbesserung der Effizienz, wie es oft bei Kunden-Releases erforderlich ist.

Change Sets im Release und Configuration Management:

Neue Releases folgen nicht notwendigerweise den Entwicklungslinien, die im Versionskontroll-Repositorium entwickelt werden. Sie entstehen viel häufiger aus stabilen Referenzkonfigurationen, die mit Hilfe von Mengen bekannter und getesteter Änderungen (repräsentiert durch Change Sets) weiterentwickelt wurden. Die Konzepte Referenzkonfiguration und Change Set sind also einer höheren Ebene des Configuration Managements zuzuordnen als Tags und Entwicklungslinien. Sie können auch als Schnittstelle betrachtet werden zwischen der Ebene des tatsächlichen Entwicklungsprozesses und einer höheren Ebene, auf der Projekt- oder Produkt-Management interessant sind.

DCVS unterstützt diese Konzepte durch die Implementierung von Snapshots und Change Sets. Snapshots können für die Identifikation von Referenzkonfigurationen verwendet werden. Change Sets repräsentieren Funktionserweiterungen und Fehlerkorrekturen und gehören daher zu der Art Objekte, die in jedem Prozesskontroll- oder Change Management-System referenziert werden müssen.

Change Sets resultieren aus bearbeiteten Änderungsanfragen (Change Requests) und Fehlerberichten (bug reports, trouble tickets, etc.). Sie sollten im CM Prozess daher mit diesen Objekten verknüpft sein.

Change Sets in DCVS:

Ein Change Set kann als eine Kombination aus zwei Snapshots beschrieben werden oder als ein Snapshot, welcher durch eine zweite Abbildung jeder Datei-Revision erweitert wurde. Ebenso wie Snapshots werden sie als unabhängige Objekte gespeichert und sind aus demselben, im Abschnitt über Snapshots beschriebenen, Grund robuster, stabiler und zuverlässiger als zwei Tags.

Warum sind Change Sets besonders vorteilhaft für verteilte Softwarentwicklung?

Die vorhergehenden Abschnitte veranschaulichen, wie wichtig Snapshots und Change Sets generell für Change Management auf der Basis von Referenzkonfigurationen sind. Der folgende Abschnitt wird aufzeigen, wieviel größer noch der Nutzen von Change Sets in Szenarien örtlich verteilter Softwareentwicklung ist.

Die meisten Modelle zur Verteilung von Versionskontroll-Repositorien verwenden zugeordnete Entwicklungslinien (LODs, branches), um Konflikte bei der Durchführung von Änderungen in den lokalen Datenbankkopien zu vermeiden. In dieser Hinsicht unterscheidet sich DCVS z. B. nicht von Rational ClearCase (TM). Das bedeutet für die Entwickler, dass sie nur Änderungen an den lokal kontrollierten Entwicklungszweigen einchecken können. Eine besondere Untermenge dieser lokal kontrollierten Entwicklungszweige sind gewöhnlich lokal angelegte Zweige. Das bedeutet, dass es immer möglich ist, eine Menge von Änderungen auf einen neuen im Vorübergehen erstellten Entwicklungszweig anzuwenden und einzuchecken. Es ist jedoch nicht immer möglich, Änderungen an anderen Entwicklungslinien durchzuführen (aufgrund administrativer Einschränkungen oder Einschränkungen der Netzwerk-Bandbreite/Effizienz).

Wenn Teams an verschiedenen Standorten nicht in der Lage sind, Änderungen an allen Entwicklungszweigen einzuchecken, scheinen Entwicklungszweige nicht das geeignete Modell für die direkte Implementierung von Produkt- oder kundenspezifischen Entwicklungslinien zu sein. Aus der Sicht des Configuration Managements mag es wesentlich effektiver sein, Entwicklungslinien auf eine Menge von Entwicklungszweigen im Repositorium abzubilden, oder noch besser auf eine Menge von Change Sets. Das ist genau der Zweck von Snapshots und Change Sets in DCVS: sie sind ein Hilfsmittel auf hoher Abstraktionsebene, um Entwicklungslinien und Referenzkonfigurationen in verteilten Entwicklungsszenarien zu gestalten. Jede einzelne Änderung kann im Repositorium auf einen lokalen Entwicklungszweig angewendet und eingecheckt werden. Zugleich wird ein einmaliges change set erstellt, welches auf viele andere Referenzkonfigurationen angewendet und in jede beliebige andere Entwicklungslinie eingefügt werden kann. Um die Implementierung solcher CM-Prozesse zu erleichtern, wurden Snapshots und Change Sets als unabhängige, eindeutig benannte und zuverlässige Objekte zur DCVS Funktionalität hinzugefügt.

Zusammenfassung


dcvs{at}elego.de