Software- Konfigurationsmanagement (Software Configuration Management)

Transkript

1 Software- Konfigurationsmanagement (Software Configuration Management)

2 Definition Software-Konfigurationsmanagement (SKM) ist die Disziplin zur Verfolgung und Steuerung der Evolution von Software. W. Tichy

3 Gliederung 1) Einführung 2) Geschichte 3) Planung 4) Change Management 5) Konfigurationsprüfung 6) Versions- und Releasekontrolle 7) System Building

4 Gliederung 1) Einführung 2) Geschichte 3) Planung 4) Change Management 5) Konfigurationsprüfung 6) Versions- und Releasekontrolle 7) System Building

5 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

6 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

7 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

8 Gliederung 1) Einführung 2) Geschichte 3) Planung 4) Change Management 5) Konfigurationspüfung 6) Versions- und Releasekontrolle 7) System Building

9 Entwicklung des SKM SKM hat sich aus klassischem KM entwickelt KM ca für US-Luft- und Raumfahrt entwickelt Wurde zunächst manuell durchgeführt Anfänge des Software KM ca (SCCS, MAKE) 1986 CVS Heute erfolgreicher Teil des Software- Werkzeugemarktes

10 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

11 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

12 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

13 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

14 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

15 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

16 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

17 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

18 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

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

20 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

21 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

22 Change Management Zusammenfassung [Quelle:

23 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

24 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?

25 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

26 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

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

28 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

29 Versions- und Releasekontrolle Versionsidentifikation Lineares Schema (1.0, 1.1,..., 2.0, ) 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

30 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

31 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

32 Versions- und Releasekontrolle Versionskontrolle - Ablauf 1) 2) 5) 6) 3) 4) 7) 8) Quelle: [6]

33 Versions- und Releasekontrolle Versionskontrolle - Begriffe Tags Branches Trunk [Quelle:

34 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

35 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

36 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

37 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

38 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?

39 System Building Problem: Viele Komponenten / Quellen mit unterschiedlichen Abhängigkeiten. Lösung: Build-Tools, z.b: Make Ants Maven

40 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

41 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

42 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

43 System Building Cruise Control (2) Quelle: [7]

44 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] [5] management/mee [6] [7] [8]

45 Software - Konfigurationsmanagment 1) Einführung 2) Geschichte 3) Planung 4) Change Management Fragen? 5) Konfigurationsprüfung 6) Versions- und Releasekontrolle 7) System Building