Advanced Continuous Integration

2,425 views

Published on

http://www.opitz-consulting.com/go/3-4-894

Die Literatur sagt, dass „Broken Builds“ auf jeden Fall zu vermeiden sind, weil andere Entwickler sich durch die fehlerhaften Änderungen ihren Entwicklungsbereich kaputt machen und dann nicht arbeiten können.

Die Solution Architects unserer IT-Beratung, Stefan Scheidt und Richard Attermeyer, zeigten in ihrem Vortrag am 10.Oktober 2013 bei der gearconf 2013 in Düsseldorf, dass „broken Builds“ nicht das Problem sind. Im Rahmen der Präsentation zeigten die Referenten, wie man durch geeignete Branching- und CI-Strategien stets eine stabilen Branch sicherstellen kann.

Veranschaulicht wurde das Ganze durch eine konkrete Umsetzung mittels Git / GitLab und Jenkins.

--
Über uns:
Als führender Projektspezialist für ganzheitliche IT-Lösungen tragen wir zur Wertsteigerung der Organisationen unserer Kunden bei und bringen IT und Business in Einklang. Mit OPITZ CONSULTING als zuverlässigem Partner können sich unsere Kunden auf ihr Kerngeschäft konzentrieren und ihre Wettbewerbsvorteile nachhaltig absichern und ausbauen.

