Softwaretechnik
Lesson 3
Versionsverwaltung
Diplomarbeit (schon wieder)
Bug
- Ich gehe nicht eher nach Hause als dass der Bug gefixt ist
- 4 Stunden harte / verzweifelte Arbeit
- Kein Ergebnis
- Feierabend
Nächster Morgen
- 10 min Bugfixen
- 4h Müll aufräumen
Erkenntnis
- Das muss auch besser gehen
=> Versionsverwaltung
Versionsverwaltung
Eine Versionsverwaltung ist ein System, das zur Erfassung von Änderungen an Dokumenten oder Dateien verwendet wird. Alle Versionen werden in einem Archiv mit Zeitstempel und Benutzerkennung gesichert und können später wiederhergestellt werden (Wikipedia)
Anforderungen
- Metadaten
- Wann?
- Wer?
- Warum? (Kommentar)
- Kennzeichnung von bestimmten Ständen (Label/Tag)
- Arbeit an unterschiedlichen Ständen (Branches)
- Wiederherstellung von Ständen (Checkout)
- Übertragen von Änderungen (Patch / Cherrypick / Rebase)
- Zusammenführen von Änderungen (Merge)
- Vergleich von Versionen (Diff)
Ersetzt keine Backup Strategy
Versionsverwaltung als Integrationspunkt
- Enthält idealerweise alle relevante Informationen zum Projekt
- Continuous Integration baut darauf auf
- Über Hooks können Personen oder Systeme informiert werden
- Wichtiges Werkzeug für Analyse von Fehlerhäufigkeiten
- Kommentare enthalten oft codierte Informationen
RCS
(Revision Control System)
- Eine der ersten Versionsverwaltungen
- Kennt die vollständige Historie einer Datei
- Vollständig: alle von einem Benutzer als relevant definierten Schritte
- Keine Verwaltung über mehrere Dateien
- Keine Unterstützung für Benutzung über das Netzwerk hinweg
CVS
(Concurrent Versioncontrol System)
-
Zentraler Server + Working Copy
- Auschecken um Dateien bearbeiten zu können.
- Versionierung von ganzen Dateibäumen
- nicht atomare commits
SVN
(Subversion)
- Zentraler Server
- atomare Commits
- optimistic Locking
Git
- Distributed Version Control System
- Jeder Benutzer hat sei eigenes Repository
- Alle Repositories sind technisch gleichberechtigt
- Jedes Commit identifizierbar durch einen Hash
- speichert die Folge der Commits, die zu dem aktuellen commit geführt haben
-
Branching und Mergen
- schnell
- einfach
- Der Gesamte Workflow basiert auf Branching und Merging
Vorteile von DVCS
-
schneller, da lokal gearbeitet wird
- mehr commits (>10 pro Tag vs ~1 pro Tag)
- offline arbeiten möglich
- unterstützt flexible Workflows
Beispiel Workflow
- Branch pro Feature
- automatische Integration in den CI-Branch (Continuous Integration)
- erlaubt die Neukombination von Featuren, wenn z.B. ein Feature doch nicht deployed werden soll
State of the Art
- Softwareentwicklung ohne Versionsverwaltung ist Pfusch
- Neue Projekte mit Nicht-DVCS machen wenig Sinn
Nicht Source Code
- Anforderungen
- Tests
- Testausführungen
- Dokumentation
- Pläne
Die gleichen Anforderungen
- Die Tests für den Bugfix werden auch für den Trunk benötigt
- Welche Änderungen gibt es an den Anforderungen?
- Warum wurde das Handbuch verändert? Und Wann? Und von wem?
Gemeinsame Versionierung
- Welche Version des Codes?
- Welche Version der Anforderung?
- Welche Version des Handbuchs?
- Welche Version der Tests
Toolinterne Versionsverwaltung
- Gute Integration in Tools
- Spezielle Diffmechanismen
- Spezielle Metadaten
- Meist nur rudimentäre VCS Funktionalität (vergleichbar RCS)
- Versionen über Tools hinaus müssen separat gemanagt werden.
- Vendor Lock-In
Externe Versionsverwaltung
- Geringe Acceptance bei nicht technischen Usern
- Nicht sinnvoll bei Binär Daten
- Nicht sinnvoll bei stark volatilen Daten
Häufiger Kompromiss
- generisches VCS als zentrales Tool
- Diverse In-Tool-Versionsverwaltungen
- Gegebenenfalls einzelne Stände vie Export in zentralves VCS
Begrenzt die Auswertbarkeit erheblich
Häufiges Antipattern
Manuelle Versionierung
- Dateien oder Verzeichnisnamen mit Versionen
- Änderungshistorie in Dokumenten
PFUSCH!
Good (Best?) Practices
Eine logische Einheit pro Commit
- Beispiele
- Ein Refactoring
- Eine neue Klasse und Ihr Test
- Integration von neuen Klassen in bestehenden Code
- Formatierung
- Größere Einheiten können durch Referenzen entstehen
- Referenz auf einen Bug
- Referenz auf ein Feature
- Erleichtert
- Rückgängig machen
- Transportieren auf andere Branches
- Bewerten von Änderungen
Sauberer Workspace
jeschaud@DDEA1846 ~/workspaces/scala/scalaDoodle (master)
$ git status
# On branch master
# Your branch is ahead of 'origin/master' by 5 commits.
#
nothing to commit (working directory clean)
Es wird das committed was auch getestet wurde
Nicht mehr
Nicht weniger
Kommentarinhalt
-
Was habe ich geändert (semantisch)
- Warum habe ich es geändert
- Nicht das Ergebnis eines diffs wiederholen
-
Referenzen (Bugs, Requirements)
- Maschinenlesbar (kurz, einheitlich, gut parsbar)
- z.B. DPS-4711
- Kommentare sollten auch ohne Referenz verständlich sein
- Inhalt das Bugs / Requirements
- Warum löst diese Änderung das Problem
Kommentare Format
<Kopfzeile>
<Leerzeile>
<Detaillierter Inhalt>
Kopfzeile
- 50 Zeichen
- Zusammenfassung der Änderung
Detaillierter Inhalt
- Mehrzeilig
- Mehrere Absätze
- 72 Zeichen pro Zeile
Code Kommentar
vs
Commit Kommentar
Code Kommentar
- Was tut der Code
- Warum tut er es
- evtl. Wie tut er es
- Helfen den Code zu verstehen und zu warten
Commit Kommentar
- Was ist das für eine Änderung
- Warum wird diese Änderung gemacht
- Verweise auf Bug/Requirements
- "Durch diese Änderung wird der Code so geändert, das er Req XY erfüllt"
- Beinhaltet implizit die (potentielle) Notwendigkeit aller vorigen Änderungen
Praktische Übung
Bowling Kata
ohne Maus
Aufgabe
Reviews der folgenden Commits
Sind es 'saubere' commits?
Wie kann man sie besser machen?
Weiterführende Literatur
Softwaretechnik Lesson 3
By Jens Schauder
Softwaretechnik Lesson 3
- 1,644