Proč nepoužívat Feature Branching

Pod minulým příspěvkem ThoughtWorks Technology Radar 10/2012 se rozpoutala diskuse ohledně (ne)vhodnosti Feature Branching. Proč vlastně považuji Feature Branching za nevhodnou techniku?

Problematika je pěkně vysvětlena ve výborném článku Martina Fowlera Feature Branch z roku 2010. Krátké shrnutí: Feature Branching je v rozporu s Continuous Integration, způsobuje velké hrůzostrašné slučování změn (Big Scary Merge) a tím odrazuje od častého pročišťování kódu (refactoringu).

eXtreme Programming

XP kromě Continuous Integration doporučuje taky krátké iterace (ideálně týdenní). Aby bylo možné každý týden dodat ucelenou funkcionalitu, tak potřebujeme dělat malé, inkrementální změny. Jak na úrovni fíčur (musíme se vejít do krátké iterace), tak na úrovni commitů (aby na jedné fíčuře mohlo spolupracovat víc lidí a dala se průběžně testovat).

Já tvrdím, že každá změna (ať už je to nová fíčura nebo refaktoring) se dá rozdělit na sérii malých ucelených kroků. Takových, že každý krok zabere max. půl dne práce, a na konci je aplikace ve funkčním stavu (unit-testy samozřejmě procházejí). Pak lze udělat commit přímo do hlavní větvě a nepotřebuji Feature Branch.

Je jasné, že pokud neumím pracovat po tak malých inkrementech, tak Feature Branch vypadá jako lákavé řešení. Bohužel vyléčí symptomy, ne příčinu.

Kanban & Lean

Všechny změny, které jsou ve Feature Branch a neprošli integrací se všemi ostatními změnami, jsou vlastně work-in-progress. Dokud neproběhne integrace, tak můj kus práce není hotový.

Čím déle moje Feature Branch existuje, tím víckrát je potřeba udělat sloučení změn (ať už s hlavní větví, nebo ostatními Feature Branch). I když většina sloučení proběhne automaticky, tak se občas vyskytne potřeba ručného vyřešení konfliktů. Každé takové řešení konfliktů je ztrátou času, neboli odpadem (waste).

Kanban a Lean metodiky nás vedou k tomu, abychom minimalizovali jak work-in-progress, tak waste. Jinak řečeno, abychom nepoužívali Feature Branching.

Závěr
Na většinu projektů se Feature Branching nehodí. Důležitou výjimkou z tohoto pravidla je svět Open Source Software, kde vývoj probíhá pomaleji, a Feature Branching je naopak vyžadovaným postupem.

