• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Einsatz von Git im Unternehmen
 

Einsatz von Git im Unternehmen

on

  • 2,265 views

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 ...

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

Statistics

Views

Total Views
2,265
Views on SlideShare
1,978
Embed Views
287

Actions

Likes
1
Downloads
22
Comments
0

2 Embeds 287

http://www.oose.de 284
http://shop.oose.de 3

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Einsatz von Git im Unternehmen Einsatz von Git im Unternehmen Presentation Transcript

    • Einsatz von Gitim 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
    • Über Uns René Preißel rp@eToSquare.de Freiberuflicher Berater, Entwickler, Trainer Bjørn Stachmann bstachmann@yahoo.de Senior Software Engineer etracker GmbHMit * markierte Grafiken sind dem Buch „Workflows mit Git“,René Preißel, Björn Stachmann, dpunkt.verlag GmbH, 2012 entnommen 2
    • AgendaGit im Open-Source-UmfeldGrundlegende KonzepteGit im Unternehmen Entwickler Entwicklungsprozesse Administration und Betrieb QualitätssicherungGrenzen von GitMigration nach GitZusammenfassung 3
    • 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
    • Google-Trends 5
    • Projekte und ToolsLinux Kernel EclipseGnome und KDE NetbeansDebian IntelliJEclipse VisualStudioPerl und Perl XCodeAndroid Jenkins / HudsonJBoss TortoiseGitPostgress Gerrit - Code ReviewSpring Framework JiraRuby On Rails MavenjQuery ...... 6
    • Open-Source-AnforderungenIntellectual Property Hohe Performance „Diese Zeilen sind von mir“ Flexibilität Easy to Contribute MotivationAutonomie des Entwicklers Keine zeitliche Koordination Viele Entwickler - Viele Standorte Freiheit zum Forking Sicherheit vor Manipulation Zusammenführung 7
    • 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
    • Dezentrales Arbeiten * aus „Workflows mit Git“ 9
    • 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
    • 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 * aus „Workflows mit Git“ Branches sind nur Zeiger auf Commits Merges erzeugen ein neues Commit 12
    • Rebasing * aus „Workflows mit Git“Beim Rebasing werden die Änderungen von Commitskopiert und der Branch verschoben 13
    • Cherry-PickingBeim Cherry-Picking werden die Änderungeneinzelner Commits kopiert 14
    • Welche Features sind für Unternehmen interessant? Welche Featuresfehlen und welche Probleme müssen gelöst werden? 15
    • Git im UnternehmenEntwicklerEntwicklungsprozesseAdministration und BetriebQualitätssicherung 16
    • Git für EntwicklerMö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
    • Entwickler - Trade-OffsTrade-Offs Starke Kommandozeilen-Orientierung Komplexität führt zu steilerer Lernkurve Lokale Administration notwendig Komplexere Workflows z.B. Push als weiterer SchrittMaßnahmen Git-Einführung bewusst planen Schulung, Workshops, Tutorials Definition von Workflows „Schritt für Schritt“-Anleitungen bereitstellen Entwickler-Tools überprüfen 18
    • EntwicklungsprozessMö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
    • Prozess - Trade-OffsTrade-Offs Weniger zentrale Kontrolle Workflows müssen definiert und verwaltet werden Feature-Branches vs. Continuous Integration abwägenMaßnahmen Git-Einführung bewusst planen Workflows erarbeiten Branching-Strategie wählen Release-Vorgehen definieren Verantwortlichkeiten klären 20
    • Diskussion Feature-Branches * aus „Workflows mit Git“ Probleme mit Continuous Integration Späte Integration führt zu größeren Merge-Aufwänden 21
    • Administration und BetriebMö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
    • Administration - Trade-OffsTrade-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 ausgerichtetMaß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
    • Network of Trust * aus „Workflows mit Git“ 24
    • QualitätssicherungMö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
    • Qualitätssicherung - Trade-OffsTrade-Offs Know-How in Git notwendig Integration von Git in Issue-TrackingMaßnahmen Git-Einführung bewusst planen Schulung, Bücher Recherche-Möglichkeiten erlernen Definition von Workflows QA-Tools überprüfen 26
    • Grenzen von GitHohe Komplexität Dezentraler Ansatz Fokus auf Kommandozeile Viele Befehle mit sehr vielen Parametern Befehle sind sehr technisch orientiert und nicht immer selbsterklärendWorkflows sind nicht standardisiertKomplizierter Umgang mit SubmodulenHoher Ressourcenverbrauch bei großen binärenDateienRepositorys können nur vollständig verwendetwerdenAutorisierung nur auf dem ganzen Repository 27
    • Migration (I)1. Git lernen - Erfahrungen sammeln a. Isoliert arbeiten, Parallel arbeiten2. 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ählen3. Neues Repository erzeugen a. Branches finden b. Repository einrichten c. Inhalte übernehmen d. Ergebnisse überprüfen 28
    • 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ützen5. Aufräumen des Git-Repository a. Temporäre Branches löschen 29
    • ZusammenfassungGit bietet interessante Möglichkeiten auchfür UnternehmenGit verlagert mehr Kontrolle undVerantwortung zu den EntwicklernGit ermöglicht andere und flexibleWorkflowsDie Einführung von Git muss sorgfältigvorbereitet werden 30