Immer mehr Open-Source-Projekte benutzen Git. Der Vorteil ist klar: Viele Entwickler arbeiten weltweit verteilt, zeitlich versetzt und nur lose gesteuert an einem Projekt. Das passt hervorragend zum dezentralen Ansatz von Git. Git untersützt die benötigten Workflows für eine solche Projektorganisation hervorragend - denn dafür wurde es entwickelt. Der Vortrag diskutiert die Fragen, die sich bei der Einführung von Git im eigenen Unternehmen stellen: - Welche Vorteile bringt Git für In-House-Projekte und Produktentwicklungen? - Wie geht man vor, wenn man Git einführen möchte? - Mit welchen Problemen ist beim Umstieg zu rechnen? - Sind die gleichen Workflows, die in der Open-Source-Welt funktionieren auch für die Unternehmenswelt sinnvoll? Am Beginn des Vortrages gibt es einem kurzen Einstieg in Git, so dass auch Git-Unerfahrene eine Idee von den Fähigkeiten einer dezentralen Versionsverwaltung erhalten. Abendvortrag oose Innovative Informatik GmbH, Tower Falkenried-Piazza, Straßenbahnring 7, 20251 Hamburg

1. Einsatz von Git
im Unternehmen
R e n é P r e i ß e l
B j ø r n S t a c h m a n n
H a m b u r g 2 5 . 1 . 2 0 1 2

2. Über Uns
René Preißel
rp@eToSquare.de
Freiberuflicher
Berater, Entwickler, Trainer
Bjørn Stachmann
bstachmann@yahoo.de
Senior Software Engineer
etracker GmbH
Mit * markierte Grafiken sind dem Buch „Workflows mit Git“,
René Preißel, Björn Stachmann, dpunkt.verlag GmbH, 2012 entnommen
2

3. Agenda
Git im Open-Source-Umfeld
Grundlegende Konzepte
Git im Unternehmen
Entwickler
Entwicklungsprozesse
Administration und Betrieb
Qualitätssicherung
Grenzen von Git
Migration nach Git
Zusammenfassung
3

4. Git im Open-Source-Umfeld
„Subversion used to say CVS done right:
with that slogan there is nowhere you can go.
There is no way to do CVS right“, Linus Torvalds, Mai 2007
http://www.youtube.com/watch?v=4XpnKHJAok8
4

5. Google-Trends
5

6. Projekte und Tools
Linux Kernel Eclipse
Gnome und KDE Netbeans
Debian IntelliJ
Eclipse VisualStudio
Perl und Perl XCode
Android Jenkins / Hudson
JBoss TortoiseGit
Postgress Gerrit - Code Review
Spring Framework Jira
Ruby On Rails Maven
jQuery ...
...
6

7. Open-Source-Anforderungen
Intellectual Property Hohe Performance
„Diese Zeilen sind von mir“ Flexibilität
Easy to Contribute Motivation
Autonomie des Entwicklers
Keine zeitliche Koordination
Viele Entwickler - Viele Standorte
Freiheit zum Forking Sicherheit vor Manipulation
Zusammenführung
7

8. Git Konzepte
Jeder Entwickler hat
einen Workspace und ein
vollständiges Repository
Neue Versionen
(Commits) werden nur
lokal angelegt
Zwischen Repositorys
können Commits mit Pull
und Push ausgetauscht
werden
Alle Repositorys sind
prinzipiell gleichwertig.
* aus „Workflows mit Git“
8

9. Dezentrales Arbeiten
* aus „Workflows mit Git“
9

10. Dezentrale Versionsnummern
Es gibt keinen zentralen
Server der die Versionen
nummerieren kann
Für alle Inhalte werden
Hash-Werte als Schlüssel
berechnet (SHA, 160 Bit)
Commit-Hash -
Dezentrale Version des
gesamten Projektes
Git versioniert immer
das ganze Projekt
* aus „Workflows mit Git“
10

11. Push und Pull
Nur nicht vorhandene
Objekte werden
übertragen (Wie eine
dezentrale Datenbank)
Das Zusammenführen
(Merging) von Commits
findet immer lokal statt
11

12. Branching und Merging
* aus „Workflows mit Git“
Branches sind nur Zeiger auf Commits
Merges erzeugen ein neues Commit
12

13. Rebasing
* aus „Workflows mit Git“
Beim Rebasing werden die Änderungen von Commits
kopiert und der Branch verschoben
13

14. Cherry-Picking
Beim Cherry-Picking werden die Änderungen
einzelner Commits kopiert
14

15. Welche Features
sind für
Unternehmen
interessant?
Welche Features
fehlen und welche
Probleme müssen
gelöst werden?
15

16. Git im Unternehmen
Entwickler
Entwicklungsprozesse
Administration und Betrieb
Qualitätssicherung
16

17. Git für Entwickler
Möglichkeiten
Flexible lokale Arbeitsweisen
Kleine Commits, Lokale Branches
Performante lokale Operationen
Gute Unterstützung von Merging
Gute Recherche-Möglichkeiten in der
Historie
Bisection - Unterstützung bei der
Fehlersuche
Offline arbeiten ist möglich
Git kann parallel zur zentralen Versionierung
genutzt werden
17

