3 Konfigurationsmanagement

Transkript

1 Software Engineering is multi-person construction of multi-version software. [Parnas 1974] 3 Konfigurationsmanagement 3.1 Motivation Qualitätssicherung und Konfigurationsmanagement nalytische Qualitätssicherung Fehler finden, z.b. durch Testen, Reviews und formale Verifikation. = Qualitätszustand wird ermittelt. Konstruktive Qualitätssicherung Fehler vermeiden, z.b. durch Vorgehensmodelle und Konfigurationsmangement. = Qualität wird aufgebaut. Konfigurationsmanagement Software Configuration Management is the discipline of managing the evolution of large and complex software systems. [Tichy 1988] Typische Fragen, die beantwortet werden müssen: Welche Änderungen wurden im Vergleich zur Vorgängerversion durchgeführt? Wer hat diese Änderung durchgeführt? Diesen Fehler habe ich schon vor Wochen korrigiert. Warum taucht er jetzt wieder auf? Konfigurationen Konfiguration Zusammenstellung von Einheiten zu einem System. Fragen dabei: Was sind die Konfigurationseinheiten? = Dateimanagement Was passiert, wenn sich eine Konfigurationseinheit ändert? = smanagement Wann darf sich eine Konfiguration/Konfigurationseinheit ändern? = Änderungsmanagement Wie wird aus den Konfigurationseinheiten ein Produkt? = Build Management Verwaltung von Konfigurationseinheiten Konfigurationseinheiten sind einer zentralen Verwaltung unterstellt, eindeutig identifiziert und vor unkontrollierten Änderungen geschützt. lte en werden aufbewahrt zur Rekonstruktion, Rückkehr, Referenz usw. Falls die Entwicklung verzweigt, werden mehrere Varianten verwaltet. Konfigurationen werden für die uslieferung zusammengestellt. Prüf- und die Integrationsabteilungen werden mit den korrekten Komponenten beliefert. uch andere Stellen erhalten die Software grundsätzlich nur vom Konfigurationsmanagementsystem. 35

2 Datenflüsse im Konfigurationsmanagement Repository Konfigurattionseinheiten geprüft ungeprüft rbeitsumgebung Datenflüsse Konfigurationseinheiten Prüfresultate Statuswechsel Prüfumgebung Releaseumgebung Konfigurationsmanagementsysteme Definition 8 (Konfigurationsmanagementsystem). Konfigurationsmanagementsysteme umfassen typischerweise folgende Managementfunktionen: smanagement Änderungsmanagement Build Support weitere organisatorische Maßnahmen (z.b. Einhaltung von Standards) Konfigurationsmanagement kann als Teilaspekt des Projektmanagements gesehen werden. insbesondere auch des Qualitätsmanagements Sollte frühzeitig beginnen! 3.2 en en/revisionen/varianten/releases Eine Instanz einer Komponente, die irgendwie anders ist als andere Instanzen dieser Komponente. Revision Eine überarbeitete einer Instanz. Variante Eine Instanz einer Komponente, die (zumeist) funktional identisch, aber nicht-funktional verschieden zu anderen Instanzen dieser Komponente ist. Release Eine Instanz, die an Nutzer außerhalb des Entwicklungsteams gegeben wird. Wie sieht das Verhältnis aus? 36

3 Revisionen und Varianten en können somit klassifiziert werden als Revisionen Varianten Reflektieren die zeitliche Entwicklung von Softwaresystemen. Stehen für den Zustand einer Komponente zu einem bestimmten Zeitpunkt ihrer Entwicklung. Entstehen durch Fehlerkorrekturen, Optimierung, Erweiterung, und anderen npassungen. Stellen die zueinander alternativen usprägungen von Komponenten dar. Entstehen z. B. bei der Unterstützung unterschiedlicher Hardware, unterschiedlicher Funktionalität oder System-Software. Revisionen und Varianten Revision Variante ssprünge, Releases Bei größeren Änderungen werden ssprünge durchgeführt. Die erste Stelle der wird erhöht. Das ist dann zumeist auch eine Release. V 1.0 V 1.1 V 1.2 V 2.0 Release 1 Release 2 System-Releases (Freigaben) Sind nicht einfach nur ausführbare Programme. Können auch umfassen: Setup-Dateien zur Installation Daten Handbücher Systeme können z.b. auf CD-ROM, DVD oder über das Internet vertrieben werden. 37

