Toolmentor: Versionssteuerung mit Rational Rose RealTime und Rational ClearCase einrichten
Dieser Toolmentor beschreibt, wie Sie mit Rational Rose RealTime und Rational ClearCase eine Versionssteuerung einrichten.
Tool: Rational Rose RealTime
Beziehungen
Hauptbeschreibung

Überblick

Rational ClearCase verwendet ein Sichtmodell, das mit einem virtuellen Dateisystem kombiniert ist, in dem Sie die Zusammenstellung (Lineup) von Dateiversionen angeben, mit der Sie arbeiten möchten. Rational Rose RealTime sieht diese Dateien anschließend in der aktuellen Sicht so, als wären sie in einem regulären Dateisystem (und nicht ClearCase) gespeichert. Rose RealTime gibt die Dateien an, aus denen sich das Modell zusammensetzt, und ClearCase stellt die Versionen der Dateien bereit, die durch die Konfigurationsspezifikation der Sicht bestimmt werden.

Symbol für Buch Ausführliche Informationen zur Verwendung von Rose RealTime mit ClearCase finden Sie im Dokument Guide to Team Development, Rational Rose RealTime.

Vor der Verwendung von ClearCase müssen Sie Ihre Workstation und alle Workstations, auf denen ClearCase verwendet wird, konfigurieren.

Voraussetzung: ClearCase konfigurieren

Allgemeine Empfehlungen

Wenn Sie mit Microsoft Windows NT arbeiten, greifen Sie nicht über den MVFS-Mount-Punkt oder das Laufwerk M: auf Sichten zu. Hängen Sie stattdessen die Laufwerke explizit an (z. B. X:, Y: oder Z:), um auf die Sichten zuzugreifen. Dies verbessert das "Wink-in" und beseitigt Abhängigkeiten von Sichtnamen.

UCM Integration

Wenn Sie in einer UCM-VOB arbeiten, können Sie mit den Tools von UCM Integration Aktivitäten Überarbeitungen zuordnen. Außerdem können Sie in Rose RealTime die Operationen "Rebase" und "Deliver" ausführen und den Project Explorer starten.

Statische Sichten

Mit ClearCase können Sie in Rose RealTime die Aktualisierung einer statischen Sicht einleiten. Die statische Sicht enthält die Verzeichnisstruktur von Quellendateien.

Die Verwendung statischer Sichten bietet sich an, wenn eine der folgenden Bedingungen vorliegt:

  • Ihr Computer unterstützt keine dynamischen Sichten.
  • Sie möchten die Build-Leistung optimieren, um native Builds schneller erstellen zu können.
  • Sie möchten Quellendateien unter ClearCase-Steuerung bearbeiten, wenn Sie vom Netz mit den VOBs getrennt sind oder nur vorübergehend mit dem Netz verbunden sind.
  • Sie möchten von einem Computer auf eine Sicht zugreifen, der kein ClearCase-Host ist.
  • Ihr Projekt verwendet keine ClearCase-Build-Prüfung und -Build-Vermeidung.
Konfiguration der Rational-ClearCase-Workstation

Auf allen Workstations, die auf eine VOB oder Sicht zugreifen, muss ClearCase konfiguriert werden. Bei Windows NT/2000 betrifft dies alle Workstation, die für die Entwicklung verwendet werden, und bei UNIX alle Maschinen, die Server für Sichten sind.

Außerdem müssen alle Maschinen, die als Server für die von Rose RealTime verwendeten ClearCase-Sichten auftreten, für ClearCase konfiguriert werden. Wenn Sie ClearCase MultiSite verwenden, müssen Sie diese Arbeiten an allen Standorten ausführen, an denen VOBs, die die Rose-Elemente enthalten, repliziert werden. Sie können die als Server für Sichten zu verwendenden Maschinen bestimmen, indem Sie in einem Befehlsfenster Folgendes eingeben:

 cleartool lsview

