Wir migrieren eine ziemlich große Codebase von VSS nach Clearcase mit UCM und erwägen, unsere Quelle in einer oder mehreren Komponenten innerhalb eines einzelnen Projekts zu organisieren. Welche bewährten Praktiken sollten wir beachten?
Die Quelle ist in Schichten organisiert (Datenschicht, Business-Schicht, GUI-Schicht). Das Team ist ziemlich klein, Entwickler neigen dazu, eine bestimmte Schicht der Codebasis zu besitzen, und wir erwarten aufgrund paralleler Entwicklungsbemühungen eine beträchtliche Menge an Verzweigungen.
Single gefährlichste Falle:
Sobald eine Komponente definiert ist, können Sie ein Element nicht mehr aus dieser Komponente entfernen (Sie können es kopieren und anderswo neu erstellen, aber Sie verlieren seinen Verlauf)
Die nützlichste Best Practice:
Verstehen Sie gut die Natur einer UCM-Komponente: es geht um Kohärenz .
Eine Komponente ist eine Gruppe von Dateien, die:
Wenn Sie Entwicklungen vornehmen können, ohne eine andere Gruppe von Dateien zu berühren, haben Sie wahrscheinlich zwei Komponenten.
Beispiel für Komponenten:
Das einzige Dokument, das Sie zur Definition von Komponenten führen soll, ist die Applikative Architektur (die die Geschäfts- und Funktionsspezifikationen übernimmt und sie auf Anwendungen projiziert, die dann auf technischer Ebene spezifiziert und implementiert werden).
Wenn all diese Komponenten definiert sind, haben Sie zwei Möglichkeiten, sie zu verwalten:
Systemansatz (jede Komponente ist in einem UCM-Projekt beschreibbar): nützlich für das Starten eines Projekts, aber umständlich mit einem älteren Projekt: Sie müssen nicht jedes Mal eine Baseline erstellen Komponenten einfach, weil 3 Dateien in einer dieser Komponenten geändert hat.
Komponentenansatz : eine oder zwei schreibbare Komponenten, der Rest ist nur als nicht veränderbare Komponente vorhanden. Dies ist ein skalierbarer Ansatz, der es Ihnen ermöglicht, ein Projekt pro zu entwickelnder Komponente zu definieren, wobei eine "feste Konfiguration" (dh "die anderen Basislinien") feste Zustände der nicht modifizierbaren Komponenten darstellt, die Sie zum Kompilieren benötigen modifizierbar, Sie können diese Konfiguration jederzeit ändern, das heißt, Sie können jederzeit die Basislinien der nicht veränderbaren Komponente rebasen.
Sie können beliebig viele Projekte und Streams definieren, sodass Sie den Merge-Workflow einfach visualisieren können / a>.
Denken Sie daran: Ein Stream repräsentiert eine Entwicklungsleistung .
Rufen Sie keinen Stream nach einer Ressource auf (wie VonC_stream ), sondern nach einer Aufgabe oder einer Gruppe von Aufgaben in diesem Stream (wie in APP_LCH_R32_Dev : Entwicklung für die 32. Version meines App Launcher)
Hinweis: UCM sind nur einige Metadaten über ClearCase: Selbst wenn eine Gruppe von Dateien als UCM-Komponente definiert ist, hindert Sie nichts daran, klassische Nicht-UCM-Zweigstellen, Checkouts oder Checkins (in Nicht-UCM) zu erstellen Ansichten).
Besteht die Gefahr, dass zu viele feinkörnige Komponenten oder zu viele Abhängigkeiten zwischen den Komponenten entstehen?
Ja, deshalb ist die anwendungsorientierte Architektur wichtig. Sobald eine Komponente definiert ist, können Sie keine Elemente mehr zwischen diesen Komponenten verschieben.
Ein weiteres Detail über Komponenten ist ihr Layout:
%Vor% Eine Wurzelkomponente befindet sich immer auf der ersten Ebene unter einem Vob.
Sie können auch eine Komponente als all Vob definieren, aber ich würde es nicht empfehlen (das Hinzufügen einer Vob belastet Ihren Vob-Server. Das Hinzufügen eines Verzeichnisses innerhalb einer vorhandenen Vob kostet nichts)
Das bedeutet, wenn Sie einige technische Bibliotheken als Komponenten definieren, können Sie nicht wie folgt vorgehen:
%Vor%muss aber tun:
%Vor%Letzte Warnung: Abhängigkeit (das wahre Kennzeichen eines Konfigurations -Managementsystems)
Einer der Hauptvorteile von UCM (oder so dachte ich damals - 2003 -) ist die Abhängigkeit.
Wenn A von B abhängt und ich A in mein Projekt lege, wird B automatisch in dasselbe Projekt eingefügt.
Magie.
Aber es ist kaputt.
Hier benötigen Sie B2 , um mit A fortzufahren, aber A beginnt mit A1 basierend auf B1 : B2 überschreibt B1 . Sobald Sie eine Basislinie auf A ( A2 ) setzen, ist es vorbei. Sie können B nicht mehr ändern. A parasite baseline (genannt A2 !?) wird aufgrund der Überlappung auf die (nicht veränderbare!) Komponente B gesetzt.
Hier haben Sie die rootless Komponenten ADep und BDep (eine wurzellose Komponente ist eine spezielle Komponente, die andere rootlose oder rootbasierte Komponenten aggregiert)
Sie haben immer noch eine Überschreibung, aber dieses Mal zwischen rootless Komponenten.
Das wird immer noch eine Parasitengrundlinie bilden (auf BDep , genannt A2 ), aber zumindest können Sie später BDep2 auf andere Basislinien umbasieren ( BDep3 , BDep4 ...)
Mehr dazu Inkohärenzen und Inkonsistenzen von ClearCase UCM , mit Rationale Gegenargumente hier (und gleich danach ihr Beitrag, der Beweis, dass ihre Argumente nicht sehr gut sind, um es gelinde auszudrücken).
Lesen Sie auch So nutzen Sie die Funktionen von Clearcase
Tags und Links clearcase