Darstellungsoptionen | UML-Darstellung: Optional kann dieses Arbeitsergebnis als Paket mit dem Stereotyp <<Projekt-Repository>>
(Project Repository) dargestellt werden.
Die Anpassung dieses Arbeitsergebnisses muss im Arbeitsergebnis Konfigurationsmanagementplan dokumentiert werden.
Das Projekt-Repository kann eine zentrale Fehlerquelle für alle Assets sein und muss deshalb zuverlässig,
fehlertolerant und skalierbar (für Modusdaten) sein und darüber hinaus eine hohe Leistung haben, um die
Produktentwicklung nicht zu beeinträchtigen. Im Folgenden sind die wichtigsten Hardwareüberlegungen (nach Priorität
sortiert) für das Projekt-Repository aufgeführt:
-
Speicherbedarf: Hauptspeicher ist eine der kostengünstigsten Methoden, um die Leistung eines
Konfigurationsmanagementtools zu verbessern. Wenden Sie die folgende Faustregel für die Ermittlung des
erforderlichen Hauptspeichers in der Servermaschine an: Addieren Sie den gesamten vom Projekt-Repository belegten
Speicherplatz in der Datenbank und teilen Sie die Summe dann durch zwei. 1 MB Hauptspeicher sollte beispielsweise
für das Caching und das Schreiben von Hintergrunddaten für 2 MB Speicherplatz in der Datenbank ausreichend sein.
Dieser Kalkulation liegt die Annahme zugrunde, dass jeweils auf die Hälfte der Daten im Projekt-Repository aktiv
zugegriffen wird. Servermaschinen sollten mindestens 256 MB Hauptspeicher haben. Auf der Clientseite sollte jede
Entwicklermaschine mindestens 128 MB Hauptspeicher haben.
-
Anforderungen an Platteneingabe/-ausgabe: Der zweite nahe liegende Leistungsengpass in der
Konfigurationsmanagementumgebung ist die Geschwindigkeit, mit der die Daten auf die Platte geschrieben werden
können. Lese- und schreibintensive Operationen sind das Einchecken, Auschecken und das Erstellen von
Referenzversionen. Es ist sinnvoll, pro Platte einen dedizierten Controller und Channel zu haben.
-
Netzbandbreite: Da das Konfigurationsmanagementtool gewöhnlich eine verteilte Anwendung ist, sind
eine angemessene Netzkapazität und Zuverlässigkeit Voraussetzungen für eine gute Leistung. Es empfiehlt sich, die
Maschinen mit dem Projekt-Repository und den Sichten in dasselbe Teilnetz zu stellen. Wenn das lokale Netz (LAN)
überlastet ist, was sich in Zeitlimitüberschreitungen und langen Antwortzeiten äußert, ist es sinnvoll, die
Netzkapazität zu erhöhen oder ein Teilnetz für die Maschine mit dem Konfigurationsmanagementtool hinzuzufügen.
-
Plattenspeicherplatz für Projekt-Repository: Je nach Größe eine Projekts kann es mehrere
Projekt-Repositorys geben, und jedes Projekt-Repository kann Zehntausende von Dateien und Verzeichnissen enthalten.
Die Anzahl der Dateien in einem Projekt-Repository richtet sich nach der Größe der Maschine, auf der der
Repository-Server ausgeführt wird, und der Anzahl der erwarteten Benutzer, die gleichzeitig auf die Daten
zugreifen. Ein aktives Projekt-Repository für die Codeentwicklung mit Lese- und Schreibzugriffen kann weniger
Elemente als ein weniger unbeständiges Repository enthalten, das nicht denselben Grad von Benutzerzugriffen hat.
Für das Projekt-Repository eines Softwareentwicklungsprojekts ist mit ungefähr 3000 bis 5000 Elementen zu rechnen.
Es empfiehlt sich, Plattenspeicherplatz für ein Anwachsen des Projekt-Repositorys vorzuhalten, und ungefähr 50 %
freien Speicherplatz zu haben, indem pro Projekt-Repository 2 GB Speicher zugeordnet werden.
Das Projekt-Repository sollte auf einem dedizierten Server gespeichert sein. Das bedeutet, dass der Server mit dem
Projekt-Repository nicht für folgende Zwecke verwendet werden sollte:
-
Kompilierung, Builds und Tests,
-
Ausführung anderer Fremdanbietertools,
-
Mail-Server,
-
Web-Server.
|