Einsatz von Git im Unternehmen

R e n é P r e i ß e lB 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

Über Uns

2

René Preißel rp@eToSquare.de

Freiberuflicher Berater, Entwickler, Trainer

Bjørn Stachmannbstachmann@yahoo.de

Senior Software Engineeretracker GmbH

Mit * markierte Grafiken sind dem Buch „Workflows mit Git“, René Preißel, Björn Stachmann, dpunkt.verlag GmbH, 2012 entnommen

Agenda

Git im Open-Source-UmfeldGrundlegende KonzepteGit im Unternehmen

EntwicklerEntwicklungsprozesseAdministration und BetriebQualitätssicherung

Grenzen von GitMigration nach GitZusammenfassung

3

Git im Open-Source-Umfeld

4

„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

Google-Trends

5

Projekte und Tools

6

EclipseNetbeansIntelliJVisualStudioXCodeJenkins / HudsonTortoiseGitGerrit - Code ReviewJiraMaven...

Linux KernelGnome und KDEDebianEclipsePerl und PerlAndroidJBossPostgressSpring FrameworkRuby On RailsjQuery...

Open-Source-Anforderungen

7

Intellectual Property Hohe Performance

Flexibilität

Motivation

Viele Entwickler - Viele Standorte

Keine zeitliche Koordination

Sicherheit vor Manipulation

Zusammenführung

Freiheit zum Forking

Autonomie des Entwicklers

„Diese Zeilen sind von mir“

Easy to Contribute

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.

8

* aus „Workflows mit Git“

Dezentrales Arbeiten

9

* aus „Workflows mit Git“

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

10

* aus „Workflows mit Git“

Push und Pull

Nur nicht vorhandene Objekte werden übertragen (Wie eine dezentrale Datenbank)

Das Zusammenführen (Merging) von Commits findet immer lokal statt

11

Branching und Merging

12

Branches sind nur Zeiger auf CommitsMerges erzeugen ein neues Commit

* aus „Workflows mit Git“

Rebasing

13

* aus „Workflows mit Git“

Beim Rebasing werden die Änderungen von Commits kopiert und der Branch verschoben

Cherry-Picking

14

Beim Cherry-Picking werden die Änderungen einzelner Commits kopiert

Welche Features sind für

Unternehmen interessant?

15

Welche Features fehlen und welche Probleme müssen gelöst werden?

Git im Unternehmen

16

Entwickler

Entwicklungsprozesse

Administration und Betrieb

Qualitätssicherung

Möglichkeiten

Git für Entwickler

17

Flexible lokale ArbeitsweisenKleine Commits, Lokale Branches

Performante lokale OperationenGute Unterstützung von MergingGute Recherche-Möglichkeiten in der HistorieBisection - Unterstützung bei der FehlersucheOffline arbeiten ist möglichGit kann parallel zur zentralen Versionierung genutzt werden

Maßnahmen

Trade-Offs

Entwickler - Trade-Offs

18

Starke Kommandozeilen-OrientierungKomplexität führt zu steilerer LernkurveLokale Administration notwendigKomplexere Workflows

z.B. Push als weiterer Schritt

Git-Einführung bewusst planenSchulung, Workshops, TutorialsDefinition von Workflows„Schritt für Schritt“-Anleitungen bereitstellen

Entwickler-Tools überprüfen

Möglichkeiten

Entwicklungsprozess

19

Organisatorische FlexibilitätVerschiedene Workflows je Team möglich

Flexible Prozessabläufe werden unterstütztFeature-BranchesRelease-BranchesStaging-Pipelines

Nutzbarerer Historie, z.B. für Release-DokumentationPrototypen und experimentelle Weiterentwicklung werden vereinfacht

Maßnahmen

Trade-Offs

Prozess - Trade-Offs

20

Weniger zentrale KontrolleWorkflows müssen definiert und verwaltet werdenFeature-Branches vs. Continuous Integration abwägen

