Software Konfigurations- Management Walter F. Tichy Universität Karlsruhe 1
Definition Software Konfigurations-Management (SKM) ist die Disziplin zur Verfolgung und Steuerung der Evolution von Software. SKM ist unerläßlich für die Entwicklung und Pflege großer, langlebiger Softwaresysteme. 2
SKM: Software-Evolution im Griff Software ändert sich andauernd. Änderungen verursachen Chaos. SKM hilft, das Änderungschaos zu vermeiden: Macht die Entwicklungsgeschichte rückverfolgbar, Verhindert oder gleicht konkurrierende Änderungen ab. Verfolgt Konfigurationen und Freigaben, Verfolgt Fehlermeldungen und Korrekturen, Automatisiert Versionsselektion und Verarbeitungsschritte, hält Software in einem wohldefinierten Zustand. 3
Ein konservatives Beispiel Betrachte ein kleines Software-Projekt: 100 Module 10 Entwickler 20 Versionen pro Modul Ein Programmierer ändert nur ein Modul pro Tag Gestern gab es eine funktionsfähige Konfiguration. Seither haben Entwickler 10 Module verändert. Sie wissen nicht, ob Sie heute mit den alten oder neuen Versionen arbeiten sollen. Wieviele mögliche Konfigurationen von alten und neuen Versionen müßten Sie untersuchen? 4
Ein konservatives Beispiel Antwort: 2 10 ~ 1000 Konfigurationen Falls das Konfigurieren, Übersetzen und Testen jeder Alternative nur 1 Min. in Anspruch nehmen würde, währen Sie allein mit der Auswahl 17 Stunden beschäftigt. In der Praxis muß man nicht alles durchprobieren, aber man hat wesentlich mehr Versionen und braucht mehr Zeit pro Konfiguration. Man verbringt jeden Tag unnötig Zeit damit, einen konsistenten Entwicklungsstand herzustellen. 5
Symptome des Änderungschaos Identifikation und Verfolgung: Dieses Programm funktionierte gestern noch! Diesen Fehler habe ich schon letzte Woche korrigiert! Wo sind meine Änderungen von letzter Woche? Das ist eine offensichtliche Verbesserung. Wurde sie schon probiert? Wer ist für diese Änderung verantwortlich? 6
Mehr Änderungschaos Versionsselektion Wurde alles übersetzt? Nachgetestet? Wie konfiguriere ich für Test, mit meinen Änderungen aber keinen anderen? Wie schließe ich diese fehlerhafte Änderung wieder aus? Ich kann den Fehler in dieser Konfiguration nicht rekonstruieren! Welche Änderungen sind denn nun in dieser Freigabe? 7
Noch mehr Chaos... Software-Lieferung Welche Wünsche des Kunden sind berücksichtigt? Welche Konfiguration hat der Kunde? Haben wir eine konsistente Konfiguration geliefert? Hat der Kunde modifiziert? Der Kunde hat die letzten zwei Freigaben nicht installiert. Was passiert, wenn wir ihm die neue schicken? Diese Probleme klingen für jeden vertraut, der in der Software-Entwicklung gearbeitet hat. 8
Geschichte von SKM Konfigurations-Management wurde ca. 1950 für die US-Luftund Raumfahrtindustrie erfunden. U.a. wurde KM im Apollo- Programm zur Verfolgung Tausender von Änderungen benutzt. SKM begann ca. 1970 mit SCCS und MAKE. SKM ist heute ein erfolgreicher Teile des Software- Werkzeugmarktes, mit über 50 versch. Lösungen. SKM-Werkzeuge bieten anerkannten Wert für den Praktiker. SKM-Werkzeuge sind technisch anspruchsvoll. 9
Wie unterscheidet sich SKM von traditionellem KM? 1. Software ist reiner Gedankenstoff, vergleichbar mit Konstruktionsplänen. Produktions- und Distributionskosten sind vernachlässigbar. Dadurch ist Software billiger zu ändern und sie ändert sich daher rascher. SKM muß daher schneller reagieren. 2. Software kann komplett im Rechner gespeichert werden. SKM ist automatisierbarer. 10
Literatur über SKM International Workshop on Software Configuration Management 6. bis 9. Treffen in 1996, 1997, 1998, 1999. Konferenz-Bände bei Springer Verlag erschienen. Bücher: Applying RCS and SCCS, Bolinger & Bronson, O Reilly, 1995. Configuration Management, Tichy, Wiley, 1994. Übersicht über viele Werkzeuge: www.cs.colorado.edu/ ~andre/configuration_management.html 11
SKM-Werkzeuge in Deutschland Quelle: IT Research, 1998 PVCS 25.7% Clearcase 12.6% Continuus 8.4% SourceSafe 8.0% RCS 7.6% Endevor 4.6% SourceInteg rity 3.6 inhouse 3.4% SCCS 2.7% 12 CCC 1.9%
2. Grundkonzepte Softwareobjekt (Softwareelement): jede maschinenlesbare Informationseinheit ( Dokument ), die im Laufe eines Softwareprojektes entsteht. Beispiele:Anforderungsdokumente, Entwurfsdokumente, UML, Spezifikationen,Programmcode, Dokumentation, Testprogramme, Testdaten, Testergebnisse, Handbücher, CAD-Dokumente, Fehlermeldungen, Ländereinstellungen, Bilder, Ikonen, Diagramme, Tonaufzeichnungen, etc. 13
Softwareobjekte Ein Softwareobjekt hat einen eindeutigen Namen und einen persistenten Inhalt. Ein Softwareobjekt ist unveränderlich: jede Änderung erzeugt eine neues Objekt (Version); kann nicht verändert werden, sobald die Erzeugung abgeschlossen ist (Einfrieren vermeidet Fehlidentifikation). Klassifikation der Softwareobjekte nach Erzeugung: manuell oder automatisch Struktur: atomar oder Konfiguration 14
Softwareobjekte Primärobjekt, Quellobject (source object): manuell erzeugt, unantastbar und normalerweise nicht löschbar. Sekundärobjekt (derived object): vollautomatisch erzeugt. Kann aus Platzgründen gelöscht werden. Besitzt eine Herleitungsgeschichte zur Wiederherstellung (Transformator(en) und Eingaben). 15
Struktur von Softwareobjekten Ein Softwareobjekt ist ein Atom (unteilbar): es besitzt keine Bestandteile, die unabhängig voneinander variiert werden können, ohne das ganze Objekt zu ändern, oder eine Konfiguration: es besitzt mehrere unabhängig variierbare Bestandteile, die selbst wieder Atome oder Konfigurationen sind (hierarchische Teileliste). 16
Beispiel Tischplatte TP1 Anleitung: Befestige Beine B1 mit Schrauben S1 an TP1. Beine B1 Schrauben S1 Welche ist die Sekundärkonfiguration? 17
3. Anforderungen an SKM Prozeß- Unterstützg. Änderungsverfolgung Verteilung (LAN, WAN) Konfigurationen, Erbauung Versionshaltung 18
4. Versionshaltung Revision: Ein Softwareobjekt, das durch Modifikation eines existierenden Objektes entstand. Varianten: Softwareobjekte, die gewisse gemeinsame Eigenschaft haben (z.b. die Spezifikation oder Schnittstelle), aber in anderen differieren (z.b. in der Bedienung, Plattform, Algorithmus, Datenstruktur, Kennlinie). 19
Versionen Version: eine Revision, Version, oder beides Sowohl Atome als auch Konfigurationen können Versionen bilden. Fast alle Quellobjekte haben Versionen (außer Fehlermeldungen, E-Post-Botschaften, u.ä.) Versionsgruppe: eine Menge von Softwareobjekten, die Versionen voneinander bilden. 20
Organisation von Versionsgruppen Datenbank (Archiv) Fix.1 checkout Arbeitsbereich (Sandkasten) 1.1 1.2 1.3 2.1 2.2 2.3 2.3 checkin Revision-von Variante-von Par.1 Par.2 Änderungszyklus:1. checkout (erzeuge Kopie in Arbeitsbereich, Platzhalter in DB) 2. modifiziere Kopie in Arbeitsbereich 3. checkin (befördere Kopie in Platzhalter) 21
Deltas sparen Platz Datenbank (Archiv) Fix.1 checkout Arbeitsbereich (Sandkasten) 1.1 1.2 1.3 2.1 2.2 2.2 2.3 2.3 checkin Par.1 Par.2 Ein Delta ist der Unterschied zw. zwei Revisionen. Kann vorwärts oder rückwärts berechnet werde. Wird zur Wiederherstellung von Revisionen benutzt. 22
Versionsverwaltung direkt aus Editor 23
VRCE Visual Revision Control Engine Archivpfad, dupliziert Struktur des Arbeitsbereiches Arbeitsbereich Grün bedeutet, der Arbeitsbereich ist im Archiv gesichert. Datei liegt -nurim Arbeitsbereich; -nurimarchiv; - zum Schreiben ausgebucht; - zum Lesen ausgebucht. Hauptfenster 24
VRCE Visual Revision Control Engine Ruft auf Versionsgraph der ausgewählten Datei Ausgewählte Version Attribute der ausgewählten Datei Attribute der ausgewählten Version Anzeige des Versionsgraphen Durchblättern der ausgewählten Dateien mit dem Nächste Knopf. 25
5. Konfigurationen Selektiere Versionen (z.b. letzte Referenzkonfiguration plus abgenommene Änderungen, minus fehlerhafte Versionen) Erbaue überall und jederzeit, mit korrekten Versionen der korrekten Komponenten. Wiederhole jeden Selektions- u. Erbauungslauf exakt und jederzeit, einschl. Versionen der Werkzeuge. Mehrere Erbauungsläufe gleichzeitig. Evtl. jeder Erbauungslauf intern parallel. 26
6. Änderungsverfolgung Alle Änderungen sind getrieben von Änderungswünschen. Änderungswünsche/Fehlermeldungen in Datenbank. Verknüpfung zw. Änderungswünschen, Versionen, Korrekturen. Zustandsverfolgung (verworfen, zurückgestellt, in Arbeit, getestet, freigegeben, etc.) genaue Zustandsberichte: Welche Änderungen sind fertig, welche in Arbeit? Wo häufen sich Änderungen? Wo gibt s Verzögerungen? Welche Änderungen sind in einer geg. Freigabe enthalten? 27
Änderungsverfolgung Bug report27 Bug report26 Bug report25 Requirements: This system shall..... Design Part 1: C1 C2 Design Part 2: D1 class C1 { method c11(){ } method c12 (){ } } D2 28
7. Prozeßunterstützung Unterstützung für Zyklus Fertigmeldung - Annahme -- Integration&Test - Übernahme Parallelentwicklung ist die Regel. Verfolgung von Änderungssätzen. Abhängigkeitsverfolgung. 29
Ein Prozeßmodell für Parallelentwicklung Jeder Entwickler oder jedes Team arbeitet an eigenem Ast. Angenommene Änderungen sind auf Haupt-Ast. Von Zeit zu Zeit starten Entwickler einen Aktualisierungsprozeß, der neue, angenommene Änderungen in den eigenen Ast übernimmt. Fertigstellung wird Integrator gemeldet. Integrator/Tester führt einfache Verschmelzungen durch; testet und nimmt ab. 30
Modell für Parallelentwicklung Sammle Änderungssatz Team1.1 Annahme, Test Rel.1 Rel.2 Sammle Änderungssatz Team2.1 Team2.2 Übernahme Team2.3 Annahme, Test Rel.3 31
8. Verteilung Weltweite Zusammenarbeit koordinieren. Informelles SKM unmöglich bei verteilten Arbeitsgruppen, speziell bei verschiedenen Zeitzonen. Datenbanken müssen verbunden und aktuell sein. Ohne sorgfältige Organisation ist verteilte Entwicklung eine Einladung zum Chaos. 32
Verteilte Versionshaltung Tokyo: Kanji- Lokalisierung New York: Oberfläche Stuttgart: Hauptprogramm 33
Verteilte Versionshaltung New York GUI.0 GUI.0 Tokyo GUI.1 Kanji.1 GUI.2 Kanji.2 Kanji.3 Kanji.3 GUI.3 Kanji.4 GUI.3 GUI.4 Kanji.5 Kanji.6 Kanji.6 GUI.5 34
9. Ausblick Stand der Kunst: Speichern und Verfolgen von Änderungen. Zuverlässige, wiederholbare Versionsselektion. Automatische Konfigurationsbearbeitung (Make und Make-oids) Verknüpfung von Änderungswünschen mit Änderungen. 35
Ausblick Wo ist weitere Entwicklungsarbeit nötig? Verteiltes SKM, Software-Distribution, Installation im Netz, Automatische Konfiguration, Erweiterte Prozeßunterstützung, Versionierung von Webs. 36
Schluß SKM ist eine etablierte Disziplin von anerkanntem, praktischem Nutzen. Werkzeuge mit unterschiedlichem Komfort erhältlich. Es gibt eine Reihe von neuen Herausforderungen. SKM-Werkzeuge sind oft technisch anspruchsvoll. 37
Fragen? 38