Der zweite Eintrag in jeder Ausgabezeile gibt den Namen der Maschine an, auf der Server für Sichten ausgeführt wird. Sie sehen beispielsweise folgende Zeile in der Ausgabe des Befehls lsview:

 meinesicht meinemaschinevwsmeinesicht.vws

In diesem Fall ist "meinemaschine" der Name der Maschine, auf der der Server für die Sicht meinesicht ausgeführt wird.

Symbol für Buch Ausführliche Informationen erhalten Sie bei Ihrem ClearCase-Administrator oder in den Informationen zu den Quellcodeverwaltungstools in der Veröffentlichung Guide to Team Development, Rational Rose RealTime.

Erstkonfiguration

Die folgenden Schritte sind nur auszuführen, wenn Sie ein Modell bearbeiten, das bereits unter Quellcodeverwaltung in einer VOB steht. Weitere Informationen finden Sie in den Abschnitten zur Quellcodeverwaltung in der Veröffentlichung Guide to Team Development, Rational Rose RealTime.

  1. Erstellen Sie die Integratorsicht so, dass die Konfigurationsspezifikation wie folgt angezeigt wird:
 
element * CHECKEDOUT
element * /main/LATEST
  1. Erstellen Sie Projektbezeichnungen, um verschiedene Zusammenstellungen zu definieren. Beispiele für wichtige Bezeichnungen sind:
  • TC_BASELINE_0 - Darstellung des Anfangszustands des Projekts
  • TC_BUILDFILES - Elementversionen angeben, die in den nächsten automatisierten Build aufgenommen werden sollen
  • TC_LATEST_STABLE - Identifikation der letzten stabilen Zusammenstellung im Integrationszweig
  1. Erstellen Sie die Anfangszusammenstellung und wenden Sie die Bezeichnung auf die VOB an. Im Folgenden sehen Sie ein Beispiel für eine Anfangszusammenstellung:
 
[x:dev]cleartool mklabel -recurse TC_BASELINE_0 dev
  1. Erstellen Sie die Vorlage für die Entwicklersicht, um sicherzustellen, dass alle Konfigurationsspezifikationen von einer gemeinsamen Basis abgeleitet werden. Damit sorgen Sie für einen konsistenten und kontrollierten Zugriff auf das Modell und vereinfachen die Verwendung von Zusammenstellungen und privaten Zweigen.

    Entwickler führen primär zwei Aktivitäten aus: Anzeigen und Entwickeln. Für jede Aktivität ist eine andere Konfigurationsspezifikation erforderlich.

Symbol für Buch Informationen zu Vorlagenregeln finden Sie in den Abschnitten zur Erstkonfiguration in der Veröffentlichung Guide to Team Development, Rational Rose RealTime.

Toolschritte

Führen Sie die folgenden Schritte aus, um ClearCase in Rose RealTime zu verwenden:

  1. Erforderliche Modellelemente als Einheiten steuern
  2. Lokalen Arbeitsbereich erstellen
  3. Modell im Arbeitsbereich speichern
  4. Optionen für die Quellcodeverwaltung im Arbeitsbereich konfigurieren
  5. Modell zur Quellcodeverwaltung hinzufügen
  6. Standardarbeitsbereich für alle Projektmitarbeiter verfügbar machen
  7. Sichtvorlagen verwenden
  8. ClearCase-Entitäten
  9. Builds automatisieren
  10. Entwicklerprozess
  11. Integrationsprozess

1. Erforderliche Modellelemente als Einheiten steuern

Legen Sie die erforderliche Granularität für Ihr Projekt und die Teamumgebung im aktuellen Stadium der Entwicklung fest. Stimmen Sie sich dabei mit dem Architekten für das Projekt ab.

2. Lokalen Arbeitsbereich erstellen

Sie können einen lokalen Arbeitsbereich erstellen, in dem Sie Modelle in ClearCase speichern. Jeder Entwickler, der auf Rose-RealTime-Dateien in einer VOB zugreift, muss eine eigene Sicht verwenden.

3. Modell im Arbeitsbereich speichern

