Versionsverwaltung von Softwareartefakten. Dr. Thorsten Arendt Marburg, 05. November 2015

Transkript

1 Versionsverwaltung von Softwareartefakten Dr. Thorsten Arendt Marburg, 05. November 2015

2 Überblick Warum ist die Versionsverwaltung von Softwareartefakten wichtig? Wie verwaltet man Softwareartefakte? Versionskontrolle für Anforderungsdokumente, Modelle, Code, Testdateien, Dokumentationen, etc. Möglichst unabhängiges Arbeiten im Team Wie erhält man konsistente Konfigurationen? Einführung in Versionsverwaltungswerkzeuge Subversion (SVN): Zentrale Verwaltung von Dateien und Ordnern Git: Verteilte Versionsverwaltung 2 Software-Evolution WS 2015/2016

3 Versionsprobleme Vermeide Fragen und Probleme wie diese: Welche ist die neueste Version eines Softwaresystems? Ich kann eine ältere Version der Software nicht finden. Ich kann eine bestimmte Version des Softwaresystems nicht erstellen, weil bestimmte Dateien fehlen. Eine gerade erstellte Datei wurde von einer älteren Version überschrieben, weil gerade nicht aufgepasst wurde. sie parallel geändert wurde. 3 Software-Evolution WS 2015/2016

4 Gründe für Versionsprobleme Software ist einfach zu ändern. Mehrere Personen dürfen dieselben Artefakte ändern, eventuell sogar zur gleichen Zeit. Es ist einfach, Inkonsistenzen zu erzeugen. schwer erkennbare Fehler zu erzeugen. Beispiele: Zwei Entwickler führen unabhängig voneinander Änderungen an verschiedenen Klassen durch. Diese passen nicht zueinander. Source Code geändert: Binärcode, Design, Dokumentation und Tests werden inkonsistent. 4 Software-Evolution WS 2015/2016

5 Motivation für klassische Versionsverwaltung Ein Versionsverwaltungssystem soll das gemeinschaftliche Arbeiten an Dokumenten ermöglichen. Hauptproblem: Wie ermöglicht das Versionsverwaltungssystem den Nutzern Zugang zu gemeinsamen Dokumenten, ohne versehentlich Informationen zu löschen? Ansatz: Alle gemeinschaftlich genutzten Dokumente werden in einem Repository (einem speziellen Datenbehälter) verwaltet. Die Nutzer bekommen Lese- bzw. Schreibzugang zu Dokumenten im Repository. Werkzeuge: CVS, SVN, Git, etc. 5 Software-Evolution WS 2015/2016

6 Das Problem Zwei Nutzer (Harry und Sally) entscheiden sich, an demselben Dokument (A) zu arbeiten. Beide führen verschiedene Änderungen an ihren lokalen Versionen des Dokuments durch. Die lokalen Versionen werden nacheinander in das Repository geschrieben. Sally überschreibt dadurch eventuell Änderungen von Harry. [Version Control with Subversion] 6 Software-Evolution WS 2015/2016

7 Problemlösung 1: Sperren von Dokumenten Harry sperrt das Dokument und arbeitet lokal daran. Sally möchte das Dokument lesen, es ist aber gesperrt. Harry schreibt sein geändertes Dokument ins Repository und entsperrt es. Sally kann nun das Dokument lesen und für andere sperren. [Version Control with Subversion] 7 Software-Evolution WS 2015/2016

8 Wie gut ist Problemlösung 1? Administrative Probleme Gesperrte Dokumente werden vergessen zu entsperren. Andere Nutzer kommen an die gesperrten Dokumente nicht ran. Unnötige Sequentialisierung der Arbeit Wenn zwei Nutzer ein Dokument an verschiedenen Stellen ändern möchten, könnten sie dies auch gleichzeitig tun. Falsches Gefühl von Sicherheit Zwei Nutzer arbeiten getrennt auf den Dokumenten A und B. Was passiert, wenn A von B abhängig ist? A und B passen nicht mehr zusammen. Die Nutzer müssen dieses Problem diskutieren. 8 Software-Evolution WS 2015/2016

9 Problemlösung 2: Mischen von Dokumenten Harry und Sally kopieren das Dokument in ihre lokalen Ordner. Beide arbeiten unabhängig daran. Sally schreibt als Erste das Dokument in das Repository zurück. Harry kann das Dokument nicht zurückschreiben: out of date [Version Control with Subversion] 9 Software-Evolution WS 2015/2016

10 Problemlösung 2: Mischen von Dokumenten Harry vergleicht seine lokale Version mit der aktuellen Version im Repository. Beide Versionen werden gemischt. Die neue (gemischte) Version wird zurückgeschrieben. Die neue Version kann ausgelesen werden. [Version Control with Subversion] 10 Software-Evolution WS 2015/2016

11 Wie gut ist Problemlösung 2? Ein Dokument liegt in zwei Versionen vor. Die Änderungen eines Nutzers überlappen sich mit den Änderungen des zweiten Nutzers. Diese Situation wird Konflikt genannt. Lassen sich zwei Dokumente immer mischen? Die Unterschiede zwischen zwei Versionen lassen sich durch Werkzeuge anzeigen. Ein Nutzer (eventuell in Absprache mit dem zweiten Nutzer) entscheidet jeden einzelnen Konflikt. 11 Software-Evolution WS 2015/2016