4 Element- und s-identifikation Element-Identifikation Eine große nzahl von Dokumenten muss eindeutig benannt werden. Hierarchische Schemata mit mehreren Ebenen sind zumeist der beste nsatz. Es sollten nur Primärobjekte verwaltet werden. s-identifikation Oft wird ein numerisches Namensschema verwendet, z.b. V1, V1.1, V1.2, V2.1, V2.2 etc. Die tatsächliche bleitungsstruktur ist zumeist ein Baum. snamen sind nicht immer bedeutungsvoll. Releases werden gelegentlich durch das Marketing benannt. ttribute für versionierte Elemente ttribute können zu einer assoziiert werden. Zum Beispiel: Datum Zustand Eigentümer ktueller Bearbeiter Entstehungsdatum Änderungshistorie Sperren, Zugriffsrechte Schlüsselbegriffe (zum Wiederauffinden) Diese Information kann auch das Finden bestimmter en unterstützen. Release-Etiketten als ttribute Etiketten (Tags) werden verwendet, um mehrere Elemente gleichartig zu markieren und/oder um sie einer Konfiguration zuzuordnen. Qellcode Datei 1 V1.0 V1.1 V1.2 V2.0 Quellcode Datei 2 V1.0 V1.1 tag: System X Release Vista Quellcode Datei 3 V1.0 V1.1 tag: System Y Release XP 38

5 Release-Probleme Kunden wollen nicht immer die aktuellste eines Systems. Sie sind mit dem gegenwärtigen System zufrieden. Die neue könnte nicht gewünschte oder nicht vertrauenswürdige Funktionalität haben (z.b. Windows Vista). Man kann nicht voraussetzen, dass nwender alle vorigen en installiert haben. 3.3 smanagement-werkeuge ufgaben von smanagement-werkzeugen s-identifikation Für neue en werden automatisch neue ttribute generiert. ufnahme der Historie Vermerken der Gründe für neue en. Koordination Umfasst Sperren Unterstützen von nebenläufigem rbeiten Kombinieren von Ergebnissen Speichermanagement Delta-Techniken Lost Updates Ein Problem, das es zu vermeiden gilt Zwei nwender die gleiche Datei Beide bearbeiten die Datei veröffentlicht zuerst seine überschreibt die von Checkout/Checkin-Modell Checkout- oder usbuche-operation 1. Reserviert das Software-Element für den usbucher (locking). 2. Holt eine Kopie eines Software-Elements aus dem Repository. Checkin- oder Einbuche-Operation 1. Legt das Software-Element in das rchiv ab. 2. Löscht die Reservierung (unlocking). Der Lesezugriff ist von den Reservierungen unbeeinflusst. Dies ist ein pessimistisches Sperrverfahren. 39

6 Vermeidung von Lost Updates Durch das Checkout/Checkin-Modell (bzw. Lock-Modify-Unlock) sperrt sperrt die die Datei Datei dann dann kopiert kopiert er er sie sie für für die die Bearbeitung Während der der Bearbeitung von von misslingt die Freischaltung von schreibt seine dann veröffentlicht er er sie Jetzt kann sperren, und die Datei bearbeiten sperren X sperren freischalten sperren RCS: Revision Control System RCS: Revision Control System RCS setzt das Checkout/Checkin-Modell um [Tichy 1985]. RCS Befehle: Zuerst Unterverzeichnis RCS erzeugen: mkdir RCS ci -u hello.java Beenden der Log-Nachricht mit,. co -l hello.java rcs u hello.java rlog, rcsdiff, etc. Typische Benutzung: co -l Foo.java emacs Foo.java ci -u Foo.java Deltas in RCS D1 D2 D3 Zeit 40

7 Varianten in RCS D1.1 D1.2 D1.3 D RELESE 1 D RELESE 2 RCS Grenzen Ursprünglich für Programmcode entworfen, daher zur Verwaltung von SCII-Text entworfen. Seit 5.5 sind auch Binärdateien erlaubt. Check in/out ist begrenzt auf einzelne Dateien Concurrent s System Concurrent s System CVS Basiert auf RCS. Erlaubt die ierung von (hierarchischen) Verzeichnissen. Erlaubt optimistische Sperren (default). Unterstützt Release-Verwaltung. Verwaltet die master sources in einem gemeinsamen Repository. Bei entsprechender Konfiguration ist auch Zugriff via Netzwerk möglich, auch ohne NFS. Repository vs. rbeitskopie lle en jeder Datei des Projektes sind im zentralen Repository. Gearbeitet wird an ausgescheckten rbeitskopien. rbeitskopien werden nicht gesperrt, wenn woanders ausgescheckt und bearbeitet wird. = Potenzial für Konflikte. 41

