ALM ohne UCM verwenden

Sie können die Satztypen "ALMBaseline" und "BTBuild" ohne UCM verwenden.

Durch Verwendung von ClearCase UCM können die ALMBaseline- und BTBuild-Datensätze automatisch Aktivitäten ermitteln, die in Builds enthalten sind. Sie können die Satztypen "ALMBaseline" und "BTBuild" jedoch auch für das Änderungsmanagement und für Aktivitäten mit Nicht-UCM-Systemen verwenden. Der Begriff Nicht-UCM bezieht sich auf alle Systeme, die eine andere Konfiguration oder Asset-Managementlösung als UCM verwenden.

Wenn Sie einen ALMBaseline-Datensatz erstellen, können Sie Abfragen verwenden, um die Liste der Aktivitäten anzugeben, und dann die Aktivitäten manuell dem ALMBaseline-Datensatz hinzufügen.

Anmerkung: Wenn Sie eine ALM-Aktivität zu einem ALMBaseline-Datensatz hinzufügen, muss die ALMActivity-ID gültig sein, oder die ALM-Referenzkonfiguration wird nicht mit der hinzugefügten Aktivität aktualisiert.

Referenzkonfigurationen und Builds erstellen

Der ALMBaseline-Datensatz wird verwendet, um Daten in einer Referenzkonfiguration zu speichern. In Nicht-UCM-Systemen kann das ein Kennsatz sein, der in einem Repository platziert wird. Dieser Kennsatz muss für die gesamte Lebensdauer des Projekts statisch bleiben. Er darf nicht versetzt oder erneut angewendet werden.

Der eindeutige Schlüssel des ALMBaseline-Datensatzes ist eine Kombination der Felder "BaselineName" und "PvobOrLocation". In UCM-Systemen speichert die PVOB die Prozessinformationen für ein UCM-Projekt. In Nicht-UCM-Systemen ist "PvobOrLocation" die Position, die eine Komponente oder ein Projektbereich sein kann, die den Kennsatz eindeutig macht. Wenn Sie z. B. zwei Komponenten Gui und Core haben, die separat erstellt werden, die Kennsätze der nächtlich erstellten Builds (z. B. NightlyBuild_2008Jan15) jedoch generisch sind, könnten Sie Datensätze für Referenzkonfiguration mit den Werten "BaselineName" und "PvobOrLocation" erstellen:
BaselineName=NightlyBuild_2008Jan15  Location=Gui 
BaselineName=NightlyBuild_2008Jan15  Location=Core

Wenn Sie einen Datensatz für eine Referenzkonfiguration haben, können ein oder mehrere Builds von ihm abgeleitet werden. Wenn Sie z. B. einen Build für drei Plattformen erstellen, bräuchten Sie für einen Datensatz für Referenzkonfiguration drei Build-Datensätze.

Beispiel

Libraries Ltd. ist ein Produzent von Softwarebibliotheken. Das Unternehmen erstellt JAR-Dateien und gibt gruppierte Dateien dieses Typs als Archive heraus. Das CM-System (Change Management) ist dateibasiert. Jede JAR-Datei kann als Komponente definiert werden. Das Archiv, das eine Gruppierung von JAR-Dateien enthält, kann als Angebot definiert werden. Die JAR-Dateien des Teams "Komponente" werden in Verzeichnissen gespeichert (z. B. "Jar\Gui_01.jar", "Jar\Gui_02.jar", ...). Tester, die für die Komponentenebene zuständig sind, testen jede JAR-Datei auf Komponentenebene. Es steht nicht notwendigerweise fest, welchem (Produkt-)Angebot die Komponenten zugeordnet werden. Die Angebote werden vom Releaseentwickler (oder Build-Ersteller), der die Archivdateien mit den Komponenten erstellt hat, erstellt. Angebote werden in Verzeichnissen gespeichert (z. B. in "Products\Sparkle_01" und "Products\Dazzle_01"). Tester, die für die Produktebene zuständig sind, testen die Archivdateien und alle enthaltenen JAR-Dateien auf Produktebene.

Der gesamte Arbeitsprozess umfasst folgende Schritte:
  • Ein ALM-Projekt (ALMProject) erstellen (z. B. mit dem Namen "nonUCM_GuiJar").
  • Eine ALM-Anforderung (ALMRequest) und eine ALMTask für die Anforderung erstellen.
  • Eine ALM-Aktivität (ALMActivity) für die Entwicklungsarbeit erstellen (z. B. mit der Aktivitäts-ID = ALM00000486).
  • Eine ALM-Aktivität abschließen. Der Entwickler ändert den Code und schließt die Aktivität.
  • Eine ALM-Referenzkonfiguration (ALMBaseline) erstellen. Der Build-Ersteller erstellt die JAR-Datei "GUI_Jar_02.jar" und einen Datensatz für Referenzkonfiguration (GUI_Jar_02), wobei er die abgeschlossenen Aktivitäten hinzufügt. Der Build-Ersteller kann eine Abfrage ausführen (basierend auf Entwicklerkategorie und Release) und dann im Raster mit der Ergebnisliste auf eine Task klicken und das Feld mit den Aktivitäten anzeigen. Nachdem die Referenzkonfiguration erstellt ist, können ein oder mehrere Builds erstellt werden.
  • Einen BTBuild aus der Referenzkonfiguration erstellen. Der Build-Ersteller erstellt einen neuen BTBuild, der das entsprechende ALM-Projekt und die ALM-Referenzkonfiguration referenziert. Auf der Registerkarte "Activities" im BTBuild-Datensatz werden alle Aktivitäten angezeigt, die die ALM-Referenzkonfiguration umfasst. Auf der Registerkarte "ALM" im BTBuild-Datensatz wird die Verbindung zur ALM-Referenzkonfiguration angezeigt.
  • Einen Build testen. Der Tester kann eine ALM-Task anzeigen und feststellen, in welchem Build die neue Funktionaliät gefunden werden kann.

Beim Erstellen einer kombinierten Referenzkonfiguration werden vorhandene Referenzkonfigurationen zum Feld Composed of Baselines in einem neuen Datensatz für Referenzkonfiguration hinzugefügt. Eine Referenzkonfiguration auf Produktebene kann beispielsweise alle Referenzkonfigurationen auf Komponentenebene enthalten.

Im vorliegenden Beispiel enthält das Feld Composed of Baselines den Namen "GUI_Jar_02" der Referenzkonfiguration der Komponente. Der Build-Ersteller kann dann einen neuen BTBuild-Datensatz aus der neuen Referenzkonfiguration "Dazzle_01" erstellen. Dabei handelt es sich um denselben Prozess wie bei der Erstellung des Builds aus der Komponente "Gui". Derselbe ALMTask-Datensatz gibt dem für die Produktebene zuständigen Tester Aufschluss darüber, in welchem Build die neue Funktionalität gefunden werden kann.


Feedback