Konfigurationsmanagement. Referat im Fachgebiet Software Engineering Referent: Philipp Schwarzhuber Datum: 11. November 2002

Größe: px

Ab Seite anzeigen:

Download "Konfigurationsmanagement. Referat im Fachgebiet Software Engineering Referent: Philipp Schwarzhuber Datum: 11. November 2002"

Pamela Siegel
vor 8 Jahren
Abrufe

1 Referat im Fachgebiet Software Engineering Referent: Philipp Schwarzhuber Datum: 11. November 2002

2 - Inhalt - Überblick - Problemstellung - Standards - Artefakte - Erstellung des KM-Plans - Umsetzung des KM-Plans - Artefakte im KM-System - Ablage und Workflow - Datenablage - Beispielsystem CVS Überblick Anwendung Problem: Merging - Quellenangaben Seite 2

KM-System - Ablage und Workflow - Datenablage - Beispielsystem

3 Überblick - ist die versionierte Verwaltung aller Artefakte eines Softwareprojekts. Sie erlaubt eine Verfolgung und Steuerung der Evolution einer Software - Artefakte sind alle mit einem Softwareprojekt in Zusammenhang stehenden Dokumente (SourceCode [Code, Content, Layout], Dokumentation, Modelle, Anforderungen, Tests) Seite 3

sind alle mit einem Softwareprojekt in Zusammenhang stehenden Dokumente

4 Problemstellung - Software ändert sich ständig (Entwicklung, Wartung, Änderungen) - Verteilte Entwicklungsteams haben Koordinationsprobleme bei konkurrierender Arbeit an gleichen Artefakten des Projekts ( last save wins ) - Komplexe Abhängigkeiten zwischen Software-Modulen führen zu aufwendigen Abstimmungen bei Änderungen Es entstehen verschiedene Versionen der Software (chronologische, aber auch parallele). Diese Entwicklung kann schnell im Chaos enden. Einführung des KM ermöglicht flüssige Koordination und nachvollziehbare Speicherung von Versionen Seite 4

zu aufwendigen Abstimmungen bei Änderungen Es entstehen verschiedene Versionen der Software (chronologische, aber auch parallele).

5 Standards - Es existiert kein wirklicher KM-Standard - Einigkeit herrscht nur in den Rahmenbedingungen KM unbedingt notwendig, auch bei kleinen Projekten Frühzeitiges KM wichtig, nicht erst in der Codierungsphase KM-Plan und Regelwerke zur Nutzung unverzichtbar - Begriffsdefinitionen sind nicht eindeutig und werden häufig für unterschiedliche Sachverhalte gebraucht - Im Weiteren: Begriffe nach Versteegen: Softwaremanagement (Artefakt-Linie) [VERSTE(2002)] Seite 5

Regelwerke zur Nutzung unverzichtbar - Begriffsdefinitionen sind nicht eindeutig und werden häufig für

6 Artefakte - Artefaktorientiertes KM Ein Artefakt eines bestimmten Typs wird versioniert gespeichert. An ihm können Entwickler Änderungen (Aktivitäten) vornehmen. leicht aufzusetzen unflexibel in komplexen Projekten - Aktivitätsorientiertes KM Es werden Aktivitäten in Prozessabläufen gespeichert, die sich auf Artefakte auswirken; das heißt der Entwickler kann Aktivitäten meist in der ganzen Fülle der Artefakte vornehmen große Freiheit (großes Risiko) für den Entwickler unübersichtlich Kombination der beiden Systeme je nach Komplexität und Größe des Projekts Seite 6

leicht aufzusetzen unflexibel in komplexen Projekten - Aktivitätsorientiertes KM Es werden Aktivitäten in Prozessabläufen gespeichert, die

7 Erstellung des KM-Plans - Zeitpunkt: in einer sehr frühen Phase des Projekts, noch vor der eigentlichen Konzeptionierung. Extreme Position: KM-Plan muss entstehen bevor das erste Artefakt des Projektes entsteht. - Beteiligte: Projektmanagement, KM-Verantwortliche, Produktions- und Releaseverantwortliche, IT-Abteilung. Bennennung eines KM- Verantwortlichen - Planung der KM-Workflows Erzeugen, Verändern und Löschen von Artefakten und Metainformationen (Benennungen, Label zu Artefakten) Art und Umfang von Branching und Merging Zugriffsregeln auf die Artefakte Erzeugung von reproduzierbaren Projektständen (Baselines) Freigabeprozeduren und Auslieferung Seite 7

- Beteiligte: Projektmanagement, KM-Verantwortliche, Produktions- und Releaseverantwortliche, IT-Abteilung.

8 Erstellung des KM-Plans - Planung der Infrastruktur Aufbau und Struktur der Datenablage (Server) Zugriffsregeln und Verantwortlichkeit für die Server Datensicherung Ausfallsicherheit (Worst-Case-Szenarien, Monitoring und Eskalationsprozeduren) - Entwicklung einer Hierarchie von Verantwortlichen und Ansprechpartnern Entscheidung für das geeignete Werkzeug/Systemumgebung Seite 8

(Worst-Case-Szenarien, Monitoring und Eskalationsprozeduren) - Entwicklung einer Hierarchie

9 Umsetzung des KM-Plans - Aufbau der im KM-Plan festgelegten Strukturen - Implementierung des KM-Tools Aufbau und Inbetriebnahme der Server Datenstrukturen anlegen, erste Artefakte übernehmen Anpassen des KM-Tools nach Maßgabe des KM-Plans Workflow- und Roll-out-Pläne umsetzen und testen Client als Muster aufsetzen und testen Seite 9