12 Problemlösung 2: Mischen von Dokumenten Zwei-Wege-Mischen Drei-Wege-Mischen Zwei unabhängige Dokumente werden gemischt. Dazu müssen Korrespondenzen gefunden werden. Ausgehend von einer Originalversion werden Differenzen berechnet und gemischt. 12 Software-Evolution WS 2015/2016

13 Revisionen Revision: Ein Zustand der zu verwaltenden Softwareartefakte Softwareartefakte sind in Ordnern gegliedert. Versionsverwaltung sollte nicht nur die Dateien, sondern auch die Ordner verwalten. [Version Control with Subversion] 13 Software-Evolution WS 2015/2016

14 Subversion (SVN) Open Source Software 2000 von CollabNet entwickelt Seit 2009 bei Apache Features Versionierung von Ordnern und Dateien Auch das Umbenennen, Erzeugen und Löschen von Ordnern werden festgehalten. Sammlung von Änderungen wird als Transaktion verwaltet. Subversion für Eclipse Subclipse Subversive Subversion im Windows Datei-Explorer TortoiseSVN 14 Software-Evolution WS 2015/2016

15 Git Software für verteilte Versionsverwaltung ohne zentralen Server Lokale Kopie des gesamten Repositories Lokale Funktionalität ähnlich wie bei SVN Neue Features: Versionen als Schnappschüsse eines Mini-Dateisystems Nichtlineare Entwicklung: einfaches Branching und Merging Datenabgleich zwischen verschiedenen Repositories möglich Werkzeuge: Git Cloud Hosting: GitHub, GitLab, BitBucket, etc. Git Client: z.b. Atlassian SourceTree Git in Eclipse: EGit Git im Datei-Explorer: TortoiseGit 15 Software-Evolution WS 2015/2016

16 Aufbau eines zentralen Repository Ein zentrales Repository für die Arbeitsgruppe z.b. in der Cloud [Atlassian SourceTree] Lokale Arbeitsbereiche oder lokale Repositories [Bitbucket] 16 Software-Evolution WS 2015/2016

17 Git in Eclipse Eclipse Plugin: EGit Wechsel zur Git Repository Perspective Versionsverwaltung starten: Neues Git Repository anlegen mit Create Vorhandenes Repository kopieren mit Clone Vorhandenes Projekt in ein neues Repository legen: Team Share Project Lokales Arbeiten in der Java- Perspektive. Git-Befehle unter Team [EGit] 17 Software-Evolution WS 2015/2016

18 Clone eines Git Repository Um eine lokale Kopie des entfernten Repository zu erstellen Auswahl einzelner Branches Angabe des lokalen Ordners [EGit] 18 Software-Evolution WS 2015/2016

19 Laden lokaler Sourcen Push lädt einen lokalen Branch oder eine Reihe von Commits in ein entferntes Repository. zum Veröffentlichen von Beiträgen Pull lädt einen Branch aus einem entfernten Repository. 19 Software-Evolution WS 2015/2016

20 Entferntes Repository 20 Software-Evolution WS 2015/2016

21 Typische Git-Befehle auf lokalem Repository Start der Versionierung: git add <filename> Datei auschecken: git checkout <filename> Versionierungsabfragen: git status (Status der Dateien) git log (Historie) Änderungsanzeige (vor commit) git diff Datei einchecken: git add <filename> ( Index) git commit (indizierte Dateien) git commit a <filename> Datei aus Repository löschen: git rm <filename> 21 Software-Evolution WS 2015/2016

22 Versionen als Schnappschüsse [ProGit] Version: Mini-Dateisystem in einem Zustand Unveränderte Dateien werden nicht kopiert. Git fügt nur Daten hinzu. 22 Software-Evolution WS 2015/2016

23 Austausch zwischen Repositories: Ein Beispielablauf Ein zentrales Repository Lokales Mischen Beispiel: John kann nach Jessica kein Push ausführen. Er muss ihre Änderungen holen und lokal mischen. Das Holen von Änderungen (fetch, pull) führt zu einem neuen Branch. Das lokale Mischen (merge) führt zwei Branches zusammen. [ProGit] 23 Software-Evolution WS 2015/2016

24 Verschiedene Revisionszweige (Branches) Gründe für mehrere Zweige: Verschiedene Alternativen gleichzeitig ausprobieren Normales Geschäft und größerer Evolutionsschritt Releases Unterscheidung in den zentralen Branch und weiteren Branches 2. Branch Original 1. Branch 3. Branch 24 Software-Evolution WS 2015/2016

25 Branches (1) Commit-Objekt Referenz auf einen Schnappschuss Commit-Objekte zeigen jeweils auf das vorige. Weitere Einträge sind der Autor, der Committer und die Commit-Message [ProGit] 25 Software-Evolution WS 2015/2016

