Software- Konfigurationsmanagement (Software Configuration Management)
Definition Software-Konfigurationsmanagement (SKM) ist die Disziplin zur Verfolgung und Steuerung der Evolution von Software. W. Tichy
Gliederung 1) Einführung 2) Geschichte 3) Planung 4) Change Management 5) Konfigurationsprüfung 6) Versions- und Releasekontrolle 7) System Building
Gliederung 1) Einführung 2) Geschichte 3) Planung 4) Change Management 5) Konfigurationsprüfung 6) Versions- und Releasekontrolle 7) System Building
Einführung Große Software Systeme sind Konfigurationen einzelner Komponenten, die sich mit der Zeit (unabhängig voneinander) entwickeln Verschiedene Konfigurationen können existieren Unterschiedliche Hardware, Betriebssysteme, etc. SKM unerlässlich für Entwicklung und Pflege großer und langlebiger Softwaresysteme
Einführung (2) Situation ohne SKM: Korrigierte Bugs tauchen wieder auf Ältere Releases können nicht wieder gebaut werden Dateien gehen verloren Dateien ändern sich auf mysteriöse Weise Gleicher oder ähnlicher Code existiert mehrmals in verschiedenen Projekten Mehrere Entwickler ändern die selbe Datei versehentlich gleichzeitig
Einführung (3) Entwicklung sollte auf festgelegten Standards beruhen Hilft Chaos zu vermeiden: Macht Entwicklungsgeschichte rückverfolgbar Verhindert bzw. gleicht überschneidende Änderungen ab Überwacht Konfigurationen und Releases Verfolgt Fehlermeldungen und Korrekturen Automatisiert Versionsselektion => hält Software in wohldefiniertem Zustand
Gliederung 1) Einführung 2) Geschichte 3) Planung 4) Change Management 5) Konfigurationspüfung 6) Versions- und Releasekontrolle 7) System Building
Entwicklung des SKM SKM hat sich aus klassischem KM entwickelt KM ca. 1950 für US-Luft- und Raumfahrt entwickelt Wurde zunächst manuell durchgeführt Anfänge des Software KM ca. 1970 (SCCS, MAKE) 1986 CVS Heute erfolgreicher Teil des Software- Werkzeugemarktes
Entwicklung des SKM (2) Unterschiede gegenüber klassischem KM: Software ist billiger zu ändern, ändert sich schneller => SKM muss schneller reagieren Software kann komplett im Rechner gespeichert werden => SKM ist automatisierbar
Gliederung 1) Einführung 2) Geschichte 3) Planung Grundbegriffe Identifikation der Konfigurationselemente Konfigurationsdatenbank 4) Change Management 5) Konfigurationsprüfung 6) Versions- und Releasekontrolle 7) System Building
Planung (Configuration Management Planning) Plan enthält: Welche Elemente sollen verwaltet werden, formelles Identifikationsschema Verantwortlichkeiten SKM Richtlinien für Versions- und Änderungskontrolle Beschreibung der Aufzeichnungen/Protokolle des SKM Prozesses Tools Definition der Konfigurationsdatenbank
Planung Grundbegriffe Konfigurationselement, KE (Software Configuration Item): jede maschinenlesbare Informationseinheit ( Dokument ), die im Laufe eines Softwareprojektes entsteht => Software ist eine Sammlung von Konfigurationselementen Baseline: Referenzpunkt in der Entwicklung eines Systems Startpunkt für kontrollierte Entwicklung
Planung Identifikation (1) Tausende Dokumente werden während Entwicklung produziert Welche Elemente sollen überhaupt verwaltet werden? Jedes Softwareelement muss eindeutig identifiziert werden -> Namensschema muss festgelegt werden
Namenschema Typisch: Planung Identifikation(2) Hierarchisches Schema z.b.: PCL-Tools/Edit/Forms/Display/Code PCL-Tools/Edit/Help/Query/HelpFrames Mögliches Problem: Komponenten sollen in verschiedenen Projekten wiederverwendet werden
Planung Konfigurationsdatenbank Sämtliche KM-relevanten Informationen Enthält z.b. Informationen über: Welche Kunden haben welche Version? Welche Hardware/BS benötigt für best. Version? Wieviele Versionen gibt es? Erstellungsdatum? Welche Versionen von Änderung an Komponente betroffen? Ausstehende Änderungsanträge für Komponente Gemeldete Fehler einer best. Version
Gliederung 1) Einführung 2) Geschichte 3) Planung 4) Change Management Änderungsanfrage Aufwandsschätzung Change Control Board 5) Konfigurationsprüfung 6) Versions- und Releasekontrolle 7) System Building
Change Management Alle Änderungen werden zunächst als Änderungswunsch eingegeben => Verhindert Änderungschaos Verknüpfung zwischen Änderungswünschen, Versionen und Korrekturen Verwaltung der Änderungen und sicherstellen das sie in der kosteneffizientesten Weise implementiert werden
Change Management Änderungsanfrage Vom Kunden oder Entwickler Ist selbst Konfigurationselement Anfrage enthält: Autor Beschreibung der Änderung Grund der Änderung Dringlichkeit Information wird in Konfigurationsdatenbank archiviert Überprüfung auf Gültigkeit nötig: Evtl.: Missverständnisse, Fehler schon bekannt...
Change Management Aufwandsschätzung Auswirkung der Änderung auf Gesamtsystem Technische Analyse (wie ist Änderung umzusetzen / zu implementieren) Abschätzen der Kosten der Änderung und evtl. benötigte Änderungen anderer Komponenten Eintragen der Ergebnisse in Änderungsanfrage
Change Management Change Control Board (CCB) Auch Configuration Control Board Entscheidet ob Änderung durchgeführt wird Externe Gruppe, unabhängig von Entwicklern Strategische, Organisations-Sichtweise, keine technische Größe des CCB ist abhängig von Größe des Softwareprojektes
Change Management Zusammenfassung [Quelle: http://www.hst.fhso.ch/archiv/2001/swe/modules/ch13-confmgmt/scm%20lecture%20notes.pdf]
Gliederung 1) Einführung 2) Geschichte 3) Planung 4) Change Management 5) Konfigurationsprüfung Konfigurationsprüfung Status Accounting 6) Versions- und Releasekontrolle 7) System Building
Konfigurationsprüfung (Configuration Auditing) Regelmäßige Überprüfung in wie weit der momentane Zustand des Systems dem in dokumentierten Baselines und Anforderungen entspricht Typen von Prüfungen: Stimmt System mit Spezifikation überein? Stimmt System mit Dokumentation überein?
Konfigurationsprüfung (2) Status Accounting Sammeln von Informationen die für den Managementprozess benötigt werden ->Status Accounting Überwachen aller KEs unter Kontrolle Änderungen am System nicht in Echtzeit Macht die Historie des Entwicklungsprozesses nachverfolgbar
Gliederung 1) Einführung 2) Geschichte 3) Planung 4) Change Management 5) Konfigurationsprüfung 6) Versions- und Releasekontrolle Grundbegriffe Versionskontrolle Tools zur Versionskontrolle Releaseverwaltung 7) System Building
Versions- und Releasekontrolle Identifikation und Beobachtung von unterschiedlichen Versionen und Releases eines System Typische Fragen: Wie schließe ich fehlerhafte Änderungen wieder aus? Welche Änderungen sind denn nun in diesem Release? Welche Konfiguration hat der Kunde? Der Kunde hat die letzten Releases nicht installiert, was passiert wenn wir ihm die neue schicken? usw...
Versions- und Releasekontrolle Grundbegriffe Version Instanz eines Systems die sich von anderen unterscheidet in Performance, Funktionalität, Fehlerbehebung oder Zielsystem (Auch Elemente haben Versionen) Release Eine Version die an Kunden ausgeliefert wird Installierbare und ausführbare Konfiguration von KE's Enthält: Konfigurationsdateien, Datendateien, Installationsprogramm, Dokumentation
Versions- und Releasekontrolle Versionsidentifikation Lineares Schema (1.0, 1.1,..., 2.0, 2.1...) Probleme Wann neues Release, statt Version kreieren Mehrere Versionen von gleicher Wurzel Jeder Kunde oder Benutzer kann einzigartige Version des Systems haben Symbolisches Namensschema Identifikation durch Attribute
Versions- und Releasekontrolle Versionskontrolle (3) Vorteile: Automatisierbar durch Tools Gleichzeitiger Zugriff mehrerer Entwickler auf die selben Softwareelemente Änderungen werden protokolliert Alte Revisionen jederzeit wiederherstellbar Server enthält Repository an zentraler Stelle Zugriff auf beliebige Vorgängerversionen
Versions- und Releasekontrolle Versionsverwaltungstools Automatische Versionierung Effizientes Speichermanagement Differenzielles Speichern der Änderungen Änderungshistorie wird aufgezeichnet Unabhängige Entwicklung Paralleles Arbeiten an den selben Elementen ist möglich 'Mergen' bei Konflikten
Versions- und Releasekontrolle Versionskontrolle - Ablauf 1) 2) 5) 6) 3) 4) 7) 8) Quelle: [6]
Versions- und Releasekontrolle Versionskontrolle - Begriffe Tags Branches Trunk [Quelle: https://eclipse-tutorial.dev.java.net/eclipse-tutorial/part2.html]
Versions- und Releasekontrolle Subversion Vorteile: Gesamter Zustand des Repository mit Revisionsnummer gekennzeichnet (nicht jede Datei einzeln) Historie bleibt beim Kopieren des Repository erhalten Atomare Commits Apache Plugin Sowohl Text als auch binäre Daten Effizientes Branching und Taggen
Versions- und Releasekontrolle Releaseverwaltung Komplexer und teurer als Versionserstellung Häufige Änderungen produzieren Fehler Zwischenrelease zur Fehlerkorrektur Abwechseln von Fehlerkorrektur und neuer Funktionalität Mischen kann zu Problemen führen Problem: Release kann nicht angewiesen sein auf Existenz vergangener Releases
Gliederung 1) Einführung 2) Geschichte 3) Planung 4) Change Management 5) Konfigurationsprüfung 6) Versions- und Releasekontrolle 7) System Building Einführung Probleme und Tools
System Building (1) Das Kompilieren und Verlinken von Software- Komponenten zu einem ausführbaren System Automatisierung möglich Für große Systeme, teurer (zeitaufwändiger) Prozess Hunderte Dateien involviert
System Building (2) Typische Fragen: Sind alle Komponenten in den Build- Anweisungen enthalten? Wird die richtige Version aller Komponenten in Anweisungen verwendet? Sind alle Daten-Dateien vorhanden? Sind die Namen die gleichen wie auf Zielsystem? Richtige Version von Compiler und Tools vorhanden?
System Building Problem: Viele Komponenten / Quellen mit unterschiedlichen Abhängigkeiten. Lösung: Build-Tools, z.b: Make Ants Maven
System Building Maven Nicht bloßes Build-Management: Spezifikation, Ausführung, Report von Unit-Tests Teil des normalen Build-Zyklus Abstrahiert von den Details des Build-Prozesses Vereinfacht Verwaltung von Multi-Projekten durch einheitliches Build System Gibt Projektinformationen Konfiguriert durch POM-(Project Object Model) Datei
System Building Continuous Build Problem: Wie oft sollte ein Build durchgeführt werden? Je seltener, desto komplizierter. Nach jeder Änderung: Continous Integration Aufruf des Build-Tools und Überwachung automatisiert Nach jeder Änderung wird Build ausgeführt Automatische Tests Tool: z.b. Cruise Control
System Building Cruise Control Überwachen der Repositories Flexibles Einstellen der Build-Zeiten 3 Hauptmodule: Build-Loop Kern des Systems Führt Build-Schleifen aus, Benachrichtigt User Konfiguriert durch XML- Datei Legacy Reporting Erlaubt Usern die Ergebnisse der Builds durchzusehen Dashboard Visuelle Repräsentation des Status aller Projekt- Builds
System Building Cruise Control (2) Quelle: [7]
Quellen [1] I. Sommerville Software Engineering, 8 th Ed. [2] Dorfman, A. Ackerman Software Engineering [3] Bersoff, Henderson, Siegel, Software Configuration Management, ACM SIGMETRICS Performance Evaluation Review, Volume 7 [4] http://www.ipd.uni-karlsruhe.de/~tichy/scm/ [5] http://en.wikipedia.org/wiki/software_configuration_ management/mee [6] http://svnbook.red-bean.com/ [7] http://cruisecontrol.sourceforge.net/index.html [8] http://maven.apache.org/
Software - Konfigurationsmanagment 1) Einführung 2) Geschichte 3) Planung 4) Change Management Fragen? 5) Konfigurationsprüfung 6) Versions- und Releasekontrolle 7) System Building