Über unsere IT-Beratung: http://www.opitz-consulting.com/go/3-8-10
Unser Leistungsangebot: http://www.opitz-consulting.com/go/3-8-874
Karriere bei OPITZ CONSULTING: http://www.opitz-consulting.com/go/3-8-5

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
2,425
On SlideShare
0
From Embeds
0
Number of Embeds
56
Actions
Shares
0
Downloads
14
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Advanced Continuous Integration

  1. 1. Advanced Continuous Integration Ein Projektbericht
  2. 2. Wer sind wir? Richard.Attermeyer@opitz-consulting.com Twitter: attermr GitHub: rattermeyer Stefan.Scheidt@opitz-consulting.com Twitter: stefanscheidt GitHub: stefanscheidt
  3. 3. © OPITZ CONSULTING GmbH 2011 Seite 3Mobile JavaScript-Web-Apps Mission Wir entwickeln gemeinsam mit allen Branchen Lösungen, die dazu führen, dass sich diese Organisationen besser entwickeln als ihr Wettbewerb. Unsere Dienstleistung erfolgt partnerschaftlich und ist auf eine langjährige Zusammenarbeit angelegt. Leistungsangebot Business IT Alignment Business Information Management Business Process Management Anwendungsentwicklung SOA und System-Integration IT-Infrastruktur-Management Märkte Branchenübergreifend Über 600 Kunden 29% Industrie / Versorger / Telekommunikation 29% Handel / Logistik / Dienstleistungen 42% Öffentliche Auftraggeber / Banken und Versicherungen / Vereine und Verbände Eckdaten Gründung 1990 400 Mitarbeiter 9 Standorte
  4. 4. Wer sind Sie?
  5. 5. Die Herausforderung
  6. 6. Also mussten wir uns beeilen ...
  7. 7. Aber manchmal waren wir zu schnell ...
  8. 8. Abhilfe durch Continuous Integration
  9. 9. Continuous Integration Process 1. […] wait for it to finish […] work with the rest of the team to make it green before you check in 2. … 3. Run the build script and tests on your development machine […] 4. […] 5. Wait for your CI tool to run the build with your changes 6. […] 7. If the build passes, rejoice and move on to your next task Jez Humble, David Farley, Continuous Delivery
  10. 10. Continuous Integration Process 1. […] wait for it to finish […] work with the rest of the team to make it green before you check in 2. … 3. Run the build script and tests on your development machine […] 4. […] 5. Wait for your CI tool to run the build with your changes 6. […] 7. If the build passes, rejoice and move on to your next task Jez Humble, David Farley, Continuous Delivery
  11. 11. Continuous Integration Process 1. […] wait for it to finish […] work with the rest of the team to make it green before you check in 2. … 3. Run the build script and tests on your development machine […] 4. […] 5. Wait for your CI tool to run the build with your changes 6. […] 7. If the build passes, rejoice and move on to your next task Jez Humble, David Farley, Continuous Delivery
  12. 12. Continuous Integration Process 1. […] wait for it to finish […] work with the rest of the team to make it green before you check in 2. … 3. Run the build script and tests on your development machine […] 4. […] 5. Wait for your CI tool to run the build with your changes 6. […] 7. If the build passes, rejoice and move on to your next task Jez Humble, David Farley, Continuous Delivery
  13. 13. Continuous Integration Process 1. […] wait for it to finish […] work with the rest of the team to make it green before you check in 2. … 3. Run the build script and tests on your development machine […] 4. […] 5. Wait for your CI tool to run the build with your changes 6. […] 7. If the build passes, rejoice and move on to your next task Jez Humble, David Farley, Continuous Delivery
  14. 14. Continuous Integration Process 1. […] wait for it to finish […] work with the rest of the team to make it green before you check in 2. … 3. Run the build script and tests on your development machine […] 4. […] 5. Wait for your CI tool to run the build with your changes 6. […] 7. If the build passes, rejoice and move on to your next task Jez Humble, David Farley, Continuous Delivery "If everybody on the team follows these simple steps every time they commit any change, you will know that your software works on any box with the same configuration as the CI box at all times."
  15. 15. CI System soll für mich arbeiten - nicht umgekehrt! WTF! Etwas stimmt nicht! Keiner bezahlt mich dafür zu warten, um sicher zu gehen, dass alle Tests immer noch grün sind. Ich will einchecken wann ich will! Ich will den meinen Build kaputt gehen lassen, wann ich will!
  16. 16. Wie kann ein Prozess aussehen, bei dem ein kaputter Build kein „stop- the-line“ bedeutet?
  17. 17. We want TeamCity‘s Feature back: Pre-Tested Commits
  18. 18. Breaking the build is no crime!
  19. 19. Voraussetzung: Einfaches Branching und Merging
  20. 20. development rat/for-development mis/for-development mho/for-development Ein Branch pro Entwickler Entwicklungsbranch, in den integriert werden soll: Branch pro Entwickler mit Namenskonvention Entwicklerbranches werden von development abgespalten Entwicklerbranches sind „privat“ Entwicklerbranches werden vom CI-System wieder in development integriert
  21. 21. Variation: Feature Branches
  22. 22. Wichtige Punkte (nicht-offensichtlich) Abgleich immer über den Integration-Branch Selbst wenn mehrere Entwickler am gleichen Feature arbeiten Kein direkter Merge eines Feature-Branch in den lokalen Working-Branch Außer man weiß, was man tut ...
  23. 23. Vorteile Ich kann unabhängig arbeiten und zentral sichern Das CI-System führt die zeit- und resourcenaufwändigen Tests für mich durch … während ich schon weiter arbeiten kann
  24. 24. Vorteile Der Integration-Branch ist immer grün Durch einen Merge hole ich nur „guten“ Code Ich kann ziemlich sicher sein, dass der Code auch nach dem Merge gebaut werden kann
  25. 25. Vorteile Als Entwickler verbringe ich nicht unnötig Zeit damit Dinge zu fixen, die andere kaputt gemacht haben
  26. 26. Eine Umsetzung +
  27. 27. Jenkins Git Plugin 1/3 Überwache Entwicklerbranches
  28. 28. Jenkins Git Plugin 2/3 Merge Entwickler-Branch auf Development-Branch
  29. 29. Jenkins Git Plugin 3/3 Push merged Development-Branch zurück, wenn Build erfolgreich
  30. 30. Entwicklungsprozess aus Entwicklersicht origin/development git fetch git merge orgin/development git add / commit git push origin rat/for-development 1. Merge 2. Build 3. Push
  31. 31. Demo ...
  32. 32. Kriterien für „Gut-Genug“ Müssen nur die „echten“ Unit Tests laufen? Oder müssen alle Tests laufen? (Unit-, Integrations- und Systemtests) Lange Feedback-Zyklen Hohe Latenz, bis Kollegen von Änderungen profitieren können
  33. 33. Kriterien für „Gut-Genug“ Oder will ich sogar noch ein echtes Code-Review? Nicht allein durch Jenkins möglich Zum Beispiel Gerrit als Review-Tool Code-Reviews für jeden Commit bei jungen Projekt sehr aufwändig
  34. 34. Kriterien für „Gut-Genug“ Lesson Learned: Die Kriterien ändern sich im Projektverlauf
  35. 35. Kriterien für „Gut-Genug“ Anfangs: Alle Tests müssen grün sein Häufig große Änderungen Integrationstests hatten deutlich mehr Aussagekraft als Unit Tests Später: Unit-Tests müssen grün sein Weniger „breaking changes“ Integrationstestfehler mit 4h Zeitverzug entdecken reicht aus
  36. 36. Die Konsequenz ...
  37. 37. Umkehr der Verantwortung An: Meine Kollegen Hallo, habe meinen Code eingechecked, bin dann mal in Urlaub. BTW: CI Server ist jetzt rot und meldet 15 Testfehler. Müsste sich jemand mal anschauen… Bis in 2 Wochen  früher:
  38. 38. Umkehr der Verantwortung An: Meine Kollegen Hallo, wollte euch meinen Code noch vor dem Urlaub zu Verfügung stellen. Hat mich leider noch 2 Stunden gekostet, die 15 Testfehler zu beseitigen. Jenkins hat den Code jetzt aber erfolgreich gemerged. Alles grün!  Bis in 2 Wochen. jetzt:
  39. 39. Dies und das ...
  40. 40. Durchsetzen der Konvention: Protected Branches
  41. 41. Beispiel: GitLab Protected branches are designed to prevent push for all except masters. This ability allows: • keep stable branches secured • forced code review before merge to protected branches
  42. 42. Pull statt fetch/merge [branch "rat/for-development"] remote = origin merge = refs/heads/rat/for-development .git/config
  43. 43. Pull statt fetch/merge [branch "rat/for-development"] remote = origin merge = refs/heads/rat/for-development [branch "rat/for-development"] remote = origin merge = refs/heads/development .git/config .git/config
  44. 44. Pull statt fetch/merge [branch "rat/for-development"] remote = origin merge = refs/heads/rat/for-development [branch "rat/for-development"] remote = origin merge = refs/heads/development $ git pull From git-e.opitz-consulting.int:cel/oc-days-git-2013 d40fefe..86878f9 development -> origin/development Already up-to-date. .git/config .git/config
  45. 45. Gotchas Polling durch Jenkings und mehrere Commits in Zeitfenster Besser: post-receive Hook Web Hooks in Stash und GitLab
  46. 46. Gotchas „Git hat meine Änderungen verschlampt“ == „Ich habe nicht gemerkt, dass mein Commit nicht sauber gemerged werden konnte“
  47. 47. Noch Fragen?
  48. 48. Referenzen (Attribution Creative Commons) Dokumentenhaufen: http://www.flickr.com/photos/katerha/5013886721/ Crashed T14: http://www.flickr.com/photos/77326563@N06/8652444158/ Question Mark: http://www.flickr.com/photos/colinkinner/2200500024/ Tractor on the Road:http://en.wikipedia.org/wiki/File:Tractor- OnTheRoad01.jpg Geek & Poke: http://geek-and-poke.com/ http://geekandpoke.typepad.com/.a/6a00d8341d3df553ef017743a8736997 0d-pi Jail: http://www.flickr.com/photos/schnaars/3036446157

×