Prezentációm a Makuka meetupon, 2018.11.13. Miskolc, Helynekem Youtube: https://www.youtube.com/watch?v=FlQw6Yerhxs Marhefka István, agile coach, T-shaped Software Kft. Blog: https://istvanmarhefka.com E-mail: hello@istvanmarhefka.com

1. Feature branches
vs.
Trunk based development
Marhefka István
Agile Coach, Software Architect
T-shaped Software Kft.
https://istvanmarhefka.com
hello@istvanmarhefka.com

2. Forrás: https://stxnext.com/blog/2018/02/28/escape-merge-hell-why-i-prefer-trunk-based-development-over-feature-branching-and-gitflow/

3. Gitflow: miért jó?
• Aszinkron működés, nem kell várni senkire
• Nagyfokú párhuzamosítás
• Heterogén csapat, elosztott csapat
• pull request: code review (GitHub)
• Legacy kódban minőség fenntartása (code review)

4. Gitflow: miért nem jó?
• „Merge-pokol”
• Senki sem szereti a merge conflictokat feloldani
• Bátorítja a hosszú életű branchek létrejöttét
• Merge-ök kockázatosak  több hibalehetőség
• Mikor van kész egy sztori?
• Lassabb és drágább szállítás
• Nem alkalmas Continuous Integrationre (Continuous Delivery alapja)

5. Continuous Integration felmérés
1. Ki használja?
2. Mindenki commitál a csapatban legalább 1x egy nap a
masterre/trunkra?
3. Lefut-e minden commit után automatizált build és teszt?
4. Ha elszáll a build, 10 percen belül újra minden zöld lesz?

7. Trunk-based development
Forrás: https://stxnext.com/blog/2018/02/28/escape-merge-hell-why-i-prefer-trunk-based-development-over-feature-branching-and-gitflow/

8. Hogyan commitáljak folyamatosan, ha a
fejlesztendő sztorit sokáig tart implementálni?
• BDD/TDD
• Tervezés fontossága (Scrum team)
• Apró commitálható részek sorozataként kell szállítani
• Folyamatosan backward compatible kódot kell írni
• Feature toggles/feature flag
• konfig fájl
• adatbázis

9. Code review
• Shared understanding
• Sztori már közösen megtervezve (Scrum team)
• Apró commitok, amiket könnyű review-zni
• Folyamatosan kell csinálni, nem szabad napokat várni
• Eszköz támogatás pl. UpSource, IntelliJ Idea

10. Production bug javítása
• Trunkon történik a javítása
• Aztán:
• VAGY: cherry pick (ha nagyon muszáj)
• VAGY: roll forward (új release)

11. Continuous Integration miért jó?
• Egyszerű folyamat (egy branch, trunk)
• Hozzájárul a fejlesztés közbeni flow-élményhez
• Gyors és hatékony fejlesztés
• Continuous Delivery első lépése (commit stage)

12. Continuous Integration kihívások
• Hatékony tesztek (10 percen belül visszajelzés)
• Distributed team
• Code review-nek hamar meg kell történnie – multitasking?
• Fegyelmezettség csapat szinten
• Bizalom a csapatban és a csapat felé

13. Continuous Integration nem lehetséges
• Ott, ahol tilos hibázni
• Sokan dolgoznak egyszerre a kódon
• Ha nagy a tudásbeli különbség a tagok között (vagy nem bíznak
egymásban)
• Ha extrém sok a multitasking (állandó tűzoltás)
• Legacy kódban (tesztek hiánya)

14. Konklúzió
• Git: cool, branchek létrehozása olcsó
• Continuous Delivery > Continuous Integration > Trunk based
development
• Csábít a GitFlow modell, de hogyan tudnánk mégis megvalósítani az
adott projekten a Trunk based developmentet?

15. Hivatkozások
• https://martinfowler.com/bliki/ContinuousIntegrationCertification.ht
ml
• https://martinfowler.com/articles/continuousIntegration.html
• https://trunkbaseddevelopment.com
• https://martinfowler.com/bliki/ContinuousDelivery.html
• https://stxnext.com/blog/2018/02/28/escape-merge-hell-why-i-
prefer-trunk-based-development-over-feature-branching-and-
gitflow/

16. Köszönöm a figyelmet!
Marhefka István
Agile coach, software architect
Blog: https://istvanmarhefka.com
E-mail: hello@istvanmarhefka.com