Advanced Continuous Integration
 

Advanced Continuous Integration

on

  • 1,559 views

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

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

Statistics

Views

Total Views
1,559
Views on SlideShare
1,515
Embed Views
44

Actions

Likes
0
Downloads
8
Comments
0

3 Embeds 44

http://lanyrd.com 26
https://twitter.com 9
http://confluence.opitz-consulting.de 9

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

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

Advanced Continuous Integration Advanced Continuous Integration Presentation Transcript

  • Advanced Continuous Integration Ein Projektbericht
  • Wer sind wir? Richard.Attermeyer@opitz-consulting.com Twitter: attermr GitHub: rattermeyer Stefan.Scheidt@opitz-consulting.com Twitter: stefanscheidt GitHub: stefanscheidt
  • © 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 View slide
  • Wer sind Sie? View slide
  • Die Herausforderung
  • Also mussten wir uns beeilen ...
  • Aber manchmal waren wir zu schnell ...
  • Abhilfe durch Continuous Integration
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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."
  • 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!
  • Wie kann ein Prozess aussehen, bei dem ein kaputter Build kein „stop- the-line“ bedeutet?
  • We want TeamCity‘s Feature back: Pre-Tested Commits
  • Breaking the build is no crime!
  • Voraussetzung: Einfaches Branching und Merging
  • 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
  • Variation: Feature Branches
  • 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 ...
  • 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
  • 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
  • Vorteile Als Entwickler verbringe ich nicht unnötig Zeit damit Dinge zu fixen, die andere kaputt gemacht haben
  • Eine Umsetzung +
  • Jenkins Git Plugin 1/3 Überwache Entwicklerbranches
  • Jenkins Git Plugin 2/3 Merge Entwickler-Branch auf Development-Branch
  • Jenkins Git Plugin 3/3 Push merged Development-Branch zurück, wenn Build erfolgreich
  • 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
  • Demo ...
  • 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
  • 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
  • Kriterien für „Gut-Genug“ Lesson Learned: Die Kriterien ändern sich im Projektverlauf
  • 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
  • Die Konsequenz ...
  • 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:
  • 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:
  • Dies und das ...
  • Durchsetzen der Konvention: Protected Branches
  • 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
  • Pull statt fetch/merge [branch "rat/for-development"] remote = origin merge = refs/heads/rat/for-development .git/config
  • 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
  • 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
  • Gotchas Polling durch Jenkings und mehrere Commits in Zeitfenster Besser: post-receive Hook Web Hooks in Stash und GitLab
  • Gotchas „Git hat meine Änderungen verschlampt“ == „Ich habe nicht gemerkt, dass mein Commit nicht sauber gemerged werden konnte“
  • Noch Fragen?
  • 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