Ü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.
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.
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.
-
Erstellen Sie die Integratorsicht so, dass die Konfigurationsspezifikation wie folgt angezeigt wird:
element * CHECKEDOUT
element * /main/LATEST
-
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
-
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
-
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.
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:
-
Erforderliche Modellelemente als Einheiten
steuern
-
Lokalen Arbeitsbereich erstellen
-
Modell im Arbeitsbereich speichern
-
Optionen für die Quellcodeverwaltung im
Arbeitsbereich konfigurieren
-
Modell zur Quellcodeverwaltung hinzufügen
-
Standardarbeitsbereich für alle
Projektmitarbeiter verfügbar machen
-
Sichtvorlagen verwenden
-
ClearCase-Entitäten
-
Builds automatisieren
-
Entwicklerprozess
-
Integrationsprozess
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.
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.
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.
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.
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.
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.
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.
Weitere Einzelheiten finden
Sie in den Informationen zur parallelen Entwicklung mit Rational ClearCase in der Veröffentlichung Guide to Team
Development, Rational Rose RealTime.
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.
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:
-
Build-Dateien bezeichnen.
-
Build ausführen.
-
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.
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.
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:
-
Laden Sie das Modell in der Sicht des Integrators.
-
Führen Sie die Zusammenführung wie beschrieben durch.
-
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.
-
Stellen Sie sicher, dass die Änderungen gültig sind.
-
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.
-
Wiederholen Sie die Schritte 2 bis 5 für jede Aktivität, die integriert werden muss.
|