10. Konfigurationsmanagement -...

10. Konfigurationsmanagement

Software Engineering

Gliederung Vorlesung

� Einführung

� V-Modell XT

� Analyse und Anforderungsmanagement

� Benutzungsoberflächen

� Architektur

� Entwurf

� Entwurfsmuster

� Persistenz

� Testen

� Konfigurationsmanagement

� Abnahme, Einführung, Wartung und Pflege

Allweyer: Software Engineering

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 Subversionhttp://svnbook.red-bean.com/nightly/de/svn-book.html

Konflikte: Versehentliches Überschreiben



Revisionsnummern

� Eine Revisionsnummer in SVN bezieht sich immer auf den gesamten Baum

● Nicht auf einzelne Dateien



Aktuellste Revision („HEAD“)

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. Bearbeiten

iii. Evtl. Revert (Lokale Änderungen rückgängig machen)

iv. Konflikt:i. Merge der Dateien

ii. Commit inklusive Kommentar!

v. Kein Konflikt: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● Besonders gekennzeichnete Versionen, die bestimmte Entwicklungsstände

repräsentieren (z. B. Meilenstein oder Release)


Repository

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)



Anlegen eines Zweiges (Branch)

� Ein Branch ist eine Kopie, auf der unabhängig vom Trunk weitergearbeitet wird



Verzweigung in der Geschichte einer Datei




Ä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ätzlicheKosten / größere Dauern – diesmuss vom Auftraggeber genehmigt werden!


ÄnderungsantragChange Request Form

Project: Proteus/PCL-T ools Number: 23/02Change requester: I. Sommerville Date: 1/12/02Requested change:When a component is selected from the structure, displaythe name of the file where it is stored.

Change analyser: G. Dean Analysis date: 10/12/02Components affected: Display-Icon.Select, Display-Icon.Display

Associated components: FileT able

Change assessment: Relatively simple to implement as a file name table isavailable. Requires the design and implementation of a display field. No changesto 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/03CCB 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

10. Konfigurationsmanagement -...

Documents

Transcript of 10. Konfigurationsmanagement -...