Software Engineering 10. Konfigurationsmanagement
Gliederung Vorlesung Einführung V-Modell XT Analyse und Anforderungsmanagement Benutzungsoberflächen Architektur Entwurf Entwurfsmuster Persistenz Testen Konfigurationsmanagement Abnahme, Einführung, Wartung und Pflege
Warum Konfigurationsmanagement? Änderungen nachvollziehen Man hat etwas im Code geändert, möchte dann aber wieder einen früheren Inhalt wiederherstellen Zusammengehörige Dateien verwalten Alle Quelltextdateien, Bibliotheken, Hilfsdateien usw. Jeweils in den Versionen, die zusammengehören Zusammenarbeit im Team Alle sollen jeweils mit den aktuellen Dateien der Kollegen arbeiten Geänderte Dateien sollen den anderen wieder zur Verfügung gestellt werden Lösung von Konflikten: 2 Leute haben die gleiche Datei geändert Wartung verschiedener Versionen Kunde erhält eine stabile Version (Release) Entwicklung arbeitet an der aktuellen Version weiter Bugfix muss in die stabile Version einfließen
Software-Elemente Eindeutig identifizierbare (Zwischen-)Ergebnisse, die im Laufe der Software-Entwicklung entstehen Beispiele Pflichtenheft Qualitätsplan Quelltext-Dateien Ausführbare Datei Unterscheidung nach Erzeugungsart: Quellelement Durch manuelle Eingaben erzeugt, z. B. Pflichtenheft, Quelltext Abgeleitetes Element Z. B. ausführbare Datei Software-Elemente müssen eindeutig bezeichnet werden Namenskonventionen
Konfigurationsmanagement mit Subversion (SVN) Quelle: Collins-Sussman/Fitzpatrick/Pilato: Versionskontrolle mit Subversion http://svnbook.red-bean.com/nightly/de/svn-book.html
Konflikte: Versehentliches Überschreiben Quelle: Collins-Sussman/Fitzpatrick/Pilato: Versionskontrolle mit Subversion http://svnbook.red-bean.com/nightly/de/svn-book.html
Revisionsnummern Aktuellste Revision ( HEAD ) Eine Revisionsnummer in SVN bezieht sich immer auf den gesamten Baum Nicht auf einzelne Dateien Quelle: Collins-Sussman/Fitzpatrick/Pilato: Versionskontrolle mit Subversion http://svnbook.red-bean.com/nightly/de/svn-book.html
Wichtige Tätigkeiten Checkout Das gesamte Projekt aus dem Repository holen Macht man am Anfang Update Neuerungen vom Repository holen Seine Arbeitskopie aktualisieren Falls es Konflikte gibt: Dateien zusammenführen ( Merge ) Commit Lokal veränderte Daten hochladen Führt zu einer neuen Revision des HEAD Geht nur, wenn man im HEAD keine Daten überschreiben würde Ggf. vorher Merge durchführen
Merge Vergleich der Unterschiede Übernahme von Änderungen und manuelle Anpassung möglich Anschließend wird die Version als merged markiert und kann commited werden
Arbeiten mit SVN Arbeitsablauf 1. Initialer Checkout um die erste Arbeitskopie des Projekt zu bekommen 2. Das tägliche Arbeiten: i. Update!!! ii. iii. iv. Bearbeiten Evtl. Revert (Lokale Änderungen rückgängig machen) Konflikt: i. Merge der Dateien ii. v. Kein Konflikt: Commit inklusive Kommentar! i. Commit inklusive Kommentar!
Beispiel: Tägliche Systemerstellung Diese Vorgehensweise eignet sich für iterative Vorgehensmodelle Es wird jeden Tag eine funktionierende Konfiguration erstellt Definierter täglicher Abgabezeitpunkt (z. B. 14 Uhr) Alle Entwickler müssen die neuen Versionen der geänderten Quelltext- Elemente einreichen. Diese müssen nicht vollständig sein, aber kompilierbar und testbar. Daraus wird ein neues System erstellt Dieses wird mit Hilfe von vordefinierten, z.t. automatisierten Tests getestet Parallel arbeiten die Entwickler an ihren Quelltexten weiter Gefundene Fehler werden an die Entwickler zurückgemeldet, diese beheben sie in einer Folgeversion Vorteile Frühes Erkennen von Fehlern Man hat ständig ein funktionierendes System (Risikoreduktion)
Umgebungen Entwicklungsumgebung Persönlicher Arbeitsbereich jedes Entwicklers Hier werden auch Elemente anderer Entwickler benötigt, damit der Entwickler seine Elemente testen kann -> Jeweils mit aktueller Baseline updaten Referenzumgebung Software-Elemente, die unter ausschließlicher Kontrolle des Konfigurationsmanagers stehen Fasst Software-Elemente zu reproduzierbaren Konfigurationen zusammen Prüfumgebung U.U. lokale Modifikationen (zum Ausprobieren), kein Weiterentwickeln Produktionsumgebung Nur freigegebenes Release
Was wird abgelegt? Produktdokumente Quell-Texte U.U. abgeleitete Elemente (z. B. Binaries) In jedem Fall: Notwendige Verfahren zur Reproduktion von Ableitungen Makefiles, Compiler, Entwicklungsumgebungen, Projektdokumente Z. B. Projektplan Prüfnachweise Z. B. Testprotokoll Selbst nicht versioniert, bezieht sich aber auf eine bestimmte Produktversion
Historie einer Datei Kommentare sind wichtig!
Vergleich mit früherer Version Man kann auch auf einen früheren Stand zurückgehen
SVN-Repository - empfohlene Verzeichnisstruktur Trunk Stamm des Versionsbaums (Hauptentwicklungslinie) Normalerweise wird hier gearbeitet Branches Äste im Versionsbaum, parallele Entwicklungszweige Tags Repository Besonders gekennzeichnete Versionen, die bestimmte Entwicklungsstände repräsentieren (z. B. Meilenstein oder Release)
Tags Ein Tag bezeichnet eine Momentaufnahme des Projektes, auf die man später evtl. wieder zurückgreifen möchte Meilenstein, Release, etc. Bezeichnung mit einem sprechenden Namen (z. B. Release 1.0 ) statt einfach einer Revisionsnummer (z. B. 4367). Ein Tag ist in SVN einfach eine Kopie der Verzeichnisstruktur Man sollte aber nicht darin weiterarbeiten Dafür dienen Branches Versucht man, in das Verzeichnis tags zu committen, erhält man eine Warnung Aber es wird nicht verhindert. Die Verwendung des Verzeichnis tags ist nur eine Konvention.
Entwicklungszweige (Branches) Quelle: Collins-Sussman/Fitzpatrick/Pilato: Versionskontrolle mit Subversion http://svnbook.red-bean.com/nightly/de/svn-book.html
Anlegen eines Zweiges (Branch) Ein Branch ist eine Kopie, auf der unabhängig vom Trunk weitergearbeitet wird Quelle: Collins-Sussman/Fitzpatrick/Pilato: Versionskontrolle mit Subversion http://svnbook.red-bean.com/nightly/de/svn-book.html
Verzweigung in der Geschichte einer Datei Quelle: Collins-Sussman/Fitzpatrick/Pilato: Versionskontrolle mit Subversion http://svnbook.red-bean.com/nightly/de/svn-book.html
Änderungsmanagement Änderungen sind natürlich und unvermeidlich Änderungen im Umfeld, z. B. Gesetzesänderungen Geänderte externe Schnittstellen Neue Anforderungen Neue Betriebsumgebung (z. B. geänderte Datenbankversion) Entdeckte Fehler / Probleme im Produkt Änderungen kontrolliert einbringen Mittel: Änderungsmanagement
Ablauf Änderungsmanagement Change Control Board -Projektmanager -Entwicklung -Auftraggeber Oft: Verschiedene Gremien, je nach Schwere des Falls Oft resultieren zusätzliche Kosten / größere Dauern dies muss vom Auftraggeber genehmigt werden!
Änderungsantrag Change Request Form Project: Proteus/PCL-T ools Number: 23/02 Change r equester: I. Sommerville Date: 1/12/02 Requested change: When a component is selected from the structure, display the name of the file where it is stored. Change analyser: G. Dean Analysis date: 10/12/02 Components affected: Display-Icon.Select, Display-Icon.Display Associated components: FileT able Change assessment: Relatively simple to implement as a file name table is available. Requires the design and implementation of a display field. No changes to associated components are required. Change priority: Low Change implementation: Estimated effort: 0.5 days Date to CCB: 15/12/02 CCB decision date: 1/2/03 CCB decision: Accept change. Change to be implemented in Release 2.1. Change implementor: Date of change: Date submitted to QA: QA decision: Date submitted to CM: Comments Quelle: Sommerville