Borland® StarTeam® 2006 - Borland Technical Publications

Ansichten, die die iterative Entwicklung unterstützen
Dieser Abschnitt beschreibt unterschiedliche Szenarios zur iterativen Entwicklung und enthält Vorschläge, wie
Ansichten zur Unterstützung dieser Szenarios verwendet werden können. Für jedes Szenario gelten die folgenden
Voraussetzungen:
♦ Die Hauptansicht wird für die Produktions-Baseline verwendet.
♦ Das Projekt ist so konfiguriert, dass es Prozesselemente erzwingt, d. h, es wird für jede "Arbeitseinheit" eine
Änderungsanforderung, ein Task oder eine Anforderung erstellt. Eine "Einheit" ist die Menge der
zusammengehörigen Dateien, die eingecheckt werden.
♦ Für Routine-Builds werden Ansichts-Labels (und ggf. Heraufstufungsstatuswerte) verwendet. Dies bedeutet
beispielsweise, dass ein nächtliches Ansichts-Label dazu verwendet wird, von dem ein Build generiert und
anschließend getestet wird. Ansichts-Labels, Heraufstufungsstatuswerte und Prozesselemente werden
verwendet, um Aktualisierungsschritte in einer Ansicht zu unterstützen.
Szenario 1: Kleine Entwicklerteams
Für kleine Entwicklerteams und/oder kurzfristige Arbeitsaktivitäten können Entwickler die Hauptansicht direkt
verwenden. Untergeordnete Ansichten werden erstellt, wenn ein Versionsmeilenstein erreicht und anschließend für
die Versionswartung verwendet wird. Das Szenario eines kleinen Entwicklerteams ist im Folgenden dargestellt.
Die Aktivitäten für dieses Entwicklungsszenario sind im Folgenden zusammengefasst:
♦ Wenn eine Änderung ("mod") erforderlich ist, checkt ein Entwickler die erforderlichen Dateien aus der
Hauptansicht aus und sperrt alle zu ändernden Dateien. Wenn der Entwickler Änderungen an den lokalen
Arbeitsdateien vorgenommen und ggf. neue erforderliche Dateien erstellt hat, führt er ein umfassendes Unit-
Testing aus, um sicherzustellen, dass Dateien für andere Entwickler freigegeben werden können.
Anschließend checkt der Entwickler die neuen und geänderten Dateien beim Entsperren ein, wobei er ein
Prozesselement verwendet, um die Revisionen mit der entsprechenden Änderungsanforderung, dem Task
oder der Anforderung zu verknüpfen.
♦ Ein automatisiertes Skript (nicht abgebildet) wird regelmäßig ausgeführt und erstellt ein neues Ansichts-Label.
Über dieses Label werden Auscheckvorgänge vorgenommen, um Builds zu erzeugen und Test-Suites zu
produzieren.
♦ Wenn der Hauptentwicklungsstrom einen Versionsmeilenstein erreicht (beispielsweise nach der Code-
Fertigstellung), wird eine Ansicht des Typs "Alle verzweigen" aus einem bestimmten Ansichts-Label (z. B.
"Build 5.3.142 Freigabekandidat") oder einem Heraufstufungsstatus (z. B. "Integrationstest") erstellt. Diese
Ansicht wird als Unterstützungsansicht verwendet, da es sich bei den an ihr vorgenommenen Änderungen
321