8 CVS Befehle Ergänzung neuer Module im Repository: cvs import mymodule V1 V2000 rbeitskopie anlegen: cvs checkout mymodule Dateien ergänzen: cvs add Dateien löschen: cvs remove Änderungen aus dem Repository holen: cvs update Änderungen in das Repository übertragen: cvs commit Information zu Dateien: status, diff, log Etiketten: tag, release, etc. Typische Benutzung: cvs update emacs Foo.java cvs commit Verschmelzen von Änderungen (Merging) Zwei Zwei Zwei Zwei Zwei nwender nwender kopieren Zwei nwender kopieren die die Zwei nwender kopieren die gleiche die gleiche nwender Datei gleiche Datei kopieren die Zwei Datei Datei kopieren die gleiche nwender gleiche Datei kopieren die die gleiche gleiche Datei Datei Datei Die Die Die Die beiden Die beiden beiden bearbeiten Die beiden ihre beiden bearbeiten Die ihre ihre beiden Datei bearbeiten Die ihre beiden ihre Datei Datei bearbeiten ihre Datei ihre Datei bearbeiten ihre Datei Datei veröffentlich ihre ihre veröffentlich ihre veröffentlich ihre veröffentlich zuerstihre zuerstihre veröffentlich zuerst zuerstihre zuerst zuerst '' '' '' '' '' '' '' '' erhält erhält die die die erhält erhält die "veraltete erhält die Fehlermeldung "veraltete die Fehlermeldung " "veraltete erhält Fehlermeldung "veraltete die " Fehlermeldung " "veraltete "veraltete " " " '' '' '' '' '' '' '' ' ' ' ' ' ' ' ' '' '' '' '' '' '' '' '' ' ' ' ' ' ' ' ' '' '' '' '' '' '' '' X X X ' ' ' ' '' '' ' ' '' ' '' '' '' die letzte aktualisiert aktualisiert die die die letzte aktualisiert die aktualisiert die letzte bei bei bei sich die letzte sich die letzte letzte bei bei sich bei sich bei sich sich Eine Eine Eine neue neue Eine neue Eine Eine neue ist ist ist neue entstanden ist neue ist ist entstanden ist entstanden ist entstanden Die Die Die Die neue Die neue neue Die Die neue ist ist ist veröffentlicht neue ist ist veröffentlicht ist veröffentlicht ist veröffentlicht Nun Nun Nun haben haben beide beide nwender die Nun haben die die Nun haben haben beide beide beide nwender des des nwender die nderen die Änderungen die Änderungen des des des nderen des nderen '' '' '' '' '' '' '' '' '' '' '' '' '' '' '' * * * * * * * * * * * '''' '''' '''' '''' '''' '''' '' '' '' '' '' '' '' * * '' '' * * * * * * '' '' '' * * '' '' * * * '' '' '' * * * * * * * * * * * 42

9 nnahmen mit CVS Konflikte sind selten. Gleichzeitiges Ändern von Dateien geschieht an verschiedenen Orten innerhalb einer Datei. Wenn, dann sind Konflikte leicht aufzulösen. Sonst scheint es ein Kommunikationsproblem im Team zu geben. Bei einem Konflikt werden alle Änderungen gezeigt und müssen manuell behoben werden Subversion SVN Subversion Nachfolger von CVS Erlaubt die Umbenennung von Verzeichnissen und Dateien Für große Projekte kann eine Datenbank für die Datenhaltung genutzt werden Effiziente Verwaltung von symbolischen Links und binären Daten nders als bei CVS führt jeder Commit zu einer neuen Revision Konflikte müssen explizit gelöst werden Kann HTTP/DV als Übertragungsprotokoll nutzen SVN Befehle Ergänzung neuer Module: svn import mymodule rbeitskopie anlegen: svn checkout mymodule Änderungen aus dem Repository holen: svn update Typische Benutzung: svn update emacs Foo.java svn commit Änderungen in das Repository übertragen: svn commit Dateien ergänzen, löschen, umbenennen: add, remove, move Information zu Dateien: status, diff, log Letze Änderungen aufheben: svn revert Nach dem Beheben von Konflikten muss der Konflikt als behoben markiert werden: svn resolved Die sverwaltung von Subversion Subversion verwaltet pro Repository eine ganze Zahl als snummer, die den aktuellen Status des Repository bezeichnet. Diese Zahl wird (für das Repository) bei jedem erfolgreichen Commit um eins erhöht. Für einzelne Elemente im Reporitory wird die entsprechende snummer nur bei Änderungen erhöht. 43