18. Entwickler - Trade-Offs
Trade-Offs
Starke Kommandozeilen-Orientierung
Komplexität führt zu steilerer Lernkurve
Lokale Administration notwendig
Komplexere Workflows
z.B. Push als weiterer Schritt
Maßnahmen
Git-Einführung bewusst planen
Schulung, Workshops, Tutorials
Definition von Workflows
„Schritt für Schritt“-Anleitungen bereitstellen
Entwickler-Tools überprüfen
18

19. Entwicklungsprozess
Möglichkeiten
Organisatorische Flexibilität
Verschiedene Workflows je Team möglich
Flexible Prozessabläufe werden unterstützt
Feature-Branches
Release-Branches
Staging-Pipelines
Nutzbarerer Historie, z.B. für Release-
Dokumentation
Prototypen und experimentelle
Weiterentwicklung werden vereinfacht
19

20. Prozess - Trade-Offs
Trade-Offs
Weniger zentrale Kontrolle
Workflows müssen definiert und verwaltet
werden
Feature-Branches vs. Continuous Integration
abwägen
Maßnahmen
Git-Einführung bewusst planen
Workflows erarbeiten
Branching-Strategie wählen
Release-Vorgehen definieren
Verantwortlichkeiten klären
20

21. Diskussion Feature-Branches
* aus „Workflows mit Git“
Probleme mit Continuous Integration
Späte Integration führt zu größeren Merge-Aufwänden
21

22. Administration und Betrieb
Möglichkeiten
Dezentrales Arbeiten an mehreren Standorten
Effektive Werkzeuge für Repository-
Manipulation
Zusammenführung von Repositorys
Trennen von Repositorys
Historien entfernen
Einfaches und flexibles Server-Setup
Standardmechanismen
Kein Problem mit Internet-Infrastruktur
Dezentrales Backup
Einsatz von Git für eigene Server-
Konfiguration
22

23. Administration - Trade-Offs
Trade-Offs
Keine feingranulare Rechteverwaltung möglich
Für große Binaries nur bedingt geeignet
Historien sind änderbar
Entscheidung welche Repositorys gesichert werden
müssen
Tools sind sehr an Unix-Infrastruktur ausgerichtet
Maßnahmen
Workflows für mehr Kontrolle definieren
Definition von Staging-Pipelines
„Network of Trust“
Einsatz von Server-Werkzeugen für mehr Kontrolle
z.B. Gitolite oder Gerrit
Auslagerung an Dienstleister evaluieren
z.B. GitHub
23

24. Network of Trust
* aus „Workflows mit Git“
24

25. Qualitätssicherung
Möglichkeiten
Feste Versionsstände durch Hashes
Feature-Branches erleichtern die Zuordnung
von Änderungen zu Features
Genauere Recherche-Möglichkeiten sind
möglich
Kontrollierter Umgang mit Bugfixes ist
möglich, z.B. Cherry-Picking
Versionierte Zusatzinformationen sind möglich
Nachträgliche Änderungen in Installationen
werden nachvollziehbar
Kundenversion kann Hash enthalten
25

26. Qualitätssicherung - Trade-Offs
Trade-Offs
Know-How in Git notwendig
Integration von Git in Issue-Tracking
Maßnahmen
Git-Einführung bewusst planen
Schulung, Bücher
Recherche-Möglichkeiten erlernen
Definition von Workflows
QA-Tools überprüfen
26

27. Grenzen von Git
Hohe Komplexität
Dezentraler Ansatz
Fokus auf Kommandozeile
Viele Befehle mit sehr vielen Parametern
Befehle sind sehr technisch orientiert und nicht
immer selbsterklärend
Workflows sind nicht standardisiert
Komplizierter Umgang mit Submodulen
Hoher Ressourcenverbrauch bei großen binären
Dateien
Repositorys können nur vollständig verwendet
werden
Autorisierung nur auf dem ganzen Repository
27

28. Migration (I)
1. Git lernen - Erfahrungen sammeln
a. Isoliert arbeiten, Parallel arbeiten
2. Entscheidungen treffen
a. Alle Projekte auf einmal migrieren?
b. Welche Projekte migrieren?
c. Bestehende Struktur übernehmen?
d. Unterbrechung der Entwicklung möglich?
e. Branching-Strategie / Workflows festlegen
f. Werkzeuge auswählen
3. Neues Repository erzeugen
a. Branches finden
b. Repository einrichten
c. Inhalte übernehmen
d. Ergebnisse überprüfen
28

29. Migration(II)
4. Repository in Betrieb nehmen
a. Ankündigung / Notfallplan während
Umstellung
b. Schulung der Entwickler
c. Letzte Änderungen aus alter Versionierung
nachziehen
d. Neues Repository bereitstellen, Entwickler
informieren
e. Null-Release durchführen
f. Altes Repository auf Read-Only setzen
g. Entwickler unterstützen
5. Aufräumen des Git-Repository
a. Temporäre Branches löschen
29

30. Zusammenfassung
Git bietet interessante Möglichkeiten auch
für Unternehmen
Git verlagert mehr Kontrolle und
Verantwortung zu den Entwicklern
Git ermöglicht andere und flexible
Workflows
Die Einführung von Git muss sorgfältig
vorbereitet werden
30