Advanced Continuous Integration
Als PPTX, PDF herunterladen0 gefällt mir3,521 aufrufe
Der Bericht von Opitz Consulting beschreibt deren Mission, branchenübergreifend Lösungen zu entwickeln, die Organisationen helfen, wettbewerbsfähig zu bleiben, und die Wichtigkeit von Continuous Integration (CI) im Entwicklungsprozess. Der CI-Prozess wird erläutert, um qualitativ hochwertigen Code durch gemeinsames Testen und Integration zu gewährleisten, während Entwickler unabhängig arbeiten können. Des Weiteren werden Herausforderungen, Best Practices und die Rolle von Tools wie Jenkins und Git zur Optimierung des CI-Workflows diskutiert.
![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](https://image.slidesharecdn.com/don-t-break-the-build-2-131011024931-phpapp01/85/Advanced-Continuous-Integration-9-320.jpg)
![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](https://image.slidesharecdn.com/don-t-break-the-build-2-131011024931-phpapp01/85/Advanced-Continuous-Integration-10-320.jpg)
![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](https://image.slidesharecdn.com/don-t-break-the-build-2-131011024931-phpapp01/85/Advanced-Continuous-Integration-11-320.jpg)
![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](https://image.slidesharecdn.com/don-t-break-the-build-2-131011024931-phpapp01/85/Advanced-Continuous-Integration-12-320.jpg)
![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](https://image.slidesharecdn.com/don-t-break-the-build-2-131011024931-phpapp01/85/Advanced-Continuous-Integration-13-320.jpg)
![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."](https://image.slidesharecdn.com/don-t-break-the-build-2-131011024931-phpapp01/85/Advanced-Continuous-Integration-14-320.jpg)
![Pull statt fetch/merge
[branch "rat/for-development"]
remote = origin
merge = refs/heads/rat/for-development .git/config](https://image.slidesharecdn.com/don-t-break-the-build-2-131011024931-phpapp01/85/Advanced-Continuous-Integration-42-320.jpg)
![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](https://image.slidesharecdn.com/don-t-break-the-build-2-131011024931-phpapp01/85/Advanced-Continuous-Integration-43-320.jpg)
![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](https://image.slidesharecdn.com/don-t-break-the-build-2-131011024931-phpapp01/85/Advanced-Continuous-Integration-44-320.jpg)
Advanced Continuous Integration
- 2. Wer sind wir? Richard.Attermeyer@opitz-consulting.com Twitter: attermr GitHub: rattermeyer Stefan.Scheidt@opitz-consulting.com Twitter: stefanscheidt GitHub: stefanscheidt
- 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
- 6. Also mussten wir uns beeilen ...
- 7. Aber manchmal waren wir zu schnell ...
- 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. 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. 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. 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. 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. 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. 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. Wie kann ein Prozess aussehen, bei dem ein kaputter Build kein „stop- the-line“ bedeutet?
- 17. We want TeamCity‘s Feature back: Pre-Tested Commits
- 18. Breaking the build is no crime!
- 19. Voraussetzung: Einfaches Branching und Merging
- 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
- 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. 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. 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. Vorteile Als Entwickler verbringe ich nicht unnötig Zeit damit Dinge zu fixen, die andere kaputt gemacht haben
- 26. Eine Umsetzung +
- 27. Jenkins Git Plugin 1/3 Überwache Entwicklerbranches
- 28. Jenkins Git Plugin 2/3 Merge Entwickler-Branch auf Development-Branch
- 29. Jenkins Git Plugin 3/3 Push merged Development-Branch zurück, wenn Build erfolgreich
- 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. Demo ...
- 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. 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. Kriterien für „Gut-Genug“ Lesson Learned: Die Kriterien ändern sich im Projektverlauf
- 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
- 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. 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. Dies und das ...
- 40. Durchsetzen der Konvention: Protected Branches
- 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. Pull statt fetch/merge [branch "rat/for-development"] remote = origin merge = refs/heads/rat/for-development .git/config
- 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. 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. Gotchas Polling durch Jenkings und mehrere Commits in Zeitfenster Besser: post-receive Hook Web Hooks in Stash und GitLab
- 46. Gotchas „Git hat meine Änderungen verschlampt“ == „Ich habe nicht gemerkt, dass mein Commit nicht sauber gemerged werden konnte“
- 47. Noch Fragen?
- 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