IBM®
Rational ClearQuest wurden
mehrere Pakete hinzugefügt, die eine Überwachung der Implementierung ermöglichen.
Die folgenden Pakete für die Überwachung der Implementierung wurden
IBM
Rational ClearQuest hinzugefügt:
- Das DeploymentTracking-Paket, das den Freigabeprozess für die Implementierung unterstützt.
- Das TPM-Paket, mit dessen Hilfe Ihr Release der Position eines
IBM Tivoli
Provisioning Manager-Servers zugeordnet werden kann.
Dieses Paket muss nur angewendet werden, wenn Sie eine Integration zwischen
Rational ClearQuest und
Tivoli Provisioning Manager erstellen wollen.
Sie können mit den Funktionen des TPM-Pakets einen URL-Link auf die
Webbenutzerschnittstelle von Tivoli Provisioning
Manager zu Ihrem Implementierungsdatensatz hinzufügen und damit eine einfache
Benutzerschnittstellenintegration zwischen
Rational ClearQuest und
Tivoli Provisioning Manager bereitstellen.
- Das eSignature-Paket, das die obligatorische Verwendung von elektronischen Signaturen bei der Freigabe oder Zurückweisung eines Genehmigungsdatensatzes unterstützt.
- Das AuditTrail-Paket, mit dem Sie überwachen können, wie, wann und von wem die Felder der Genehmigungs- und Implementierungsdatensätze geändert wurden.
- Das Email-Paket, das den Versand von E-Mail-Benachrichtigungen nach der Übergabe, Freigabe oder Zurückweisung einer Genehmigung an die für die Freigabe eines Releases verantwortlichen Benutzer unterstützt.
- Das BuildTracking-Paket, das die Rückverfolgbarkeit zwischen der Build- und der Implementierungsphase ermöglicht.
Satztypen
Mit der Anwendung des DeploymentTracking-Pakets auf das Rational-ClearQuest-Schema werden folgende Satztypen hinzugefügt:
- DTDeployment
Jeder Implementierungsdatensatz stellt eine separate Implementierung dar.
Jeder dieser Implementierungsdatensätze enthält ein Feld, in dem angegeben wird, in welcher Umgebung er implementiert werden kann.
Die Implementierungsdetails werden in der XML-Datei der Implementierungseinheit beschrieben, auf die der Implementierungsdatensatz verweist.
- DTApproval
Dieser Satztyp stellt eine Genehmigung für eine Implementierung dar. Genehmigungen können höchstens auf einen einzigen Implementierungsdatensatz verweisen.
- DTEnvironment
Jede Umgebung stellt eine unterschiedliche Testphase dar. Sie können mehrere Umgebungen für die diversen Testphasen erstellen, die Ihre Software bis zum Release durchlaufen muss. Beispielsweise können Sie Umgebungen für den Einheitentest, Funktionstest, Systemtest und Integrationstest erstellen.
- DTRole
Aufgabenbereiche geben an, welche Benutzer berechtigt sind, eine Implementierung in einer bestimmten Umgebung freizugeben. Rational-ClearQuest-Benutzer können zu mehreren Aufgabenbereichen gehören.
- DTRelease
Jeder Releasedatensatz modelliert ein Release auf Implementierungsebene.
Jedes Release besitzt eine Gruppe von Aufgabenbereichen, die zur Freigabe von Implementierungen berechtigt sind und in UCM-Umgebungen die Modellierung von mehreren UCM-Projekten als Eingabe für eine einzelne Implementierung ermöglichen.
Ein Release besitzt während seiner Laufzeit eine Serie von Implementierungen.
Satztypen des TPM-Pakets
Mit der Anwendung des TPM-Pakets auf das Rational-ClearQuest-Schema werden folgende Satztypen hinzugefügt:
- TPMServer. Jeder TPMServer-Datensatz enthält Basisinformationen zu einem Server von Tivoli Provisioning Manager.
Für jeden Server von Tivoli Provisioning Manager
in Ihrer Umgebung gibt es eine einzige Instanz dieses Satztyps und in der Regel nur einen
einzigen Datensatz.
Wenn ein Release definiert wird, kann es einem TPM-Serverdatensatz zugeordnet werden. Jeder Implementierungsdatensatz mit einem Releasedatensatz, der auf einen TPM-Server verweist, enthält eine URL-Referenz auf die TPM-Webschnittstelle, wodurch eine einfache Benutzerschnittstellenintegration für Implementierungsdatensätze bereitgestellt wird.
- TPMWorkflow. Dieser Datensatz stellt einen TPM-Workflow dar. Dies ist ein Proxy für Informationen in TPM. Dieser Datensatz wird zur Unterstützung der Integration mit
TPM in künftigen Releases hinzugefügt. Workflowdatensätze verweisen auf 0..* Implementierungsdatensätze.
Satztypen des BuildTracking-Pakets
Mit der Anwendung des BuildTracking-Pakets auf das Rational-ClearQuest-Schema werden folgende Satztypen hinzugefügt:
- BTBuild. Mit diesem Satztyp können Sie den Status Ihres Builds überwachen. Sie können überwachen, wann Ihr Build gestartet und beendet wurde, ob er erfolgreich war oder nicht, welchem Release er zugeordnet ist und wo sich Ihr Buildprotokoll befindet.
Statustypen von Implementierungsdatensätzen
Nachstehend finden Sie die Anforderungen zum Festlegen der Statustypen bei der Verwendung von
Rational ClearQuest für Implementierungsdatensätze:
- Sie müssen jedem Statustyp einen Status zuweisen.
- In Ihrem Implementierungsdatensatztyp muss genau eine Statusdefinition der folgenden Statustypen enthalten sein:
- Ready. Dieser Status gibt an, dass das Release für die Implementierung in der aktuellen Umgebung bereit ist.
- Deployed. Dieser Status gibt an, dass das Release in der aktuellen Umgebung implementiert wurde.
- Retired. Dieser Status gibt an, dass das Release in allen erforderlichen Umgebungen implementiert wurde.
- Failed. Dieser Status gibt an, dass in dem implementierten Release Fehler gefunden wurden und dass die Implementierung dieses Release eingestellt wurde.
- Der Pfad für den Statusübergang lautet: Ready->Deployed->Retired.
- Sie können den Anfangsstatus von Implementierungsdatensätzen nicht auf "Retired" oder "Failed" setzen. Der Anfangsstatus sollte stets "Ready" sein.
Statustypen von Genehmigungsdatensätzen
Nachstehend finden Sie die Anforderungen zum Festlegen der Statustypen bei der Verwendung von
Rational ClearQuest für Genehmigungsdatensätze:
- In Ihrem Implementierungsdatensatztyp muss genau eine Statusdefinition der folgenden Statustypen enthalten sein:
- Submitted. Dieser Status gibt an, dass der Genehmigungsdatensatz übergeben wurde.
- Approved. Dieser Status gibt an, dass der Genehmigungsdatensatz freigegeben wurde.
- Rejected. Dieser Status gibt an, dass der Genehmigungsdatensatz zurückgewiesen wurde.
- Der Pfad für den Statusübergang lautet: Submitted >Approved bzw. Submitted > Rejected.
Neben den hier beschriebenen Statustypen und Übergangsmodellen können Sie auch eigene, angepasste Statustypen und Statusübergänge erstellen.
Statustypen von Builddatensätzen
Nachstehend finden Sie die Anforderungen zum Festlegen der Statustypen bei der Verwendung von
Rational ClearQuest für Builddatensätze:
- Submitted. Dieser Status gibt an, dass der Build gestartet wurde.
- Completed. Dieser Status gibt an, dass der Build fehlerfrei abgeschlossen wurde.
- Failed. Dieser Status gibt an, dass der Build fehlgeschlagen ist.
- Retired. Dieser Status gibt an, dass der Builddatensatz nicht mehr relevant ist.
Der
Pfad für den Statusübergang lautet: Submitted > Completed, Submitted > Failed,
Completed > Retired, Failed > Retired.