Versionsverwaltung von Softwareartefakten Dr. Thorsten Arendt Marburg, 06. November 2014
Ü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 2014/2015
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 2014/2015
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 2014/2015
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 2014/2015
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 2014/2015
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 2014/2015
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 2014/2015
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 2014/2015
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 2014/2015
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 2014/2015
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 2014/2015
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 2014/2015
Verschiedene Revisionszweige Gründe für mehrere Zweige (Branches): 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 14 Software-Evolution WS 2014/2015
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/1.0.1 15 Software-Evolution WS 2014/2015
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 Datei-Explorer TortoiseSVN 16 Software-Evolution WS 2014/2015
Typische Befehle in SVN Arbeitskopie auf den neuesten Stand bringen: svn update Änderungen an der Ordnerstruktur durchführen: svn add svn delete svn copy svn move Änderungen prüfen: svn status svn diff Änderungen zurücknehmen (optional): svn revert Konflikte auflösen: svn update svn resolved Änderungen in das Repository einlesen: svn commit 17 Software-Evolution WS 2014/2015
Revisionsänderungen im Arbeitsordner svn commit schreibt lokale Änderungen in das Repository, checkt aber keine Änderungen aus. svn update holt neue Änderungen aus dem Repository und mischt sie in die lokale Kopie, checkt aber keine lokalen Änderungen ein. Datei im Arbeitsordner ist lokal unverändert und aktuell: svn commit und svn update tun nichts. geändert und aktuell: svn update tut nichts, svn commit checkt die Änderungen ein. unverändert, aber veraltet: svn commit tut nichts, aber svn update fügt die neuesten Änderungen aus dem Repository ein. geändert und veraltet: Die Datei ist lokal und im Repository geändert worden. svn commit bricht mit out-of-date ab. svn update versucht beide Versionen zu mischen. 18 Software-Evolution WS 2014/2015
Beispiel für einen Statusbericht svn status 19 Software-Evolution WS 2014/2015
Konfliktlösung Mit svn resolve kann ein Konflikt aufgelöst werden. Alternativen zur Konfliktlösung: base: zurück zur Originalversion mine-full: Meine Version soll es sein. theirs-full: Die Repository-Version soll es sein. working: Konflikte werden von Fall zu Fall gelöst. Anschließend nochmal svn update, um Konfliktfreiheit zu prüfen. 20 Software-Evolution WS 2014/2015
Subversion in Eclipse Eclipse Plugins: Subversive, Subclipse Wechsel zur SVN Repository Exploring Perspective Für das Arbeiten mit einem bestehenden Repository muss die Repository Location angegeben werden: New Repository Location Neues Repository anlegen: New Repository Für den Import eines bestehenden Projekts in das SVN Repository: Import [Subversive] 21 Software-Evolution WS 2014/2015
Subversion in Eclipse Im SVN Repository Explorer: Checkout lädt eine bestimmte Revision aus dem Repository herunter. Lokales Arbeiten in der Java-Perspektive. SVN-Befehle unter Team Überblick über Änderungen im Projekt: Window Open Perspective Other..., dort Team Synchronizing Die Team Synchronization Perspective wird gestartet. [Subclipse] 22 Software-Evolution WS 2014/2015
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 23 Software-Evolution WS 2014/2015
Aufbau eines zentralen Repository Ein zentrales Repository für die Arbeitsgruppe z.b. in der Cloud [Atlassian SourceTree] Lokale Arbeitsbereiche oder lokale Repositories [Bitbucket] 24 Software-Evolution WS 2014/2015
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] 25 Software-Evolution WS 2014/2015
Clone eines Git Repository Um eine lokale Kopie des entfernten Repository zu erstellen Auswahl einzelner Branches Angabe des lokalen Ordners [EGit] 26 Software-Evolution WS 2014/2015
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. 27 Software-Evolution WS 2014/2015
Entferntes Repository 28 Software-Evolution WS 2014/2015
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> 29 Software-Evolution WS 2014/2015
Versionen als Schnappschüsse [ProGit] Version: Mini-Dateisystem in einem Zustand Unveränderte Dateien werden nicht kopiert. Git fügt nur Daten hinzu. 30 Software-Evolution WS 2014/2015
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] 31 Software-Evolution WS 2014/2015
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] 32 Software-Evolution WS 2014/2015
Branches (2) Der Default-Branch heisst master. Zwei Branches können auf denselben Schnappschuss verweisen. Der aktuelle Branch heisst HEAD. 33 Software-Evolution WS 2014/2015
Branches (3) Die Historie läuft auseinander: Beispiel: master -Branch testing -Branch Der Nutzer kann beliebig zwischen den Branches wechseln. die Branches zusammenführen [ProGit] 34 Software-Evolution WS 2014/2015
Beispiel für Branches http://nvie.com/posts/a-successful-git-branching-model/ 35 Software-Evolution WS 2014/2015
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? 36 Software-Evolution WS 2014/2015
Versionierung in verschiedenen Entwicklungsprozessen (1) Kleines Projekt Kleines Team Ein zentrales Repository Jedes Team-Mitglied darf alle Dateien lesen und schreiben. Bekanntes Modell [Kamann] 37 Software-Evolution WS 2014/2015
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] 38 Software-Evolution WS 2014/2015
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] 39 Software-Evolution WS 2014/2015
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. 40 Software-Evolution WS 2014/2015
Sekundär-Literatur Ben Collins-Sussman, Brian W. Fitzpatrick, C. Michael Pilato: Version Control with Subversion, 2011, online erhältlich unter http://svnbook.red-bean.com/ Apache Subversion: http://subversion.apache.org/ Subversive: http://www.eclipse.org/subversive/ Subclipse: http://subclipse.tigris.org/ Scott Chacon, Ben Straub: ProGit, 2nd Edition, 2014, online erhältlich unter http://git-scm.com/book GitHub: http://github.com/ Bitbucket: http://bitbucket.org/ Atlassian SourceTree: http://sourcetreeapp.com/ EGit: http://www.eclipse.org/egit/ Thorsten Kamann: GIT oder Subversion? Sei kein Depp!, Eclipse Magazin, Ausgabe 1-2011 41 Software-Evolution WS 2014/2015