10 CVS und Subversion Richtlinien Teile keine rbeitsbereiche! Jeder Entwickler muss auf einer eigenen rbeitskopie des Projekts arbeiten. rbeite nicht ausserhalb des rbeitsbereiches! Quellcode sollte nur in Verzeichnissen bearbeitet werden, die von CVS bzw. Subversion verwaltet werden. Synchronisiere Dich häufig mit dem Repository! svn update vor Bearbeitung nicht vergessen. CVS und Subversion Richtlinien (Forts.) Commit uch für Zwischenstände, auf die man möglicherweise wieder aufsetzen möchte. Backup Zusammengehörige Dateien (evtl. ganze Verzeichnisse) in einer Operation Verwende dabei eine gemeinsame Log-Nachricht Markiere wichtige Stadien mit Etiketten! Ein paar Links Offizielle Seite des Subversions-Projekts Offizielle CVS Sites Tortoise Online-Handbuch: Konfigurationsmanagement mit CVS und Subversion Mit beiden können alle wichtigen ufgaben des smanagements erledigt werden. Mit beiden können somit auch einige Konfigurationsmanagementaufgaben erledigt werden. Dabei müssen Richtlinien für Release- und Änderungsmanagement definiert und eingehalten werden. Durch Etiketten können mehrere Dateien im Repository einer Release (Konfiguration) zugeordnet werden. RCS / CVS / Subversion Grenzen Kein Ersatz für gutes Management Kein Ersatz für Kommunikation Nur eingeschränkte Änderungskontrolle: Zeilenorientiert Kein Prozesskontrollsystem Kein Build System 44

11 ndere Beispiele für smanagementwerkzeuge SCCS PVCS IBM Rational ClearCase Microsoft SourceSafe Unterstützen häufig noch mehrere ufgaben, als nur das s- und Konfigurationsmanagement. 3.4 System Bauen (Build) System Bauen (Build) Nimmt alle Systemkomponenten und baut daraus ein ausführbares System. Verschiedene Systeme können aus verschiedenen Kombinationen von Komponenten gebaut werden. Es kann bei großen Systemen eine gewisse Zeit kosten, bis alle Komponenten compiliert und gelinkt wurden. Evtl. Erzeugung älterer en im Rahmen der Wartung. Systembau-Herausforderungen Typische Fragen: Berücksichtigen die Bauinstruktionen alle benötigten Komponenten? Werden die richtigen en der Komponenten verwendet? Sind alle Dateien verfügbar? Welcher Teil eines Systems muss nach einer Änderung neu übersetzt werden? Wird die Zielplattform berücksichtigt? Werden verschiedene Compiler-en, etc. richtig aufgerufen? Systembau mit make Systembau mit make Wird üblicherweise unter Unix verwendet. Vergleichbares gibt es natürlich auch unter anderen Betriebssystemen Komponentabhängigkeiten werden spezifiziert und make erzwingt automatisch eine Neu-Compilation von benötigten Dateien, falls diese geändert wurden; nachdem die abhängigen Dateien erzeugt wurden. 45

12 Komponent-bhängigkeiten steuer main.o input.o calc.o print.o main.c input.c input.h calc.h calc.c print.c Wie sieht das makefile aus? Wie kommt man an bestimmte en? Probleme mit make Basiert auf einem physikalischen Modell von bhängigkeiten. Inhaltlich wäre auch ganz sinnvoll. bhängigkeitsspezifikationen (Makefiles) können leicht groß, komplex und schwer zu verstehen werden. Disziplin und eine hierarchische Datei-Struktur können helfen. make verwendet ein einfaches Änderungsmodell basierend auf Dateiänderungszeiten. Kommentaränderungen in Programmen erfordern eigentlich keine Neu-Compilation pache nt pache nt Werkzeug zur Systemerstellung des pache-projektes Vorteile gegenüber make durch Java- und XML-Technologie Steuerung durch Buildfile mit Zielen (Targets) und ufgaben (Tasks) 46

