Borland® StarTeam® 2006 - Borland Technical Publications

Projekte autonom halten
Die auf einer starken Kohäsion und geringen Abhängigkeiten basierenden Programmierungsgrundsätze gelten auch
für StarTeam-Projekte. Je unabhängiger Ihre StarTeam-Projekte sind, desto einfacher ist es, sie zu sichern, zu
verwalten und sie bei Bedarf von der ursprünglichen StarTeam-Konfiguration zu trennen. Wenn Sie Projekte
autonom halten, reduzieren Sie projektübergreifende Verknüpfungen und Freigaben auf ein Minimum bzw.
vermeiden Sie diese vollständig.
Nachfolgend finden Sie einige Richtlinien für die Entscheidung, welche Elemente im selben Projekt vorhanden sein
sollten:
♦ Ein Projekt sollte verwendet werden, um die Lebenszyklusartefakte einer zusammenhängenden
Anwendungsgruppe oder einer Anwendungskomponentengruppe zu verwalten. Beispiele sind im Handel
erhältliche Software-Produkte oder Packages mit Bibliotheken für Grundkomponenten. Mehrere Anwendungsoder
Komponentengruppen können in einem Projekt verwaltet werden, wenn sie zusammenhängen und in der
Regel zusammen verbessert und veröffentlicht werden.
♦ Ein Projekt sollte alle Artefakte enthalten, die zum Verwalten des Lebenszyklus der unterstützten
Anwendungen oder Komponenten erforderlich sind. Dazu gehören frühe Lebenszyklusartefakte, z. B.
Anforderungsdokumente, Modeling-Diagramme und Design-Dokumente sowie Artefakte der
Konstruktionsphase, z. B. Quelltextdateien.
♦ Dateien, die für das Authoring erforderlich sind. Dies umfasst beispielsweise alle Dateien, die von den IDEs
erzeugt wurden, z. B. Arbeitsbereichs-/Projektdateien, Quellcode- und Ressourcendateien. Außerdem
gehören dazu "Eingabedateien", z. B. .h-, .lib-, .jar-, oder .dll-Dateien, die an anderer Stelle erstellt
oder generiert werden, aber für die IDEs oder den Build-Prozess des Projekts erforderlich sind. Eingabedateien
können von Drittanbietern oder aus anderen Projekten in derselben oder anderen StarTeam-Konfigurationen
stammen. (Das Übertragen von Artefakten aus einem Projekt in ein anderes wird an anderer Stelle
beschrieben.)
♦ Dateien, die direkt aus geschriebenen Dateien generiert werden, z. B. .OBJ-, .CLASS,- und .LIB-Dateien,
müssen in der Regel nicht in das Projekt eingecheckt werden. Es ist jedoch üblich, die "endgültigen"
Binärdateien einzuchecken, z. B. .jar-, .war- und .exe-Dateien, die für andere Projekte, Engineering-Tests,
QA oder andere Deployment-Phasen vorgesehen sind. Der Bedarf, generierte Dateien der Versionskontrolle
zu unterstellen, ist stark abhängig von Ihren eigenen Entwicklungs-, Test- und Freigabemethoden.
♦ Ein Projekt sollte eine langfristige Sicht auf die Produkte oder Komponenten haben, die es unterstützt. Dies
bedeutet, dass alle über mehrere Iterationen des Lebenszyklus hinweg generierten Artefakte enthalten sein
sollten. Dies bedeutet weiterhin, dass das Projekt mehrere Versionen seiner Anwendungen oder Komponenten
unterstützt, die die gesamte Historie dieser Module darstellen.
♦ StarTeam funktioniert am besten, wenn die zusätzlichen Objekte (Änderungsanforderungen, Tasks, Themen
und Anforderungen), die mit den Dateien eines Projekts in Zusammenhang stehen, im selben Projekt
gespeichert werden. Dies ermöglicht beispielsweise, dass eine Änderungsanforderung eingegeben, verfolgt
und mit den Dateien im selben Projekt verknüpft werden kann, auf die sich die Änderungsanforderung bezieht.
Dieser Ansatz erfordert einige Überlegungen zu Aktivitäten wie das "Sichten von Änderungsanforderungen"
und die projektübergreifende Berichtserstellung. Diese Themen werden weiter hinten erläutert.
Einige Kunden haben versucht, Projekte zu verwenden, um Entwicklungsphasen (z. B. Design und Entwicklung)
oder Entwicklungsartefakttypen (wie Dateien und Änderungsanforderungen) zu trennen. Diese Artefakte werden
anschließend mittels zahlreicher Verknüpfungen oder Freigaben miteinander verbunden. Die Erfahrung hat jedoch
gezeigt, dass die übermäßige Verwendung von Freigaben – speziell von projektübergreifenden Freigaben – zu
Schwierigkeiten bei der Versionskontrolle, Berichtserstellung, Sicherheit und sogar der Leistung führt. Es hat sich
gezeigt, dass Artefakte, die mit denselben Anwendungen und Komponenten verknüpft sind, obwohl von
unterschiedlichen Typen und/oder unterschiedlicher Lebenszyklusrelevanz, effektiver in einem einzigen selben
Projekt verwaltet werden können.
208