Borland® StarTeam® 2006 - Borland Technical Publications
Borland® StarTeam® 2006 - Borland Technical Publications 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 224
ausschließlich um Behebungen kritischer Probleme handelt. Die primäre Entwicklung findet weiterhin in der Hauptansicht statt. ♦ Wenn eine an der Unterstützungsansicht vorgenommene Änderung auch auf andere (zukünftige) Versionen angewendet werden soll, wird sie ebenfalls mit der Hauptansicht zusammengeführt (nicht abgebildet). Das Vergleichen/Zusammenführen von Ansichten ist hierfür in der Regel nicht erforderlich, da die Arbeit an der Hauptansicht weitergeführt wird, während die Unterstützungsansicht im Hinblick auf eine bestimmte Version relativ konstant bleibt. Stattdessen werden einzelne Dateien mit der Versionsansicht zusammengeführt. ♦ Dieser Prozess wird für alle Hauptversionen wiederholt, wobei mit der Zeit mehrere Unterstützungsansichten erstellt werden. Es kann vorkommen, dass die Unterstützungsansicht selbst in eine weitere Ansicht aufgeteilt wird, z. B. für die Unterstützung von Service Packs. Dies sollte jedoch nur selten der Fall sein. Wenn viele Service Pack-Support- Ansichten erstellt werden und so das Zusammenführen zahlreicher einzelner Dateien erforderlich machen, bietet sich möglicherweise eher ein anderes Szenario zur iterativen Entwicklung an. Szenario 2: Große Entwicklerteams Wenn in Ihrer Organisation langfristigere Arbeitsaktivitäten anfallen, die in der Regel nacheinander ausgeführt werden, sollten Änderungen aufgrund von Phasen zeitweiliger Instabilität nicht direkt an der Hauptansicht vorgenommen werden. Die einzelnen Projekte sollen stattdessen zunächst einen stabilen Punkt erreichen (z. B. Unit-Tests oder Integrationstests), bevor sie in der Hauptansicht freigegeben werden. Um dieses Modell zu unterstützen, können Sie beim Start einer neuen Arbeitsaktivität eine Aktivitätsansicht erstellen. (Der Begriff "Aktivität" wird verwendet, um Verwechslungen mit dem Begriff "Projekt" zu vermeiden, obwohl "Projektansicht" ebenfalls ein passender Name ist.) Eine Aktivitätsansicht ist eine Variantenansicht des Typs "Alle verzeigen", deren Elementkonfigurationen auf "Unverankert" gesetzt sind. Die in der übergeordneten Ansicht vorgenommenen Änderungen wirken sich daher auch auf die untergeordnete Ansicht aus. Als Variantenansicht verzweigt die Aktivitätsansicht alle Elemente, wenn diese über diese Ansicht geändert werden. Wenn die Aktivität einen entsprechenden Meilenstein erreicht (z. B. den Integrationstest besteht), wird sie in der Hauptansicht freigegeben, indem die untergeordnete Ansicht mit der übergeordneten Ansicht verglichen und mit ihr zusammengeführt wird. Die Aktivitätsansicht wird anschließend inaktiv und kann schließlich gelöscht werden. Bei diesem Modell werden Änderungen für neue Hauptaktivitäten aus der Hauptansicht isoliert. Das Szenario der Aktivitätsansicht ist im Folgenden abgebildet. 225
- Seite 173 und 174: Diagrammlegende Die Diagrammlegende
- Seite 175 und 176: Der Layoutbereich des Formulars Der
- Seite 177 und 178: Ansichten vergleichen/zusammenführ
- Seite 179 und 180: ♦ Die Testperspektive enthält di
- Seite 181 und 182: Verwandte Konzepte Übersicht über
- Seite 183 und 184: Die Hauptversion von File Compare/M
- Seite 185 und 186: Ordner vergleichen/zusammenführen
- Seite 187 und 188: FCM-Menüs und -Symbolleiste Die ei
- Seite 189 und 190: Toolbar-Dienstprogramm Dieses Thema
- Seite 191 und 192: StarTeam Web Edition Dieser Abschni
- Seite 193 und 194: Komponentenregister Die Komponenten
- Seite 195 und 196: StarTeam Layout Designer-Benutzerob
- Seite 197 und 198: Borland Search Dieses Thema beschre
- Seite 199 und 200: Workflow Designer Dieses Thema besc
- Seite 201 und 202: Widerrufen Stellt eine zuvor rückg
- Seite 203 und 204: Konzepte 203
- Seite 205 und 206: Allgemeines Dieser Abschnitt enthä
- Seite 207 und 208: Übersicht über Projekte In einem
- Seite 209 und 210: Beispiel 1: Eine einfache Client-/S
- Seite 211 und 212: Projektübergreifende Dateiabhängi
- Seite 213 und 214: Projektübergreifende Aktivitäten
- Seite 215 und 216: Übersicht zu Ansichten Beim Erstel
- Seite 217 und 218: "Verzweigen bei Änderung" für den
- Seite 219 und 220: Varianzansicht Schreibgeschützte R
- Seite 221 und 222: Ansichtstyp Referenz im Gegensatz z
- Seite 223: enötigen nicht Tausende Ansichten.
- Seite 227 und 228: Die Schlüsselpunkte dieses Szenari
- Seite 229 und 230: Übersicht über Ordner und Pfade I
- Seite 231 und 232: Verwandte Konzepte Übersicht über
- Seite 233 und 234: ♦ Manuell zeigt an, dass die Auto
- Seite 235 und 236: Allgemeines zu Standardordnern und
- Seite 237 und 238: Übersicht über Ein- und Auscheckv
- Seite 239 und 240: Konsistente Ein- und Auscheckvorgä
- Seite 241 und 242: Auscheckvorgänge von Dateien über
- Seite 243 und 244: einigen nicht übereinstimmenden Da
- Seite 245 und 246: Übersicht über das Vergleichen/Zu
- Seite 247 und 248: Übersicht über das Vergleichen/Zu
- Seite 249 und 250: Festschreibungsphase In der Festsch
- Seite 251 und 252: Typen und Regeln für das Vergleich
- Seite 253 und 254: Szenarios für das Zusammenführen
- Seite 255 und 256: 6 Es wird eine Replizierung ausgef
- Seite 257 und 258: andere Aktion setzen, die ausgefüh
- Seite 259 und 260: Schnellzugriff auf Projekte und Ele
- Seite 261 und 262: Sicherheit StarTeam bietet Sicherhe
- Seite 263 und 264: Die wichtigsten Knoten, für die Re
- Seite 265 und 266: Gruppenberechtigungen für Objekte
- Seite 267 und 268: ♦ Statuswerte in einer Ansicht ne
- Seite 269 und 270: Verwendung von Passwörtern Passwö
- Seite 271 und 272: Server-Zeitlimit-Optionen Sie könn
- Seite 273 und 274: Übersicht über Benutzer- und Grup
Ansichten, die die iterative Entwicklung unterstützen<br />
Dieser Abschnitt beschreibt unterschiedliche Szenarios zur iterativen Entwicklung und enthält Vorschläge, wie<br />
Ansichten zur Unterstützung dieser Szenarios verwendet werden können. Für jedes Szenario gelten die folgenden<br />
Voraussetzungen:<br />
♦ Die Hauptansicht wird für die Produktions-Baseline verwendet.<br />
♦ Das Projekt ist so konfiguriert, dass es Prozesselemente erzwingt, d. h, es wird für jede "Arbeitseinheit" eine<br />
Änderungsanforderung, ein Task oder eine Anforderung erstellt. Eine "Einheit" ist die Menge der<br />
zusammengehörigen Dateien, die eingecheckt werden.<br />
♦ Für Routine-Builds werden Ansichts-Labels (und ggf. Heraufstufungsstatuswerte) verwendet. Dies bedeutet<br />
beispielsweise, dass ein nächtliches Ansichts-Label dazu verwendet wird, von dem ein Build generiert und<br />
anschließend getestet wird. Ansichts-Labels, Heraufstufungsstatuswerte und Prozesselemente werden<br />
verwendet, um Aktualisierungsschritte in einer Ansicht zu unterstützen.<br />
Szenario 1: Kleine Entwicklerteams<br />
Für kleine Entwicklerteams und/oder kurzfristige Arbeitsaktivitäten können Entwickler die Hauptansicht direkt<br />
verwenden. Untergeordnete Ansichten werden erstellt, wenn ein Versionsmeilenstein erreicht und anschließend für<br />
die Versionswartung verwendet wird. Das Szenario eines kleinen Entwicklerteams ist im Folgenden dargestellt.<br />
Die Aktivitäten für dieses Entwicklungsszenario sind im Folgenden zusammengefasst:<br />
♦ Wenn eine Änderung ("mod") erforderlich ist, checkt ein Entwickler die erforderlichen Dateien aus der<br />
Hauptansicht aus und sperrt alle zu ändernden Dateien. Wenn der Entwickler Änderungen an den lokalen<br />
Arbeitsdateien vorgenommen und ggf. neue erforderliche Dateien erstellt hat, führt er ein umfassendes Unit-<br />
Testing aus, um sicherzustellen, dass Dateien für andere Entwickler freigegeben werden können.<br />
Anschließend checkt der Entwickler die neuen und geänderten Dateien beim Entsperren ein, wobei er ein<br />
Prozesselement verwendet, um die Revisionen mit der entsprechenden Änderungsanforderung, dem Task<br />
oder der Anforderung zu verknüpfen.<br />
♦ Ein automatisiertes Skript (nicht abgebildet) wird regelmäßig ausgeführt und erstellt ein neues Ansichts-Label.<br />
Über dieses Label werden Auscheckvorgänge vorgenommen, um Builds zu erzeugen und Test-Suites zu<br />
produzieren.<br />
♦ Wenn der Hauptentwicklungsstrom einen Versionsmeilenstein erreicht (beispielsweise nach der Code-<br />
Fertigstellung), wird eine Ansicht des Typs "Alle verzweigen" aus einem bestimmten Ansichts-Label (z. B.<br />
"Build 5.3.142 Freigabekandidat") oder einem Heraufstufungsstatus (z. B. "Integrationstest") erstellt. Diese<br />
Ansicht wird als Unterstützungsansicht verwendet, da es sich bei den an ihr vorgenommenen Änderungen<br />
224