Als PDF, PPTX herunterladen
Hochgeladen vonoose
Einsatz von Git im Unternehmen
Das Dokument behandelt den Einsatz von Git in Unternehmen, erläutert grundlegende Konzepte und Funktionen sowie die Vor- und Nachteile seiner Verwendung im Entwicklungsprozess. Es betont die Notwendigkeit einer sorgfältigen Planung und Schulung bei der Einführung von Git, um Flexibilität und Effizienz zu gewährleisten. Zudem werden Herausforderungen und Limitierungen wie Komplexität und notwendige Anpassungen in der Administration aufgeführt.
Weitere ähnliche Inhalte
Ähnlich wie Einsatz von Git im Unternehmen
Einsatz von Git im Unternehmen
- 1. Einsatz von Git imUnternehmen 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 GrundlegendeKonzepte Git im Unternehmen Entwickler Entwicklungsprozesse Administration und Betrieb Qualitätssicherung Grenzen von Git Migration nach Git Zusammenfassung 3
- 4. Git im Open-Source-Umfeld „Subversionused 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.
- 6. Projekte und Tools LinuxKernel 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 werdendie Ä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 Administrationund 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 HoheKomplexitä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. Gitlernen - 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 inBetrieb 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 interessanteMö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