Bevor Sie das Modell unter Quellcodeverwaltung stellen, müssen Sie es im lokalen Arbeitsbereich speichern. Speichern Sie das Modell in dem Verzeichnis, das Sie dem Repository für die Quellcodeverwaltung zugeordnet haben.

4. Optionen für die Quellcodeverwaltung im Arbeitsbereich konfigurieren

Legen Sie zum Aktivieren der Quellcodeverwaltung die Einstellungen fest, die in den Abschnitten über die Grundlagen der Quellcodeverwaltung in der Veröffentlichung Guide to Team Development, Rational Rose RealTime beschrieben sind.

5. Modell zur Quellcodeverwaltung hinzufügen

Die einfachste Möglichkeit, alle gültigen Einheiten zur Quellcodeverwaltung hinzuzufügen, ist die Verwendung des Tools Submit All Changes to Source Control. Weitere Informationen hierzu finden Sie in den Abschnitten zur Administration der Quellcodeverwaltung in der Veröffentlichung Guide to Team Development, Rational Rose RealTime.

6. Standardarbeitsbereich für alle Projektmitarbeiter verfügbar machen

Die Arbeitsbereichsdatei (.rtwks) enthält Informationen, die für alle Benutzer, die am Projekt arbeiten, gleich sind. Einstellungen im Arbeitsbereich ändern sich nur selten, wenn überhaupt, nachdem sie konfiguriert wurden. Alle Entwickler in einem Projekt müssen identische Kopien der Arbeitsbereichsdatei verwenden. Aus diesem Grund sollten Sie die Datei unter Quellcodeverwaltung stellen, damit eine fixe Version für alle Projektbenutzer verfügbar ist. Rational Rose RealTime bietet keine explizite Unterstützung für das Ein- und Auschecken dieser Datei an.

Nachdem der Quellcodeverwaltungsmanager das Modell zur Quellcodeverwaltung hinzugefügt hat, muss der Arbeitsbereich manuell mit dem Tool für Quellcodeverwaltung hinzugefügt werden. Andere Benutzer müssen den Arbeitsbereich dann im Rahmen der ersten Aktualisierung ihres lokalen Arbeitsbereichs abrufen. Damit wird sichergestellt, dass alle Teammitglieder dieselben Einstellungen für die Quellcodeverwaltung des Projekts verwenden.

7. Sichtvorlagen verwenden

Sichtvorlagen werden verwendet, um sicherzustellen, dass Entwickler eine gemeinsame Basis für die Konfigurationsspezifikation ihrer Sicht verwenden, und vereinfachen die Arbeit an privaten Zweigen. Eine Sichtvorlage gibt den zu bearbeitenden Integrationszweig an, listet bezeichnete Prüfpunkte auf, die als Basis für einen privaten Zweig verwendet werden können, und enthält eine Konfigurationsspezifikationsvorlage, die mit weiteren Regeln für die Konfigurationsspezifikation gefüllt werden kann.

Symbol für Buch Weitere Einzelheiten finden Sie in den Informationen zur parallelen Entwicklung mit Rational ClearCase in der Veröffentlichung Guide to Team Development, Rational Rose RealTime.

8. ClearCase-Entitäten

Mit Sichten, Sichtvorlagen und Bezeichnungen können die Rational-ClearCase-Features vereinfacht werden. Weitere Einzelheiten finden Sie in den Informationen zur parallelen Entwicklung mit ClearCase in der Veröffentlichung Guide to Team Development, Rational Rose RealTime.

9. Builds automatisieren

Damit Sie die Versionen der Dateien, die in den Build aufgenommen werden, selektiv bestimmen können, wählt das Erstellungsprogramm (Builder) alle Versionen aus, die die Build-Bezeichnung TC_BUILDFILES haben. Auf diese Weise können die exakten Versionen, die in den Build aufgenommen werden, flexibel geändert werden. Wenn die aktuelle Version einer Datei beispielsweise Code enthält, der nicht kompiliert werden kann, kann die vorherige Version entsprechend bezeichnet werden:

