Versionskontrolle. Warum?... Und vor allem: Womit?

Transkript

1 Warum?... Und vor allem: Womit?

2 Agenda Motivation & Grundlagen Beispiel: Perforce Beispiel: git Wrap-Up Andreas Knirsch Bettina Kurz-Kalweit Clemens Fischer

3 aka.... Versionsverwaltung Konfigurationsmanagement oder auch... Version Control System (VCS) Revision Control Source Control Software Configuration Management etc.

4 Erfahrungen Was Warum Wie? r e d e i w o...genaus bn Some rights reserved by tantek

5 Unser Ziel: Funktionierendes System b Some rights reserved by wwarby

6 Motivation für Verteilte/Parallele Entwicklung Verschiedene Versionen in Betrieb Traceablility (Code Change/Feature Requests) Rollback/Back-In-Time/Diff Unterschied zu anderen Disziplinen: Software kann jederzeit an jeder Stelle geändert werden! hohe Dynamik möglich!!

7 Motivation für Dynamik in der Entwicklung (und bei der Wartung) von Software kontrollierbar machen! Entwickler UNTERSTÜTZEN!!

8 Grundlagen

9 Terminologie Branch (Entwicklungszweig) um den (Haupt-)Entwicklungszweig aufzuspalten. und um den Code gefahrlos zu ändern. macht ggf. einen Merge notwendig (Integration in den Basiszweig) Tag/Label (Bezeichner) um eine bestimmte Software-Version zu markieren und einfach wieder rekonstruieren zu können.

10 Terminologie: Branches & Tags

11 Terminologie: Merging Branches

12 Softwareentwicklung Das echte Leben sieht leider nicht so aus.

13 Szenario I: Parallele Entwicklung Mehrere Entwickler arbeiten an einer Software Unterschiedliche Fähigkeiten, Verständnis, Ziele, Sprache, etc. Komponentenbasierte Systeme mit unvollständig beschriebenen Schnittstellen ba Some rights reserved by gruntzooki

14 Szenario I: Parallele Entwicklung (II) BIG BANG! Besser: Continuous Integration.. en eh rg Vo es tiv ra ite : st de in m zu er od

15 Szenario I: Parallele Entwicklung (III) BANG BANG BANG

16 Szenario I: Parallele Entwicklung (IV) löst nicht alle der genannten Probleme... aber macht den Entwicklungsprozess transparent und nachvollziehbar. erreichen des Ziels nicht mit weniger Aufwand aber vorhersagbarer!!! b Some rights reserved by wwarby

17 Szenario II: Wartung Hauptentwicklungszweig mit neuen Features Frühere Versionen noch in Betrieb Kunde benötigt Bugfix für frühere Version Mit kein Problem solange immer schön Tags benutzt wurden :-)

18 Szenario II: Wartung (II) oder Cherry Picking

19 Szenario III: Traceability Üblicherweise sind Anforderungen, bzw. Features mit eindeutigen IDs gekennzeichnet. Auch Fehler sind in einem Bug-/Issuetracker mit eindeutigen IDs gekennzeichnet. Werden diese IDs beim Submit / Commit verwendet, kann der Bezug zur Software einfach und jederzeit aufgelöst werden. Dies gilt besonders für zu Merge/Integration. Hier gilt was auch für Code zutrifft: Kommentare weiß man erst zu schätzen wenn man sie braucht :-)

20 Szenario IV: Rollback/Back-In-Time/Diff Jeder Softwarestand ist wiederherstellbar, solange man sich noch erinnert welchen Stand man benötigt. Dazu braucht man entweder. Datum/Uhrzeit, ID des Commits/Submits oder ein Tag/Label. Kommentare zu den Commits/Submits helfen oft!! Ein Tag mehr schadet nie!! Noch weniger ein Schema für Tags!!

21 Aber... Welches Werkzeug ist das Beste? Wir erinnern uns: Ziel ist ein funktionierendes System :-)

22 Aber... Welches Werkzeug ist das Beste? (II) Projekt ist u.a. gekennzeichnet durch: Aufgabe, Mitarbeiter, Budget, Zeit, Abhängigkeiten/Vorgaben, etc.

23 Aber... Welches Werkzeug ist das Beste? (III) Ergebnis: Mit jedem der vorhandenen Werkzeug ist die hier gestellte Aufgabe lösbar :-)

24 Beispiel: Perforce aka. p4

25 Überblick p4 MS Windows with Visual Studio Linux with Eclipse IDE Mac OSX with Eclipse IDE

26 p4 weitere Features Apache Ant... Redmine Bugzilla Apache Maven Build Tools + CI Tracking System CodeStriker GIT Fusion Code Reviewer Perforce... Third Party Merge/ Diff Tool 3ds IDE Plugin Eclipse Client Application Maya Visual Studio Softimage P4 Visual Client Web Client Photoshop

27 Beispiel: git

28 Historie Linux Kernel 1300 Entwickler in der ganzen Welt verstreut 15 Millionen Zeilen Code (3.2 Kernel) Ca Patches pro Kernel-Release Änderungen wurden als Patches via oder Mailinglisten weitergereicht Einführung des proprietären DVCS BitKeeper BitKeeper entzog der Kernel-Community wegen Streitereien die kostenlose Lizenz J. Corbet, G. Kroah-Hartman, A. McPherson: Linux Kernel Development How Fast it is Going, Who is Doing It, What They are Doing, and Who is Sponsoring It. The Linux Foundation, März 2012

29 Historie git Linus Torvalds startete 2005 die Entwicklung von git Anlehnend an BitKeeper, jedoch zusätzlich: Hohe Effizienz Hohe Integrität der Daten Verteilte Arbeitsabläufe Seit der Veröffentlichung ist git das offizielle Versionskontrollsystem des Linux Kernels

30 git Optimiert für nicht-lineare Entwicklung

31 git Keine zentralen Server Am Beispiel von OMAP5

32 git Weitere Eigenschaften Versionierung auf Dateisystemebene Webinterfaces Interoperabel zu anderen Versionskontrollsystemen Sichere Projekthistorie

33 git Weit verbreitet

34 Unvollständiger Überblick Werkzeug git svn p4 OpenSource Ja Ja (Nein) Administrierbarkeit Serverzentriert Nein Ja Ja Verteilte Versionsverwaltung Push-Notification Support Ja Master-Slave Proxy Nein +/- Nein +/- Ja ++ Bug-Tracking 3rd Party 3rd Party Bridged/Jobs Tool-Umfang +/- +/- ++

35 Wrap Up

36 Und noch mal... Welches Werkzeug ist das Beste? Genau das, dass am besten zum Projekt passt und auch beherrscht wird! Wir erinnern uns: Ziel ist ein funktionierendes System und nicht die Klärung einer Religionsfrage :-)

37 Warum jetzt noch mal? und nicht Dropbox/Google Drive/NFS/etc.? wenn es nur zusätzlichen Aufwand bedeutet? wenn ich doch nur coden will?

38 Wann erstellt man einen Branch/Tag? Tag: Jeder Softwarestand der evtl. nochmal gebraucht wird!! oder alles was aus der Hand gegeben wird!! Branch: Wenn (umfangreiche) Änderungen an der Software andere stören würden; zur (temporären) Entkopplung der Entwicklung. Vorsicht: kostet Aufwand!!

39 und die Zukunft im ICM-Labor?

40 Literatur Perforce P4 User s Guide April 2013

41 Clemens Fischer Bettina Kurz-Kalweit Andreas Knirsch