22 thoughts on “Proč nepoužívat Feature Branching
  1. Ondro normálně do mastru. Pokud procházejí testy můžeš i pushnout. Lokální klon repa je přece už sám o sobě větví. Pokud děláš nějakou zásadní změnu je dobré ji oddělit abstrakcí a dělat v izolaci (ale stále součástí veškerého kódu), tak aby pushe nerozbily aplikaci. Nasazení featury je pak věcí konfigurace IoC kontejneru nebo přepínače v aplikaci.

  2. Martin Fowler se mýlí. Feature branche se nevylučují s Continuous Integration, nebrání refaktoringu a ani nevede k strašnému mergování. A taky Feature Branche nebrání krátkým iteracím. Merge (nevím, jak v jinde) trvá v Mercurialu 1 sekundu. To je velmi malý waste a tento argument mi přijde jako už naprosto lichý kopanec do FB.

    Respektuju Branch by Abstraction, ale FB je jednodušší a pokud feature branch žije maximálně 2 dny a nepřežije přelom sprintu, nebrání žádnému solidnímu programátorskému postupu.

    Sám jsem ve FB roky fungoval, průběžně integroval svou práci, mergování nebyl problém a FB nebyly ani zdaleka největším zdrojem waste při práci.

  3. Jirko, pokud někdo udělá refactoring, tak tvůj feature branch jím zůstane nepoznamenaný. O to jde. A čím větší featura, tím větší konflikt a problémy s mergováním. A jak už jsem psal, lokální clon je branch sám o sobě, proč přidávat ještě další úroveň a přidávat další risk/cost?

    Já mám za sebou více než 4 roky mainline vývoje, zkoušel jsem i feature branche, ale vůbec se to nedá srovnávat. Vzhledem k tomu, že jsem naučenej dělat architekturu tak, aby se věci dali snadno měnit a přepínat, tak pro FB nevidím žádný důvod a spíš jen negativa.

    Já preferuju chytrou lenost a FB je práce navíc. :)

  4. Díky Jirko za opačný názor. Zajímalo by mě, co ti FB přinášeli, když žili jenom jeden-dva dny? A taky kolik lidí na projektu pracovalo?

  5. Pokud děláš nějakou zásadní změnu je dobré ji oddělit abstrakcí a
    dělat v izolaci (ale stále součástí veškerého kódu), tak aby pushe
    nerozbily aplikaci.

    Tvorba one abstrakce neni waste?

  6. Aleši, pro mě je feature branch velkou měrou přidávání sémantiky do zdrojového kódu. Mnohokrát jsem nastartoval feature branch, ale pracovalo nás na něm víc, v tu chvíli se stal mainline (90 % commitů týmu šlo do jednoho branche), jen jeden kolega třeba zkoušel nějaký experiment, který mohl a nemusel vyjít. Jakmile byla práce hotova, sloučili jsme branch do sprint branche a založili jsme další na další story. A pokud jsme na jedné story dělali ve více lidech, opět se z toho branche stail mainline. Práci jsme za sebe rebasovali.

    A někdy jsme fungovali i běžně, jako fungují feature branche obvykle.

    Co nám to dalo? Sémantiku, kterou můžeme využít při automatizaci deploymentu, při zjednodušování code review, při dohledávání věcí v kódu v dávné historii, možnost experimentovat a experiment zahodit. Zkrátka lepší produktivitu, kvalitu i flexibilitu.

    Co nám to vzalo? Nutnost na začátku napsat “hg branch” a na konci “hg merge; hg commit -m ‘Merging X’ –close-branch”. Dohromady 10 vteřin?

    Vývoj v mainline jsem provozoval podobně dlouho, jako ty. 3 roky už dělám FB a taky nekoukám zpět a nelituju.

  7. Jirka to vystihl myslím celkem přesně.

    Ještě co se týče Big Scary Merge, tak je to přesně naopak. FB vytváří daleko menší a snáze řešitelné konflikty. Příklad:

    V SVN někdo commitne velký refactoring. Já mám u sebe změny, které jsou s tím v konfliktu. Udělám update a musím vyřešit jeden velký konflikt.

    V Gitu bez FB někdo pushne velký refactoring. Udelám pull a vznikne mi jeden velký merge konflikt.

    V Gitu s FB někdo pushne do masteru velký refactoring. Když budu chtít svoji větev aktualizovat, udělám rebase na master a vyřeším několik menších konfliktů – vždy řeším jen konflikt aktulního rebasovaného commitu oproti masteru.

  8. Daniele, ve tvé úvaze jsi vynechal důležitou podmínku – u sebe mám rozdělanou práci o rozsahu max. půl dne.

    To znamená:

    Když v SVN/GIT bez FB někdo dělá refactoring, tak začne tím, že si vezmě poslední verzi a tím pádem udělá refaktoring i v mé pomyslné FB (protože commitu jsou dávno v hlavní větvi).

    Já si udělám co nejdřív update a vyřeším konflikt aktuální práce (tedy rozsahem max. poslední půlden).

    Tím pádem je to ekvivalentní tomu, že “vždy řeším jen konflikt aktuálního rebasovaného commitu oproti masteru”. Protože “aktuální rebasovaný commit” odpovídá přesně tomu, co mám u sebe rozdělané a není to pushnuté do hlavní větvě.

  9. Jasně, rozumím. Nic to ale nemění na faktu, že strach z velkých konfliktů pochází z práce s větvemi v SVN a v současných moderních DVCS se s tím už dávno nesetkáme.

  10. mainline jsem používal několik let na menších projektech o 1 – 2 lidech, naprosto jsem si nedokázal představit, že svět může být i jinak barevný.

    U ale jednoho většího projektu s 8 – 10 vývojáři jsem začal narážet. Ne vždy je možnost sestavit tým z profi vývojářů, unit testy mnoho chyb nevyřeší a klient potřebuje pár dní na schválení a připomínkování. Podtrženo a sečteno, do mainline se začaly dostávat chyby navzdory všem kontrolám a testům, v mainline začalo být příliš dead kódu, který nikdy nebyl schválen k nasazení.

    FB byl řešením (ne ideálním, ne jediným). Každopádně poskytuje lepší kontrolu nad kódem, v případě, že feature má delší iteraci než je zdrávo. S refactorem a ani s konflikty u mergováním nejsou zásadní problémy, git cherry-pick a trochu skriptů řeší vše podstatné.

  11. Honzo, to co popisuješ je krásný příklad řešení příznaků špatně fungujícího teamu na úplně špatné úrovni. Neřeší však problém samotný, pouze ho odsouvá. Někdy to může být krátkodobě výhodné, aledlouhodobě neudržitelné.

    Mainline vývoj je spjat se spoustou dalších disciplín, který když neděláš, tak to bolí. A to je dobře, že to bolí, proto se to taky dělá, aby byla vidět slabá místa, na kterých je třeba zapracovat. FB tohle zahaluje.

  12. Jirko, dovedu si představit jak zanést do kódu sémantiku mnohem trvaleji a hondotněji – přímo na úrovni kódu. VCS je jen nástroj, zdrojový kód je výstupní dokument.

  13. Aleši, máš pravdu, je to jen obezlička, záplatování nějakého nedostatku a dlouhodobě to je neudržitelný. Pro mě FB je skoro symbolem nedůvěry mezi lidmi.

    Opravdu, dobře fungující tým nepotřebuje FB. Mainline klade velký důraz na schopnost spolupráce programátorů mezi sebou a dále jí rozvíjí, což je úžasné v takovém týmu dělat. Kdo zkusí, už nechce nic jiného.

    Každopádně svět není růžový a bohužel mezi námi je ještě obrovské množství nefungujících firem, já do jedné takové před několika týdny nastoupil, asi mě to i začalo bavit.

    Já FB řeším špatnou odbornost programátorů, kdy je potřeba přísná kontrola a častá revize kódu a naprosté nepochopení práce s vývojem aplikace od vedení/klientů. Jinej případ, kdy může být FB přínosem neznám. Postupně jak odpadávají překážky, master větev přestává být zakázaným ovocem.

    FB je vždy komplikace, buď to znamená, že je jeden člověk, který se o to musí starat, a ano, je to moc práce. Nebo se o to starají všichni, v tom případě nevidím jediný důvod k FB a ty porodní bolesti při začátcích mainline za to stojí.

  14. ako riesite pri mainline vyvoji code review? Obavam ze pri mainline vyvoji sa z VCS stava len zdielane ulozisko zdrojakov, orientovat sa v historii je parkticky nemozne kedze ku jednej feature tam je 15 commitov poprepletanych s dalsimi 100 ostatnymi commitmi. Osobne preferujem strednu cestu medzi FB a mainlinom – pride mi vhodnejsie commitovat raz za 2-3 dni ako si umelo rozsekavat featury na prilis male celky. Celkovo pripady ze kolega urobi zasadny refaktoring a ja to musim pol dna mergovat sa nestavaju tak casto aby bolo potrebne commitovat kazdy polden a 2-3 dnovy FB cyklus mi pride ako rozumny kompromis.
    V konecnom dosledku by mali commity odzrkadlovat logicke celky a nie casove intervaly.

    Svoj nazor k tomu som spisal sem: http://blog.mawek.cz/2012/10/mainline-versus-feature-branch.html

  15. Marku, jak jsem psal výše, mainline vývoj je spjat s dalšími extrémními praktikami a jednou z nich je i párové programování. Párové programování odstraňuje potřebu obrovského overheadu zvaného Code Review.

    Celkovo pripady ze kolega urobi zasadny refaktoring a ja to musim pol
    dna mergovat sa nestavaju tak casto

    to by se nemělo stávat vůbec. Něco jako “zásadní refactoring” je redesign. Refactoring je třeba dělat průběžně a hned integrovat. redesign je třeba dělat bezpečnými technikami inkrementálních změn, tj. pomocí refactoringu a pak je to opět bezpečné.

    I 2-3 denní FB znamená, že je systém v neznámém stavu, nezintegrovaný a tudíž roztroušený po různých čertech.

  16. You will find a lot of approaches after visiting your post. I was exactly searching for. Thanks for such useful post!
    buy rubber flooring UK from Rubberflooringco.co.uk

  17. This website is help me in my study. I found it very interesting. I will check back later to see if more posts are updated.
    shop our collection of exercise gym mats from rubbergymmats.co.uk

Blog byl staticky vyexportován, nové komentáře již nelze přidávat.