13 <target name="compile"> <mkdir dir="\${builddir}"/> <javac srcdir="\${srcdir}/ bestellwesen" destdir="\${builddir}"/> </target> Viele vordefinierte ufgaben z.b. javac und jar Selbst definierte ufgaben sind möglich. Typische Verzeichnisse in einem Java-Projekt src enthält die.java -Dateien mit dem Java-Quellcode einschließlich der Verzeichnisse gemäß der PackageStrukturen. classes enthält die.class-dateien mit dem Java-Bytecode einschließlich der Verzeichnisse gemäß der PackageStrukturen. Wird manchmal auch build genannt. lib enthält gepackte Dateien, z.b..jar-dateien. doc enthält die Dokumentation. 3.5 Planung des Konfigurationsmanagements Planung des Konfigurationsmanagement lle Produkte der Softwareentwicklung müssen verwaltet werden, z.b.: Spezifikationen Entwürfe Programme Testdaten Handbücher Für große Softwaresysteme können das Tausende von Dokumenten werden. Der Konfigurationsmanagementplan Definiert die Typen der Dokumente, die verwaltet werden sollen, sowie ein Namensschema für diese Dokumente. Definiert wer wofür Verantwortung hat. Definiert Regeln für Änderungs- und smanagement. Beschreibt die zu verwendenden Werkzeuge inklusive deren Benutzung. 47

14 Standards für das Konfigurationsmanagement Konfigurationsmanagement sollte immer auf Standards beruhen, die dann innerhalb einer (Projekt- ) Organisation befolgt werden. Das hat auch etwas mit Disziplin zu tun. Solche Standards müssen definieren wie Elemente identifiziert werden, wie Änderungen kontrolliert werden (Freigaben), wie neue en verwaltet werden. Beispiele: IEEE 828: Software Configuration Management Plans IEEE 1042: Guide to Software Configuration Management Struktur eines Konfigurations-Managementplans (SCMP, IEEE ) Introduction Describes purpose, scope of application, key terms and references. Management (WHO) Identifies the responsibilities and authorities for accomplishing the planned configuration management activities. ctivities (WHT) Identifies the activities to be performed in applying to the project. Schedule (WHEN) Establishes the sequence and coordination of the SCM activities with project mile stones. Resources (HOW) Identifies tools and techniques required for the implementation of the SCMP. Maintenance Identifies activities and responsibilities on how the SCMP will be kept current during the lifecycle of the project. Änderungsmanagement Die Änderung eines Software-Elements ändert prinzipiell auch die gesamte Konfiguration. Änderungen sollten einen koordinierten Änderungsprozess durchlaufen, um Änderungen strukturiert, kontrolliert und dokumentiert vornehmen zu können. ufgaben dabei: Erfassung, Verwaltung und Verfolgung von Problemmeldungen und Änderungsanforderungen Bewertung und Entscheidung über die Bearbeitung von Änderungsanforderungen unter Berücksichtung des Projektkontextes Werkzeuge zur Unterstützung des Änderungsmanagements sind z.b.: Bugzilla GNU GNats: Tracking System (GNTS) Änderungsgeschichte rchiv von Änderungen für ein Dokument Sollte u.a. verwalten Was wurde geändert? Warum? Wer? Wann? Status 48

15 Beispiel Historie r24 reiner :05: (Fri, 24 Mar 2006) 2 lines kleinere Korrekturen um die Übersetzbarkeit wieder sicherzustellen r21 reiner :07: (Fri, 24 Mar 2006) 2 lines Verzeichnisstrukturänderungen r19 willi :35: (Fri, 24 Mar 2006) 1 line r16 willi :24: (Thu, 23 Mar 2006) 1 line Änderungen in Dagstuhl r15 willi :38: (Tue, 21 Mar 2006) 1 line include/input Umstellung r14 reiner :21: (Tue, 21 Mar 2006) 6 lines dded a lot of makefile stuff and other checks did some additional restructuring added tests for each chapter updated the tructure document Lernziele Wissen, was Konfigurationsmanagement leisten kann, und was nicht... Konzepte für das smanagement verstehen. Konkrete Systeme kennenlernen: RCS, CVS und Subversion (in den Übungen). Das Bauen von Systemen verstehen. Make als einfaches Werkzeug, nt als spezialisiertes Werkzeug für Java (mit XML). Planung des Konfigurationsmanagements Das Ganze hat viel mit Disziplin zu tun. Einhaltung von Standards (z.b. IEEE 828 und IEEE 1042) Ohne Werkzeugunterstützung geht es eigentlich nicht. Literatur: Zeller and Krinke [2003], Popp [2008]. 49