$30 off During Our Annual Pro Sale. View Details »

Erfolgreich mit Git - Ein Erfahrungsbericht

Erfolgreich mit Git - Ein Erfahrungsbericht

Gestern habe ich auf dem "IT Talk" der Firma ConceptPeople einen Vortrag über die Einführung von Git bei der Techniker Krankenkasse gehalten
In dem Vortrag, den ich gemeinsam mit René Preißel gehalten habe, haben wir uns unter anderem an konkreten Praxis-Beispielen damit beschäftigt, wie man große Projekte mit Git verwalten kann, welche Werkzeuge dazu benötigt werden und wie mögliche Migrationsszenarien aussehen können.

Nils Hartmann

October 02, 2014
Tweet

More Decks by Nils Hartmann

Other Decks in Programming

Transcript

  1. CONCEPT  PEOPLE      IT-­‐TALK     Ein  Erfahrungsbericht  

    Erfolgreicher  Ums9eg  auf  Git       René  Preißel  (eToSquare)   Nils  Hartmann  (Techniker  Krankenkasse)      
  2. RENÉ  PREISSEL  |  NILS  HARTMANN,  10.  FEBRUAR  2014   VORSTELLUNG

      René  Preißel  |  Freiberuflicher   SoGwarearchitekt,  Entwickler  und  Trainer   Co-­‐Autor  des  Buchs  „Git:  Dezentrale  Versionsverwaltung   im  Team  –  Grundlagen  und  Workflows“   Kontakt:  [email protected]     Nils  Hartmann  |  Java-­‐SoGwareentwickler,   Techniker  Krankenkasse     Schwerpunkte:  OSGi,  Eclipse  und  Build-­‐Management   Kontakt:  [email protected]  
  3. RENÉ  PREISSEL  |  NILS  HARTMANN,  10.  FEBRUAR  2014   AGENDA

      •  Ausgangssituaaon   •  Git  vs  Synergy   •  Repositories  &  Branches   •  Entwicklungsprozess  mit  Git   •  Tooling   •  Einführung   •  Fragen  &  Diskussionen  
  4. RENÉ  PREISSEL  |  NILS  HARTMANN,  10.  FEBRUAR  2014   AUSGANGSSITUATION:

     TKEASY   TKeasy   •  1  Soeware  Ÿ  120  Produkte   •  65.000  Java  Klassen   •  700  MB  Code   •  120  Entwickler     Regelmäßige  Releases   •  5-­‐6  Major  Releases  pro  Jahr   •  1  Bugfix    pro  Woche  
  5. RENÉ  PREISSEL  |  NILS  HARTMANN,  10.  FEBRUAR  2014   AUSGANGSSITUATION:

     SYNERGY   Synergy   •  Von  IBM  übernommen   •  Sehr  hohe  Lizenzkosten   •  Zu  langsam  für  die  Code-­‐Größe     Entwicklungsprozess   •  Synergy  Change   •  Komplex  
  6. RENÉ  PREISSEL  |  NILS  HARTMANN,  10.  FEBRUAR  2014   ZUSTÄNDE

     UND  QUERIES  IN  SYNERGY   Change  C   Rel.  4.5  /  offen   Task   Task   Task   Change  B   Rel.  4.0  /  freigegeben   Task   Task   Task   Change  A   Rel.  4.5  /  freigegeben   Task   Task   Task   Freigegeben   Rel.  <=4.5   Versionen  von     Dateien   Release  -­‐  Build  
  7. RENÉ  PREISSEL  |  NILS  HARTMANN,  10.  FEBRUAR  2014   COMMITS

     UND  BRANCHES  IN  GIT   •   Jedes  Commit  versioniert  das  gesamte  Projekt   •   Integrierte  Änderungen  müssen  explizit  ausgebaut  werden  
  8. RENÉ  PREISSEL  |  NILS  HARTMANN,  10.  FEBRUAR  2014   REPOSITORIES

     –  ANFORDERUNGEN     +  Einfache  Verwaltung   +  Sehr  gut  für  zentralen  Build   -  Git-­‐Operaaonen  dauern  lange  (klonen,  git  status  etc)   -  Keine  feingranularen  Berechagungen  möglich   -  Sehr  viele  Commits  =>  komplexe  Historie   +  Git-­‐Operaaonen  gehen  sehr  schnell   -  Hoher  Verwaltungsaufwand   -  Probleme  beim  Refaktoring  
  9. RENÉ  PREISSEL  |  NILS  HARTMANN,  10.  FEBRUAR  2014   REPOSITORIES

     -­‐  ANFORDERUNGEN   •  Weboberfläche   •  Source  Code  Suche   •  Verlinkung  aus  Stacktraces  etc   •  Rechteverwaltung   •  Qualitätssicherung  /  Code  Review   •  REST  API  /  Plug-­‐ins  
  10. RENÉ  PREISSEL  |  NILS  HARTMANN,  10.  FEBRUAR  2014   REPOSITORY-­‐VERWALTUNG:

     ALTERNATIVEN   •  Volltext-­‐Suche   •  (Eingeschränkte)  Rechteverwaltung   •  „Amend-­‐basierter“  Workflow   •  Konfigurierbare  Code-­‐Review-­‐Regeln   •  Feingranulares  Berechagungssystem   •  Konfigurierbare  Code-­‐Review-­‐Regeln   •  Bei  Projekt-­‐Start  noch  nicht  verfügbar  
  11. RENÉ  PREISSEL  |  NILS  HARTMANN,  10.  FEBRUAR  2014   int

    master „manueller“ non-fast-forward Merge ďƵŐĮdž prod BRANCH  MODELL    „TK  GIT  FLOW“  
  12. RENÉ  PREISSEL  |  NILS  HARTMANN,  10.  FEBRUAR  2014   int

    master „manueller“ non-fast-forward Merge ďƵŐĮdž prod Release 13.03 13.03 13.04 13.05 BRANCH  MODELL    „TK  GIT  FLOW“  
  13. RENÉ  PREISSEL  |  NILS  HARTMANN,  10.  FEBRUAR  2014   int

    master „manueller“ non-fast-forward Merge ďƵŐĮdž prod ͣĂƵƚŽŵĂƟƐĐŚĞƌ͞ŶŽŶͲĨĂƐƚͲĨŽƌǁĂƌĚDĞƌŐĞ Release 13.03 13.03 13.04 13.05 BRANCH  MODELL    „TK  GIT  FLOW“  
  14. RENÉ  PREISSEL  |  NILS  HARTMANN,  10.  FEBRUAR  2014   TK

     ENTWICKLUNGSPROZESS   •  Changes  müssen  freigegeben  werden   •  Changes  müssen  isoliert  entwickelt  werden   •  Jeder  Change  benöagt  Review     Synergy   •  Integrierte  Change  Verwaltung   •  Freigaben  über  Change  Zustand     •  Einsammeln  über  Query  
  15. RENÉ  PREISSEL  |  NILS  HARTMANN,  10.  FEBRUAR  2014   EINEN

     CHANGE  BEARBEITEN      1   •  Verwaltung  der  Changes  in  Atlassian  Jira   •  Change  wird  auf  Topic-­‐Branch  entwickelt   master topic-2 Beginn Topic-Branch topic-1
  16. RENÉ  PREISSEL  |  NILS  HARTMANN,  10.  FEBRUAR  2014   EINEN

     CHANGE  BEARBEITEN      2   master topic-2 Beginn Topic-Branch topic-1 Pull Request
  17. RENÉ  PREISSEL  |  NILS  HARTMANN,  10.  FEBRUAR  2014   EINEN

     CHANGE  BEARBEITEN      3   •  Automaascher  Build,  QS,  Tests  
  18. RENÉ  PREISSEL  |  NILS  HARTMANN,  10.  FEBRUAR  2014   EINEN

     CHANGE  BEARBEITEN      4   •  Freigabe  über  den  Jira-­‐Vorgang   •  Beim  Deployment  werden  Freigaben  überprüe    git log int..prod | grep Jira-Id Bei  Nicht-­‐Freigabe  eines  Changes   •  Änderungen  müssen  ausgebaut  werden   •  Git  Reverse  Commit    
  19. RENÉ  PREISSEL  |  NILS  HARTMANN,  10.  FEBRUAR  2014   TOOLING

     FÜR  ENTWICKLER   Egit  –  Git  Team  Provider   •  Sehr  „technisch“   •  Kein  Workflow   •  Fehlerhaee  Merges   Mylyn  –  Taskverwaltung     •  Topic-­‐Branch  akavieren  nicht   implemenaert    
  20. RENÉ  PREISSEL  |  NILS  HARTMANN,  10.  FEBRUAR  2014   TOOLING

     FÜR  ENTWICKLER   •  Authenafizieren  und  Klonen  
  21. RENÉ  PREISSEL  |  NILS  HARTMANN,  10.  FEBRUAR  2014   TOOLING

     FÜR  ENTWICKLER   •  Branches  anlegen  und  wechseln  
  22. RENÉ  PREISSEL  |  NILS  HARTMANN,  10.  FEBRUAR  2014   TOOLING

     FÜR  ENTWICKLER   •  CGit  für  Merge-­‐Operaaonen    
  23. RENÉ  PREISSEL  |  NILS  HARTMANN,  10.  FEBRUAR  2014   TOOLING

     FÜR  BUILDMANAGEMENT   •  Vollständiges  Build  benöagt  alle  Produkte  und   dauert  lange   •  Vor  der  Integraaon  eines  Topic-­‐Branches  soll   ein  Build  inklusive  Tests  durchgeführt  werden   •  Schnelle  Builds  einzelner  Produkte  notwendig   •  Jedes  Produkt  kann  separat  mit  den  letzten   Versionen  abhängiger  Produkte  gebaut  werden      
  24. GIT  SUBTREE   •  Vollständiges  Build   benöagt  alle  

    Produkte   •  Git-­‐Subtree  wird  für   die  Integraaon  aller   Produkte  in  ein   Repository  benutzt  
  25. RENÉ  PREISSEL  |  NILS  HARTMANN,  10.  FEBRUAR  2014   TOOLING

     FÜR  CHANGEMANAGEMENT   •  Automaasche  Merges   •  Taggen  von  Code-­‐Ständen  (Installierte  Stände)   •  Abgleich  von  Git  und  Jira   •  Erzeugen  und  Pflegen  von  Jenkins  Jobs   •  Java,  Python,  Git  Bash   •  REST-­‐APIs  
  26. RENÉ  PREISSEL  |  NILS  HARTMANN,  10.  FEBRUAR  2014   MIGRATIONSPFAD

      Git 13.04 Build 13.03 Build 13.05-A Build 13.05-B Build 14.01 Build Produktentwicklung in Synergy Git Synergy
  27. RENÉ  PREISSEL  |  NILS  HARTMANN,  10.  FEBRUAR  2014   EINFÜHRUNG

      •  Beschränkung  auf  essenaelle  Git-­‐Features   •  Frühzeiage  Ausbildung  interner  Experten   •  Entwicklerschulungen  kurz  vor  der  Umstellung   •  Verzicht  auf  Übernahme  der  gesamten   Historie   Kein  Big  Bang  
  28. RENÉ  PREISSEL  |  NILS  HARTMANN,  10.  FEBRUAR  2014   PROBLEME:

     VIELE  NEUE  KONZEPTE   •  Lokale  vs  Remote-­‐Branches   •  Commit  vs  Push   •  „Wo  ist  mein  Change?“   •  Jira  vs  Git  vs  Jenkins...   •  Viele  potenaelle  Fehlerquellen  
  29. RENÉ  PREISSEL  |  NILS  HARTMANN,  10.  FEBRUAR  2014   PROBLEME:

     MERGE-­‐KONFLIKTE   •  Synergy:  pessimisasche  Sperren  
  30. RENÉ  PREISSEL  |  NILS  HARTMANN,  10.  FEBRUAR  2014   FAZIT

      •  Umstellung  hat  gut  geklappt   •  Einführung  länger  als  geplant   •  Absammung  der  Prozesse  aufwendiger  als   Umstellung  der  Tools   •  Prakasche  Umstellung  hat  gut  funkaoniert   •  ToollandschaG  hat  sich  verbessert   •  Weniger  Bugs   •  Mehr  Auswahl