anlegen, erste Artefakte übernehmen Anpassen des KM-Tools nach Maßgabe des KM-Plans

10 Artefakte im KM-System - Früher: KM dient nur zur Versionierung des Sourcecodes - Heute: Ablage aller Artefakte, die für das Projekt relevant sind und reproduzierbar sein müssen im KM-System: Sourcecode Planungsdokumente, Modelle Testumgebung (Skripte, Testdaten und Testpläne) Binäre Daten (Grafiken) Third-Party-Software (Bibliotheken, Entwicklungswerkzeuge) Auch: Executables der Projektsoftware - Auch die nicht-sourcecode-objekte müssen in Freigabe- und Releaseprozeduren miteinbezogen werden Kernaussage: Alles was zur Reproduzierbarkeit notwendig ist, muss ins KM-System Seite 10

(Grafiken) Third-Party-Software (Bibliotheken, Entwicklungswerkzeuge) Auch: Executables der Projektsoftware - Auch die nicht-sourcecode-objekte

11 Ablage und Workflow - Baselining Anwendung bei starken Querverbindungen der Artefakte, wobei ein Gesamtstand einer Version zur Reproduktion notwendig ist Anwendung heute: bei Anforderungsdokumenten und Dokumentation - Versionierung Anwendung, wenn jede Version reproduzierbar sein muss Nur ein Anwender kann zum gleichen Zeitpunkt das Artefakt ändern Allein die Versionierung ist heute selten im Einsatz (Ausnahme: Embedded Software), da kürzer werdende Innovationszyklen das parallele Entwickeln erzwingen - Varianten Artefakt von mehreren Anwendern gleichzeitig bearbeitbar Problem: Zusammenführung von Änderungen ( merge ) Seite 11

gleichen Zeitpunkt das Artefakt ändern Allein die Versionierung ist heute selten im Einsatz (Ausnahme: Embedded Software), da kürzer werdende

12 Datenablage - Zentrales Archiv Nutzer sperrt Artefakt während Bearbeitung Single-Point-of-failure - Lokale Kopien Synchronisation nötig Infrastruktur an jedem Standort nötig - Mischform Entwickler arbeiten mit lokalen Kopien eines zentralen Datenbestandes Seite 12

Synchronisation nötig Infrastruktur an jedem Standort nötig -

13 Beispielsystem: CVS - CVS Concurrent Versions System - Eigenschaften Gleichzeitiger Zugriff mehrerer Nutzer Verschmelzungsfunktion ( merging ) Mehrere Entwicklungslinien möglich ( branching ) Diff-Funktion (Deltas zwischen Versionen) Event-Trigger - Nachteile / Probleme Keine Verwaltung von Konsistenzbeziehungen zwischen verschiedenen Artefakten Erkennt Konflikte bei Merging, kann sie aber nur bedingt beheben Seite 13

(Deltas zwischen Versionen) Event-Trigger - Nachteile / Probleme Keine Verwaltung von

14 Beispielsystem: CVS - CVS-Server Client des Entwicklers - (public repository) (private workspace) Check Out Check In Funktionen Checkout: Commit: Update: Erstellt private, lokale Kopie des Artefakts Übermittelt Artefakt nach Änderung zurück an Server Vergleicht lokale Kopie mit Repository auf dem Server Seite 14

Erstellt private, lokale Kopie des Artefakts Übermittelt Artefakt nach

15 Beispielsystem: CVS Beispiel: Änderung des Artefakts helloworld.c im Repository world mit dem CVS commandline-tool 1. Verbindung konfigurieren # setenv CVSROOT /test/src 2. Lokale Kopie des Repository erstellen # cvs checkout world 3. Editieren der Datei helloworld.c im Verzeichnis world # cd world # vi helloworld.c 4. Testen der Änderung, ggf wieder editieren # gcc helloworld.c &&./a.out 5. Lokale Kopie mit Repository auf dem Server vergleichen # cvs update 6. Falls ein merging stattgefunden hat evtl weitere Tests 7. Übermitteln der Änderungen # cvs commit helloworld.c Seite 15

Editieren der Datei helloworld.c im Verzeichnis world # cd world # vi helloworld.c 4. Testen der Änderung, ggf wieder editieren # gcc helloworld.

16 Beispielsystem: CVS Unwahrscheinlich, aber möglich: Function P (int a,b) { if (a < b) {... } } Function P (int v,w) { Function P (int a,b) { int a; if (a < b) {... } while (v < w) {... } elseif (a == b) {... } } } Function P (int v,w) { int a; while (v < w) {... } elseif (a == b) {... } } Syntaktisch falsch Semantisch falsch - Nach [SCHÜRR], S.451 Seite 16

17 Quellenangaben [VERSTE] Versteegen, G. (Hrsg.), Software Management, Springer Verlag Heidelberg (2002) [SCHÜRR] Schürr, A., Software Engineering I, Universität der Bundeswehr München, Vorlesungsskript [CVSHOME] Seite 17

Ähnliche Dokumente

Versionsverwaltung GIT & SVN. Alexander aus der Fünten. Proseminar: Methoden und Werkzeuge, SS 2012. Lehrstuhl i9, Prof. Dr. T.

Versionsverwaltung GIT & SVN. Alexander aus der Fünten. Proseminar: Methoden und Werkzeuge, SS 2012. Lehrstuhl i9, Prof. Dr. T. Versionsverwaltung GIT & SVN Alexander aus der Fünten Proseminar: Methoden und Werkzeuge, SS 2012 Lehrstuhl i9, Prof. Dr. T. Seidl RWTH Aachen Ablauf Was ist Versionsverwaltung? Arbeitsmodelle Lokale,