Der Build-Prozess setzt sich aus den folgenden Schritten zusammen:

  1. Build-Dateien bezeichnen.
  2. Build ausführen.
  3. Nach erfolgreichem Abschluss des Build:
    • Neue Bezeichnung für Zusammenstellung erstellen und auf die Dateiversionen des Build anwenden.
    • TC_LATEST_STABLE auf die Dateiversionen im Build anwenden.
    • Neue Zusammenstellung für die Entwickler verfügbar machen.

10. Entwicklerprozess

Jede Entwicklungsaktivitäten wird von einem einzelnen Entwickler in einem privaten Zweig für genau diese Aktivität ausgeführt. Auch hier benötigt jeder Entwickler eine eigene Sicht. Die Sicht basiert auf einem Verzweigungspunkt in dem Integrationszweig, der die Build-Bezeichnung trägt.

Es muss ein eindeutiger Zweigname gewählt werden, der die ausgeführte Arbeit kennzeichnet, z. B.:

 paulz_timing

Die Konfigurationsspezifikationsregeln der Sicht sind so festgelegt, das Dateien aus dem Verzweigungspunkt automatisch ausgecheckt und und im privaten Zweig abgelegt werden. Auch die neuen Elemente, die während der Entwicklungsaktivität erstellt werden, werden sofort im privaten Zweig abgelegt.

Da der Zweig vor anderen Entwicklern verdeckt bleibt, kann der Benutzer inkrementelle Änderungen, die er in seinem Zweig vornimmt, einchecken. Wenn der Entwickler der Meinung ist, dass seine Änderungen abgeschlossen sind und integriert werden können, informiert er den Integrator darüber, dass alle Änderungen in seinem privaten Bereich für die Integration bereit sind.

Indem die privaten Zweige der Entwickler auf Bezeichnungen basieren, die den in automatisierten Builds verwendeten Versionen entsprechen, kann jeder Entwickler einen Großteil der Build-Ergebnisse in Form abgeleiteter Objekte (Wink-In-Methode) wiederverwenden. Auf diese Weise verringert sich der Build-Aufwand bei den einzelnen Entwicklern, wenn Änderungen vorgenommen werden.

11. Integrationsprozess

Jede Entwicklungsaktivität muss irgendwann in den Integrationszweig eingeführt werden. ClearCase stellt hierfür mehrere Tools zur Verfügung. Mit dem Tool cleartool findmerge können alle Änderungen aus einem Zweig mit einem anderen Zweig zusammengeführt werden. Aus der Integratorsicht kann die folgende Befehlssyntax verwendet werden:

 cleartool findmerge dev -all -fversion .../paulz_timing/LATEST -merge

Für dieselbe Aufgabe können Benutzer von Windows NT den ClearCase Merge Manager verwenden.

Beide Methoden führen die Verzeichnisversionen zusammen und verwenden Rose RealTime Model Integrator, um Änderungen in Modelldateien zusammenzuführen. Nach der Zusammenführung muss der Integrator das Modell in Rose RealTime laden und sicherstellen, dass keine Fehler bei der Zusammenführung aufgetreten sind. Wenn das Modell fehlerfrei geladen wird, müssen die Änderungen geprüft werden. Verwenden Sie dazu die Menüpunkte Tools -> Source Control -> Submit All Changes to Source Control.

Für die Integration mehrerer Entwicklungsaktivitäten müssen Sie die folgenden Schritte ausführen:

  1. Laden Sie das Modell in der Sicht des Integrators.
  2. Führen Sie die Zusammenführung wie beschrieben durch.
  3. Wählen Sie die Menüpunkte Tools -> Source Control -> Synchronize Entire Model aus. Daraufhin werden alle Dateien erneut geladen, die sich bei der Zusammenführung geändert haben.
  4. Stellen Sie sicher, dass die Änderungen gültig sind.
  5. Wählen Sie die Optionen Tools -> Source Control -> Submit All Changes to Source Control aus, um die Änderungen zu akzeptieren und sie in die Quellcodeverwaltung einzuchecken.
  6. Wiederholen Sie die Schritte 2 bis 5 für jede Aktivität, die integriert werden muss.