Git-Einführung bewusst planenWorkflows erarbeiten

Branching-Strategie wählenRelease-Vorgehen definieren

Verantwortlichkeiten klären

Diskussion Feature-Branches

21

Probleme mit Continuous IntegrationSpäte Integration führt zu größeren Merge-Aufwänden

* aus „Workflows mit Git“

Möglichkeiten

Administration und Betrieb

22

Dezentrales Arbeiten an mehreren StandortenEffektive Werkzeuge für Repository-Manipulation

Zusammenführung von RepositorysTrennen von RepositorysHistorien entfernen

Einfaches und flexibles Server-SetupStandardmechanismenKein Problem mit Internet-Infrastruktur

Dezentrales BackupEinsatz von Git für eigene Server-Konfiguration

Maßnahmen

Trade-Offs

Administration - Trade-Offs

23

Keine feingranulare Rechteverwaltung möglichFür große Binaries nur bedingt geeignetHistorien sind änderbar Entscheidung welche Repositorys gesichert werden müssenTools sind sehr an Unix-Infrastruktur ausgerichtet

Workflows für mehr Kontrolle definierenDefinition von Staging-Pipelines„Network of Trust“

Einsatz von Server-Werkzeugen für mehr Kontrollez.B. Gitolite oder Gerrit

Auslagerung an Dienstleister evaluierenz.B. GitHub

Network of Trust

24

* aus „Workflows mit Git“

Möglichkeiten

Qualitätssicherung

25

Feste Versionsstände durch HashesFeature-Branches erleichtern die Zuordnung von Änderungen zu FeaturesGenauere Recherche-Möglichkeiten sind möglichKontrollierter Umgang mit Bugfixes ist möglich, z.B. Cherry-PickingVersionierte Zusatzinformationen sind möglichNachträgliche Änderungen in Installationen werden nachvollziehbar

Kundenversion kann Hash enthalten

Maßnahmen

Trade-Offs

Qualitätssicherung - Trade-Offs

26

Know-How in Git notwendigIntegration von Git in Issue-Tracking

Git-Einführung bewusst planenSchulung, Bücher

Recherche-Möglichkeiten erlernenDefinition von WorkflowsQA-Tools überprüfen

Grenzen von Git

27

Hohe KomplexitätDezentraler AnsatzFokus auf KommandozeileViele Befehle mit sehr vielen ParameternBefehle sind sehr technisch orientiert und nicht immer selbsterklärend

Workflows sind nicht standardisiertKomplizierter Umgang mit SubmodulenHoher Ressourcenverbrauch bei großen binären DateienRepositorys können nur vollständig verwendet werdenAutorisierung nur auf dem ganzen Repository

Migration (I)

28

1. Git lernen - Erfahrungen sammelna. Isoliert arbeiten, Parallel arbeiten

2. Entscheidungen treffena. Alle Projekte auf einmal migrieren?b. Welche Projekte migrieren?c. Bestehende Struktur übernehmen?d. Unterbrechung der Entwicklung möglich?e. Branching-Strategie / Workflows festlegenf. Werkzeuge auswählen

3. Neues Repository erzeugena. Branches findenb. Repository einrichtenc. Inhalte übernehmend. Ergebnisse überprüfen

Migration(II)

29

4. Repository in Betrieb nehmena. Ankündigung / Notfallplan während

Umstellungb. Schulung der Entwicklerc. Letzte Änderungen aus alter Versionierung

nachziehend. Neues Repository bereitstellen, Entwickler

informierene. Null-Release durchführenf. Altes Repository auf Read-Only setzeng. Entwickler unterstützen

5. Aufräumen des Git-Repositorya. Temporäre Branches löschen

Zusammenfassung

30

Git bietet interessante Möglichkeiten auch für UnternehmenGit verlagert mehr Kontrolle und Verantwortung zu den EntwicklernGit ermöglicht andere und flexible WorkflowsDie Einführung von Git muss sorgfältig vorbereitet werden