Der Mythos der Trunk-basierten Entwicklung
•
1 like•1,085 views
www.opitz-consulting.com Langlebige Branches sind out - es lebe die Trunk-basierte Entwicklung. So oder ähnlich lautet ein Mantra im Bereich Continuous Delivery. Und das ist richtig. Aber wenn man die Trunk-basierte Entwicklung naiv einführt, dann schadet sie vielleicht mehr, als sie nützt. Im Rahmen ihres Vortrags bei der Continuous Lifecycle Conference am 16.11.2016 berichteten Richard Attermeyer (OPITZ CONSULTING) und Jens Kanschik (ista) von ihrer "Reise" von Story-Branches über naive Trunk-basierte Entwicklung hin zu einem Pre-Tested-Commit Workflow. Dabei zeichnen sie nach, welche Anforderungen maßgeblich für die jeweilige Entscheidung für ein Branching- und Commit-Modell und wie die Erfahrungen in einem Projekt mit vier Entwicklungsteams waren.
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Similar to Der Mythos der Trunk-basierten Entwicklung
Similar to Der Mythos der Trunk-basierten Entwicklung (20)
More from OPITZ CONSULTING Deutschland
More from OPITZ CONSULTING Deutschland (18)
Der Mythos der Trunk-basierten Entwicklung
- 1. © OPITZ CONSULTING 2016© OPITZ CONSULTING 2016 Richard Attermeyer, OPITZ CONSULTING Jens Kanschik, ista International GmbH Der Mythos der Trunk- basierten Entwicklung
- 2. © OPITZ CONSULTING 2016 "Weg" (CC BY-SA 2.0) by sternenseemann
- 3. © OPITZ CONSULTING 2016 "124/355 - Symmetrie / Symmetry" (CC BY 2.0) by Boris Thaser Rahmenbedingungen Agile Entwicklung nach SAFe 4 Entwicklungsteams mit 27 Entwicklern & Testern 2 Wochen Sprints 6 Fachmodule Gemeinsame GUI Integration mit Umsystemen
- 4. © OPITZ CONSULTING 2016 für unfertige Stories "Stop" (CC BY-SA 2.0) by Der Stefan
- 5. © OPITZ CONSULTING 2016 Unabhängigkeit "DSCN0912" (CC BY-SA 2.0) by vdespa
- 6. © OPITZ CONSULTING 2016 Realität "Stau auf der A661 bei Offenbach Kaiserle" (CC BY-ND 2.0) by tacker
- 7. © OPITZ CONSULTING 2016 "Weggabelung" (CC BY 2.0) by Faldrian. Entscheidung Kopplung abschaffen Common in jedem Projekt implementieren Client Module abschaffen Unabhängig entwickeln Zusammen bauen und deployen
- 8. © OPITZ CONSULTING 2016 Entscheidung Unabhängig entwickeln Zusammen bauen und deployen "Weggabelung" (CC BY 2.0) by Faldrian.
- 9. © OPITZ CONSULTING 2016 Unabhängig entwickeln Zusammen bauen und deployen Das System muss als Ganzes funktionieren Bis (mindestens) zum ersten Produktivgang gibt es keine unabhängigen Deployments je Modul Unabhängigkeit ist ein architektonisches Ziel Unabhängigkeit: aktuell zu viel Overhead und zu wenig Vorteil
- 10. © OPITZ CONSULTING 2016 Unabhängig entwickeln Zusammen bauen und deployen Mit dem Modell: alles als ein Multimodulprojekt (Maven) sind wir zufrieden + project-parent +---- modul_1-parent | +----submodul_1 | +----submodul_2 +---- modul_2-parent | +----submodul_1 | +----submodul_2
- 11. © OPITZ CONSULTING 2016 "Applaus!" (CC BY-ND 2.0) by spdsaar
- 12. © OPITZ CONSULTING 2016 Können wir Story XYZ im Review zeigen? Ja, muss nur noch gemerged werden Also, nein. "Applaus!" (CC BY-ND 2.0) by spdsaar
- 13. © OPITZ CONSULTING 2016 "Sandales" (CC BY 2.0) by Gilles FRANCOIS Der Heilsbringer
- 14. © OPITZ CONSULTING 2016 Der Heilsbringer
- 15. © OPITZ CONSULTING 2016 „ “(Mainline development) is an extremely effective way of developing, and the only one which enables you to perform continuous integration.
- 16. © OPITZ CONSULTING 2016 "Gutierrez crashed @ T14 with an India Fo" (CC BY-SA 2.0) by emperornie
- 17. © OPITZ CONSULTING 2016 "Red Light" (CC BY 2.0) by lorentey
- 18. © OPITZ CONSULTING 2016 Simple process to follow Continuous Delivery, Jez Humble et al. Here is a simple process to follow: 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 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.
- 19. © OPITZ CONSULTING 2016 "Scream" (CC BY 2.0) by crosathorian"Scream" (CC BY 2.0) by crosathorian
- 20. © OPITZ CONSULTING 2016 CI System soll für mich arbeiten - nicht umgekehrt WTF! 30 Minuten warten, um sicher zu gehen, dass alle Tests immer noch ok sind? Ich will einchecken wann ich will Ich will meinen Build kaputt gehen lassen, wann ich will "Scream" (CC BY 2.0) by crosathorian
- 21. © OPITZ CONSULTING 2016 "Davenport Jail" (CC BY-SA 2.0) by schnaars Breaking the build is not a crime
- 22. © OPITZ CONSULTING 2016 Was stimmt nicht mit Trunk- Based Development?
- 23. © OPITZ CONSULTING 2016 Daran ist nichts falsch!
- 24. © OPITZ CONSULTING 2016 Nur die meisten verstehen nicht, was damit gemeint ist
- 25. © OPITZ CONSULTING 2016 Kennen Sie diesen Mann? Paul Hammant
- 26. © OPITZ CONSULTING 2016 Aussagen […] TBD is where all developers […] commit to one shared branch under source-control. Developers do not break the build with any commit. Hier hören viele auf zu lesen…. More sophisticated companies will use pre-commit verifications. Devs take on habit: prove the commit is good, by synchronizing to the the trunk’s latest revisions, building from root/scratch, double-checking their functional change, then committing. Hier hören viele auf zu denken….
- 27. © OPITZ CONSULTING 2016 Rebase Build & Test Commit
- 28. © OPITZ CONSULTING 2016 Das muss nicht auf dem eigenen Rechner passieren!
- 29. © OPITZ CONSULTING 2016 One single repo Mondrian / Gerrit Extensive Tooling Googles Workflow
- 30. © OPITZ CONSULTING 2016 "Trunks" (CC BY-ND 2.0) by sarae Ausgangssituation: Trunk Based Development
- 31. © OPITZ CONSULTING 2016 Ausgangssituation: Trunk Based Development Meistens schlagen E2E-Tests fehl Fehlschläge in allen Teams Umbauten in der GUI, aber auch Backend sorgen dafür, dass zum Teil mehrere Tage der Build fehlschlägt Als Lösung nutzen Teams Branches, allerdings ohne jegliche CI-Unterstützung
- 32. © OPITZ CONSULTING 2016 Anforderungen"“Chaos in the world brings uneasiness," (CC BY 2.0) by katerha
- 33. © OPITZ CONSULTING 2016 Anforderungen Bei Abhängigkeiten zwischen den Teams müssen auch Zwischenstände einer Story für andere Teams verfügbar sein Fehler in den Builds bzw. Behebung der Fehler sollen möglichst schnell sichtbar sein Im Regelfall sollte das System als Ganzes funktionieren und auf Test deploybar sein Fehlgeschlagene Builds sollten mit Commits im Zusammenhang stehen
- 34. © OPITZ CONSULTING 2016 Anforderungen Größere Änderungen dürfen nicht dazu führen, dass andere Ergebnisse nicht ausgeliefert werden können. Bei bestimmten Arten von Stories sollten keine Zwischenergebnisse deployed werden, sondern erst der fertige Stand. Umfangreiche Merges sind zeitaufwändig zu vermeiden Regelmäßige, kleine Merges sind in der Regel kein Problem Auch halbfertiger Code soll eingecheckt werden können, z.B. am Feierabend oder um mit Kollegen an einem Problem zu arbeiten.
- 35. © OPITZ CONSULTING 2016 "Hauptuntersuchung" (CC BY-ND 2.0) by tuv_sud Pre-Tested-Commits
- 36. © OPITZ CONSULTING 2016 Pre-Tested-Commits Entwickler committen nicht direkt auf den trunk Sondern auf einem Branch (XXX/for/trunk) CD System führt für jeden Commit eine Pipeline aus Rebase, Tests, Merge in Trunk
- 37. © OPITZ CONSULTING 2016 Branching Modell trunk rat/for/trunk team/for/trunk story/for/trunk Entwicklungsbranch in den integriert werden soll Branch pro Entwickler / Story / Team mit Namenskonvention
- 38. © OPITZ CONSULTING 2016 Delivery Pipeline: Pretested Commit Rebase Pre-Flow Merge into Master Master Flow Deploy UAT Deploy Cap Deploy Mig Deploy Dyn Deploy Test Branches werden vom CD System vor Start einer Pipeline gerebased. Branches werden vom CD System wieder in trunk reintegriert
- 39. © OPITZ CONSULTING 2016 Konfigurationsmöglichkeit Konfiguration von Branches erfolgt durch eine Datei im Worktree: config/XXX.properties Reintegration branch in trunk nach grüner Pipeline (j/n) Liste der auszuführenden E2E Test Suiten Automatisches merge trunk in branch, wenn keine Konflikte (j/n) Nutzung des gleichen Flow-Skripts für Master und Branch
- 40. © OPITZ CONSULTING 2016 Branching Modell Es darf auch immer auf den Master committet werden Schnell Änderungen an alle Teams / Branches verteilen Um den Master schnell wieder grün zu bekommen Aber man sollte wissen, was man tut oder mit dem Zorn der Kollegen leben
- 41. © OPITZ CONSULTING 2016 Rebase Push triggert Gitlab Web Hook Gitlab Web Hook triggert „Rebase Job“ Rebase Job ist geskripted Rebase Branch Triggere erst Flow, wenn kein rebase erforderlich Push im Rebase triggert ja über Webhook direkt wieder ein Rebase Brich ab, wenn Rebase nicht automatisch möglich Trunk Branch Pre-FlowMerge notwendig? ja Merge Commit Push nein
- 42. © OPITZ CONSULTING 2016 Testsuiten Branch Config ermöglicht Steuerung schnelleres Feedback vs. höheres Risiko Wenn nur an einem Teil gearbeitet wird, brauchen nicht im Branch alle Tests laufen Aktuell auf E2E Tests beschränkt, da diese am Längsten laufen Im Trunk laufen immer alle Tests Der Trunk darf rot werden (etwa Regressionsfehler), aber er sollte nicht regelmäßig rot sein
- 43. © OPITZ CONSULTING 2016 Erkenntnisse Trunk Based Development Arbeiten direkt auf dem Trunk ist schwierig und nicht die Lösung unserer Probleme Naives Trunk Based Development erfüllt nicht die Anforderungen Feature-Toggles, Branching by Abstraction etc. würden aktuell technische Schulden erzeugen und Testen erschweren Pre-Tested Commits erfüllen für die Neuentwicklung unsere Anforderungen am besten Branches werden transparent unterstützt Branches entfernen sich nicht weit vom Trunk Merge in Trunk ist automatisch möglich Trunk bleibt grün
- 44. © OPITZ CONSULTING 2016 Erkenntnisse zu Pre-Tested Commits Jeder Push triggered Build Höherer Ressourcenbedarf vs. Zuordnung Fehler zu Push Gegen Sprintende sollte Master Flow gegenüber Branch Flows priorisiert werden Cloudansatz mit Skalierung der Infrastruktur vor Sprintende hilfreich Kenne deine Anforderungen und entscheide dann über den Workflow
- 45. © OPITZ CONSULTING 2016 Seite 49 Fragen & Antworten
- 46. © OPITZ CONSULTING 2016 Seite 50 Blogpost
- 47. © OPITZ CONSULTING 2016 @OC_WIRE OPITZCONSULTING opitzconsultingWWW.OPITZ-CONSULTING.COM Richard Attermeyer Senior Solution Architect OPITZ CONSULTING Deutschland GmbH richard.attermeyer@opitz-consulting.de Telefon +49 2261 60 01-1713 Mobil +49 173 727 9004 Jens Kanschik IT Architekt ista International GmbH jens.kanschik@ista.com Telefon +49 201 459 – 0
Editor's Notes
- Wir wollen Sie in diesem Vortrag auf eine Reise mitnehmen und von unseren Erfahrungen berichten, die wir mit unterschiedlichen Branching Methoden gemacht haben. Der Weg war in der Tat etwas steinig. Und wie auch häufiger in den Bergen war nicht immer klar erkennbar, was uns hinter der nächsten Abbiegung erwartet oder welchen Weg wir gehen sollten.
- Wir haben am Anfang gestritten, wie wir mit der Entwicklung einzelner Stories umgehen. Durchgesetzt haben sich diejenigen, die keine unfertigen Stories ausliefern wollen… auch wenn alle Tests für die erstellten Teile grün sind. Dies bedingt, dass wir jede Story in einem Story Branch entwickeln.
- Jedes Fachmodul sollte unabhängig von den anderen bauen. Und seine eigene Geschwindigkeit bestimmen können. Schließlich sollen die einzelnen Fachmodule später auch unabhängige Deploymentzyklen besitzen.
- Die Realität sah aber ganz anders aus… wie so häufig. Wir standen häufig im Stau. Wir warteten. Und hatten gleichzeitig alle Hände voll zu tun. Wir hatten ein common Projekt. Fachmodule sind über das common Projekt gekoppelt. Es wird etwas am common Modul geändert. Wenn die Änderung wichtig ist für die andern Projekte (und das ist sie in der Regel), dann müssen die Projekte warten, bis das common Modul gebaut und eine neue Version verfügbar ist. Module sind ebenfalls über die Client Module gekoppelt, die ein Modul für alle Clients zur Verfügung stellt. Oder ander ausgedrückt: Module sind über ihre Schnittstellen gekoppelt. Wenn eine Schnittstelle in der Entwicklung ist und noch regelmäßig Anpassungen erfährt (etwa beim Format des Payloads), dann müssen die Clients nachziehen (wenn sie im gleichen Sprint am gleichen Feature arbeiten).
- Das haben wir doch dann gut gemacht, oder? Also lassen wir uns feiern
- Zwar war das Handling in der Entwicklung einfacher. Aber Story Branches waren von der Entwicklung des Masters abgekoppelt. Ein Merge konnte durchaus 2 Tage in Anspruch nehmen. Die Differenzen zum Master konnten schnell sehr groß werden.
- Manchmal erscheint dann ein Heilsbringer, dem man nur noch folgen muss. Folgt der Sandale! (Übereinstimmungen mit Life of Brian sind rein zufällig).
- Manchmal erscheint dann ein Heilsbringer, dem man nur noch folgen muss. Folgt der Sandale! (Übereinstimmungen mit Life of Brian sind rein zufällig).
- Jetzt geht alles reibungslos und schnell… leider: nein.
- Allerdings waren alle Ampeln auf rot. Und das die meiste Zeit. Wir waren nicht in der Lage zum Review etwas auf die Reviewumgebung zu bringen. Auch wenn ein Fehler schnell behoben wurde, dann war meistens der nächste Fehler drin, welcher die Pipeline rot bleiben ließ. Irgend etwas machen wir falsch, oder?
- Standardvorgehen / Clean Code / Craftsmanship in Frage stellen Dzone Artikel? Interaktiv: Teilnehmer fragen
- Bei Abhängigkeiten zwischen den Teams müssen auch Zwischenstände einer Story für andere Teams verfügbar sein: Beispiel: In App X wird eine Schnittstelle bereitgestellt, die von App Y genutzt wird. Diese Schnittstelle sollte so schnell wie möglich im Team 2 genutzt werden können. Fehler in den Builds bzw. Behebung der Fehler sollen möglichst schnell sichtbar sein: Beispiel: In einem E2E-Test tritt ein Fehler auf oder wird korrigiert; der Entwickler muss zur Zeit bis zu einer Stunde warten, bis es Feedback gibt. Beispiel: In einem E2E-Test tritt ein Fehler auf, aufgrund eines Fehlers in einem anderen Modul und aufgrund einer „fremden“ Story werden die E2E-Tests aber nicht gestartet. Im Regelfall sollte SYS als Ganzes funktionieren und auf Test deploybar sein: Für integrative Tests der Teams muss SYS auf die Test-Umgebung deployed werden; das ist nur sinnvoll, wenn die Applikation auch funktioniert (d.h. die Tests sind grün). Ohne solche Tests können bestimmte Stories nicht abgeschlossen werden. Fehlgeschlagene Builds sollten mit Commits im Zusammenhang stehen: Zurzeit ist es nicht immer möglich, am Commit den Grund für den fehlgeschlagenen Test zu ermitteln: zu häufig brechen Builds bereits vorher wegen anderen Stories/Infrastruktur ab, es sind Tests auskommentiert oder es werden nur einzelne Tests ausgeführt („fdescribe“).
- Größere Änderungen dürfen nicht dazu führen, dass andere Ergebnisse nicht ausgeliefert werden können. Beispiel: Ein Team führt Änderungen durch, die auf mehrere Stellen/Module Auswirkungen haben (Validierungen in den REST-Schnittstellen, Raum bei Geräten/Messstellen etc.). Während der Entwicklung werden nennenswerte Teile der Applikation inkonsistent/fehlerhaft sein. Das darf nicht dazu führen, dass die Teams nicht mehr arbeiten können bzw. nicht deployed werden kann. Bei bestimmten Arten von Stories sollten keine Zwischenergebnisse deployed werden, sondern erst der fertige (oder fast fertige) Stand. Beispiel: Änderungen am Datenmodell sind in sich konsistent und fehlerfrei, aber bei dem Import von Verträgen fehlt noch ein Teil der Logik. Importe aus SAP würden bei einem Deployment immer fehlschlagen.
- Aktuell ein Problem: Wir können das Starten des Flows nur durch einen Failure verhindern. Entwickler müssen Fehlernachricht genau lesen (Subject Line), um zu wissen, ob es ein echter Fehler ist. Das wird manchmal übersehen
- Aktuell ein Problem: Wir können das Starten des Flows nur durch einen Failure verhindern. Entwickler müssen Fehlernachricht genau lesen (Subject Line), um zu wissen, ob es ein echter Fehler ist. Das wird manchmal übersehen
- Das Konzept der Testuiten kann auch auf Integrationstests ausgeweitet werden