Der vom Projektmanagement erteilte Arbeitsauftrag ist ein Stimulus für alle im Rahmen des Projekts ausgeführten
Arbeitsvorgänge. Wenn ein Arbeitsauftrag eingeht, planen Teammitglieder ihre Arbeit normalweise, indem sie Listen der
zu erledigenden Aufgaben mit Fälligkeitsdaten erstellen, die den Vorgaben des Arbeitsauftrages entsprechen.
Der nächste Schritt besteht darin, dass die zuständige Rolle die notwendigen Arbeitsergebnisse, die bearbeitet oder zur
Quellensteuerung hinzugefügt werden müssen, abruft bzw. erstellt.
Projekte verwalten normalerweise gesteuerte Versionen von Arbeitsergebnissen in einem zentralen Repository mit
beschränktem Zugriff. Über die Operationen Check-in und Check-out kann das Entwicklungsteam eine bestimmte Version
eines Arbeitsergebnisses abrufen, ändern und erneut übergeben, um die geänderte Version zur aktuellen gesteuerten
Version zu machen. Der Zweck dieses Schritts besteht darin, sicherzustellen, dass Entwickler den Check-in- und
Check-out-Prozeduren folgen, um Änderungen an versionsgesteuerten Arbeitsergebnissen vorzunehmen.
Die primären Operationen im Rahmen des Konfigurationsmanagement, die von jedem Mitglied des Entwicklungsteams
ausgeführt werden können, sind folgende:
-
Check Out - Erteilt die
Berechtigung zur Änderung eines Elements.
-
Check In - Speichert eine
neue Version des geänderten Elements und macht die geänderte Version für den Check-out durch andere Teammitglieder
verfügbar. Es wird empfohlen, jeden Check-in mit einem kurzen Kommentar zu versehen, der die Änderung beschreibt.
-
Add to Source Control - Unterstellt eine neue Datei oder ein neues Verzeichnis der Versionssteuerung und
erstellt die erste Version.
-
Deliver - Übergibt Änderungen an den Integrator.
-
Rebase - Macht Änderungen anderer Entwickler für Ihre Anzeige verfügbar.
Ein Implementierer geht normalerweise wie folgt vor:
-
Zu ändernde Dateien auschecken.
-
Änderungen vornehmen.
-
Einheitentests durchführen, um die Änderungen zu überprüfen.
-
Änderungen genehmigen lassen.
-
Änderungen einchecken.
-
Änderungen bekannt machen.
Verschiedene Arten des Check-out
Standardmäßig besteht beim Check-out eines Elements die Möglichkeit, eine neue Version des Elements zu erstellen. Das
wird als reservierter Check-out bezeichnet. Ein anderer Benutzer, der parallel versucht, einen reservierten
Check-out desselben Elements durchzuführen, vorzunehmen, kann das nicht tun.
In vergleichbaren Entwicklungssituationen ist ein nicht reservierter Check-out ein Mechanismus, mit man eine
Datei auschecken kann, selbst wenn sie bereits durch jemand anderen ausgecheckt wurde.
Einige Organisationen verwenden routinemäßig einen FIFO-Entwicklungsstil, bei dem mehrere Benutzer einen nicht
reservierten Check-out desselben Elements vornehmen. Jeder von ihnen kann später einen Check-in durchführen, um die
nächste Version dieser Datei zu erstellen. Jeder andere muss diese Änderungen mit zuvor eingecheckten Änderungen
mischen, um eine neue Version erstellen zu können.
|