Warum?... Und vor allem: Womit?
Agenda Motivation & Grundlagen Beispiel: Perforce Beispiel: git Wrap-Up Andreas Knirsch Bettina Kurz-Kalweit Clemens Fischer
aka.... Versionsverwaltung Konfigurationsmanagement oder auch... Version Control System (VCS) Revision Control Source Control Software Configuration Management etc.
Erfahrungen Was Warum Wie? r e d e i w o...genaus bn Some rights reserved by tantek
Unser Ziel: Funktionierendes System b Some rights reserved by wwarby
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!!
Motivation für Dynamik in der Entwicklung (und bei der Wartung) von Software kontrollierbar machen! Entwickler UNTERSTÜTZEN!!
Grundlagen
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.
Terminologie: Branches & Tags
Terminologie: Merging Branches
Softwareentwicklung Das echte Leben sieht leider nicht so aus.
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
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
Szenario I: Parallele Entwicklung (III) BANG BANG BANG
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
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 :-)
Szenario II: Wartung (II) oder Cherry Picking
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 :-)
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!!
Aber... Welches Werkzeug ist das Beste? Wir erinnern uns: Ziel ist ein funktionierendes System :-)
Aber... Welches Werkzeug ist das Beste? (II) Projekt ist u.a. gekennzeichnet durch: Aufgabe, Mitarbeiter, Budget, Zeit, Abhängigkeiten/Vorgaben, etc.
Aber... Welches Werkzeug ist das Beste? (III) 1 1 2 4 Ergebnis: Mit jedem der vorhandenen Werkzeug ist die hier gestellte Aufgabe lösbar :-)
Beispiel: Perforce aka. p4
Überblick p4 MS Windows with Visual Studio Linux with Eclipse IDE Mac OSX with Eclipse IDE
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
Beispiel: git
Historie Linux Kernel 1300 Entwickler in der ganzen Welt verstreut 15 Millionen Zeilen Code (3.2 Kernel) Ca. 10.000 Patches pro Kernel-Release Änderungen wurden als Patches via E-Mail 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
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
git Optimiert für nicht-lineare Entwicklung
git Keine zentralen Server Am Beispiel von OMAP5
git Weitere Eigenschaften Versionierung auf Dateisystemebene Webinterfaces Interoperabel zu anderen Versionskontrollsystemen Sichere Projekthistorie
git Weit verbreitet
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 +/- +/- ++
Wrap Up
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 :-)
Warum jetzt noch mal? und nicht Dropbox/Google Drive/NFS/etc.? wenn es nur zusätzlichen Aufwand bedeutet? wenn ich doch nur coden will?
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!!
und die Zukunft im ICM-Labor?
Literatur Perforce 2013.1 P4 User s Guide April 2013
Clemens Fischer Bettina Kurz-Kalweit Andreas Knirsch