26 Branches (2) Der Default-Branch heisst master. Zwei Branches können auf denselben Schnappschuss verweisen. Der aktuelle Branch heisst HEAD. 26 Software-Evolution WS 2015/2016

27 Branches (3) Die Historie läuft auseinander: Beispiel: master -Branch testing -Branch Der Nutzer kann beliebig zwischen den Branches wechseln. die Branches zusammenführen 27 Software-Evolution WS 2015/2016

28 Merging (1) Merging von aufeinanderfolgenden Commits / Schnappschüssen Fast Forward 28 Software-Evolution WS 2015/2016

29 Merging (2) Merging von auseinander laufenden Commits / Schnappschüssen 3-Wege-Mischen Ein neuer Schnappschuss entsteht Merge Commit Mehrere Vorgänger 29 Software-Evolution WS 2015/2016

30 Rebasing Alternatives Merging von aufeinanderfolgenden Commits / Schnappschüssen Verwendung eines Patches des einen auf den anderen Schnappschuss Anschließender Fast Forward 30 Software-Evolution WS 2015/2016

31 Beispiel für Branches 31 Software-Evolution WS 2015/2016

32 Arbeiten mit Releases Entwicklerteam arbeitet auf dem Hauptzweig. Erstellung eines Release-Zweigs Z.B.: branches/1.0 Team arbeitet parallel: Intensives Testen der Release-Version Neue Features in der Hauptversion (für Version 2.0) Der Release-Zweig bekommt ein Tag und wird releast. Tag: ein Schnappschuss des Projekts Z.B: /tags/1.0.0 Der Release-Zweig wird weiter gepflegt. Z.B.: nach Fehlerbeseitigung /tags/ Software-Evolution WS 2015/2016

33 Versionsmanagement-Aktivitäten Welche Konfigurationselemente haben wir? D.h. Dateien welcher Typen müssen versionsverwaltet werden? Nach welchen Strategien werden die Versionen verwaltet? Nach welchen Änderungen muss eingecheckt werden? Wann darf eingecheckt werden? Wer hat welche Rollen und Verantwortlichkeiten? Welche Personen sind für welche Komponenten zuständig? Welche Werkzeuge sollen benutzt werden? Häufig können nicht alle Dateitypen gleich gut verwaltet werden. Wo liegt das (Haupt-) Repository? 33 Software-Evolution WS 2015/2016

34 Versionierung in verschiedenen Entwicklungsprozessen (1) Kleines Projekt Kleines Team Ein zentrales Repository Jedes Team-Mitglied darf alle Dateien lesen und schreiben. Bekanntes Modell [Kamann] 34 Software-Evolution WS 2015/2016

35 Versionierung in verschiedenen Entwicklungsprozessen (2) Mittelgroßes Projekt Jedes Entwicklerteam hat ein eigenes Repository. Die eigenen Entwickler haben Schreibzugriff. Alle anderen Entwickler haben Lesezugriff. Der Integration Manager liest Änderungen und integriert sie in die Hauptversion. Er hat Schreibzugriff auf das Haupt-Repository. Alle anderen Entwickler haben Lesezugriff. [Kamann] 35 Software-Evolution WS 2015/2016

36 Versionierung in verschiedenen Entwicklungsprozessen (3) Sehr großes Projekt Hunderte von Entwicklern Hierarchische Versionierung Leutnant: Integration Manager für einen Teil des Projekts Diktator: Integration Manager für alle Teile des Projekts Er hat Schreibzugriff auf das Haupt-Repository. [Kamann] 36 Software-Evolution WS 2015/2016

37 Zusammenfassung Wesentliche Features der Versionsverwaltung: Softwareentwicklungs-Artefakte sind ständigen Änderungen unterworfen, die versioniert werden sollen. Unterstützung für nebenläufiges Arbeiten im Team. Konsistente Konfigurationen durch die Versionierung von Ordnern und Dateien Häufiges Commit mit Dokumentation der Änderungen Verteilte Repositories für verteilte Versionskontrolle im Projekt Fortschritt in der Werkzeugentwicklung für Versionsverwaltung: CVS SVN Git Das Arbeiten mit Zweigen ist einfach und billig. Es macht das Arbeiten mit mehreren Releases einfacher. Es erlaubt eine entspannte und sichere Durchführung von Evolutionsschritten. 37 Software-Evolution WS 2015/2016

38 Sekundär-Literatur S. M. Easterbrook, E. E. Beck, J. S. Goodlet, L. Plowman, M. Sharples and C. C. Wood: A Survey of Empirical Studies of Conflict, Easterbrook, S. M. (ed), 1993 CSCW: Cooperation or Conflict?, Springer-Verlag, pp Ben Collins-Sussman, Brian W. Fitzpatrick, C. Michael Pilato: Version Control with Subversion, 2011, online erhältlich unter Apache Subversion: Subversive: Subclipse: Scott Chacon, Ben Straub: ProGit, 2nd Edition, 2014, online erhältlich unter GitHub: Bitbucket: Atlassian SourceTree: EGit: Thorsten Kamann: GIT oder Subversion? Sei kein Depp!, Eclipse Magazin, Ausgabe Software-Evolution WS 2015/2016