Trunk based development - hit, czy kit?

5

A co, jeśli na masterze znajdzie się kompletny i dokończony ficzer, ale nie będzie przez nikogo używany bo ktoś go źle zaprojektował?

No przed tym nie uratuje żaden gitflow, trunk based ani nic innego, a i tak się może zdarzyć - i ludzie z tym żyją :P

W trunk-based development nie ma 40 branchy to ogarniania / synchronizowania między sobą i nie ma (zwykle) problemów jak np. PRy na 15k linii zmian w 80 plikach. Nie ma rozwiązywania konfliktów przez dwa tygodnie, żeby po dwóch tygodniach rozwiązywać nowe konflikty przez następny tydzień. Wychodzę z mastera / maina z króko żyjącym (na czas jednego taska) feature branchem, po zatwierdzeniu zmian robię rebase + squash i tyle. Jeśli leci release z danego commita, to można go otagować i tyle.

0
superdurszlak napisał(a):

króko żyjącym (na czas jednego taska) feature branchem

Czas jednego taska to u ciebie zazwyczaj kilka godzin, dni, tydzień?
Czy efekt taska jest widoczny dla użytkownika końcowego? Czy regularnie zdarzają się taski "zrób coś tam, żeby w przyszłości dało się zrobić coś przydatnego"?

4
piotrpo napisał(a):

Czas jednego taska to u ciebie zazwyczaj kilka godzin, dni, tydzień?
Czy efekt taska jest widoczny dla użytkownika końcowego? Czy regularnie zdarzają się taski "zrób coś tam, żeby w przyszłości dało się zrobić coś przydatnego"?

Tak / nie / nie wiem / to zależy / różnie.

Jeśli to niczego nie psuje, to co za różnica? Jeśli nawet dodam zmiany, które nie wpłyną od razu na użytkownika końcowego - to tak właściwie co z tego? To mógł być task przygotuj codebase pod takie i siakie zmiany a mógł być dodaj logi bo nie wiemy co się dzieje jak jest pożar - z punktu widzenia użytkownika końcowego efekt jest widoczny tak samo, czyli wcale.

3
piotrpo napisał(a):

Czy efekt taska jest widoczny dla użytkownika końcowego? Czy regularnie zdarzają się taski "zrób coś tam, żeby w przyszłości dało się zrobić coś przydatnego"?

Czy użytkownik końcowy wie, czym są taski, kod źródłowy, i na czym polega zarządzanie kodem źródłowym?
Jeśli nie - to jakie to ma dla niego znaczenie, co się znajduje w kodzie.
Jeśli tak - to daj mu klawiaturę, i niech sobie sam napisze.

Git Flow to jakiś wynalazek germańskich architektów, którzy widząc zbyt szybki system kontroli wersji postanowili spowolnić go biurokracją.

0
somekind napisał(a):

Czy użytkownik końcowy wie, czym są taski, kod źródłowy, i na czym polega zarządzanie kodem źródłowym?
Jeśli nie - to jakie to ma dla niego znaczenie, co się znajduje w kodzie.

Jeżeli kod, który napisałeś i wszedł do wersji produkcyjnej nie jest podpięty do UI/API to nie da się go przetestować z tego poziomu, w tym napisać testów funkcjonalnych, mniejsza czy w postaci scenariusza, czy automatu. Można się jedynie starać, by takie testy powstały przed udostępnieniem funkcjonalności użytkownikowi, po przełączeniu feature switch. W dodatku w tej chwili nie za bardzo widzę możliwość automatyzacji takiego działania. Feature switch jest realizowane na poziomie buildu / osobnej usługi a informacja, czy feature (kompletna funkcja biznesowa) został zakończony w dżirze.

Staram się być otwarty na ten pomysł (Trunk Based Development), próbuję do niego jednak podejść krytycznie i przemyśleć jego wady zanim potencjalnie zacznę go wdrażać.

Git Flow to jakiś wynalazek germańskich architektów, którzy widząc zbyt szybki system kontroli wersji postanowili spowolnić go biurokracją.

Bez przesady. To nie oni go wymyślili. Merge Miał też odpowiedzieć na dość konkretne wyzwania. To, że ma też swoje wady jest jasne, jak również to, że nie do końca jest zgodny z aktualnym podejściem do tworzenia kodu, jest dość oczywiste.

0

@ProgScibi: W TBD nie masz współdzielonych ficzer branczy. Jak coś trafia do mainline, to ma to być kod gotowy na produkcję. Nie masz dodatkowego procesu release, czyli zrobienia brancza release, pospolitego ruszenia testerów itd. Na ile rozumiem sens tego podejścia, pożądane jest automatyczne wypychanie zmian na produkcję możliwie często.

5
piotrpo napisał(a):

@ProgScibi: W TBD nie masz współdzielonych ficzer branczy. Jak coś trafia do mainline, to ma to być kod gotowy na produkcję. Nie masz dodatkowego procesu release, czyli zrobienia brancza release, pospolitego ruszenia testerów itd. Na ile rozumiem sens tego podejścia, pożądane jest automatyczne wypychanie zmian na produkcję możliwie często.

No tak, jeśli chcesz mieć dywizje deweloperów, bataliony testerów i pułki release managerów do wielkiej kobyły releasowanej co pół roku, to trunk based development może do tego pasować jak pięść do nosa. Ale nie sprecyzowałeś, że celujesz w coś takiego :)

Jedyny raz, gdy widziałem wdrożony git flow, to właśnie przy wielkiej kobyle, która miała release może raz albo dwa razy do roku, była instalowana on-premise więc klient mógł chcieć sobie podbić do najnowszej wersji ale mógł nie chcieć, w efekcie do starych releasów też leciały fixy i tak dalej. Ale nadal, było to potężnie biurokratyczne - był szpec od robienia merge do developa, code freeze i inne wynalazki, jak się nie wyrobiłeś z ficzerem przed code freeze to był problem - no pełen serwis. Nie wiem, jak trunk based development sprawdził by się przy tak dużym repo. Mając na uwadze naturę on-premise, raczej i tak skończyłoby się na pączkowaniu release branchy do których leciałyby fixy.

ALE, tutaj uwaga - mimo, że były tam długo żyjące feature branche, releasy itd. nie chroniło to przed wrzucaniem na "produkcję" rzeczy niekompletnych lub niewidocznych dla użytkownika - bo znowu pojawiały się tematy w stylu nie zdążymy z tym do releasu 7.4.x, ale możemy zrobić zmianę i jak wypuścimy plugin pod 7.5.x to będzie wciąż kompatybilny z 7.4 (przykład z grubsza zmyślony, ale oddaje sytuacje)

1

@piotrpo: Główna zasada działania Git Flow jest błędna: nie zawsze da się dostarczyć ficzer w jednym branchu. Czasami okazuje się, że do dalszej pracy potrzebny jest commit z innego brancha, wtedy to wszystko się załamuje. Póżniej okazuje się, że programista walczy więcej z mergami niż to warte.

2

Nie masz dodatkowego procesu release, czyli zrobienia brancza release, pospolitego ruszenia testerów itd. Na ile rozumiem sens tego podejścia, pożądane jest automatyczne wypychanie zmian na produkcję możliwie często.

No właśnie nie rozumiesz, o czym już pisałem wcześniej. Oczywiście że przy TBD możesz mieć release branche, przecież to jest nawet pokazane na stronie do której sam link podałeś! Różnica jest taka że cały development odbywa się na głównym branchu. Wtedy release jest brany kiedy faktycznie ma się odbyć release. Taki branch może zostać wtedy przetestowany odpowiednio, przejść przez różne środowiska jeśli trzeba itp. Nie commituje się natomiast do niego nowych feature'ów.

Niepotrzebnie wszystko nadinterpretujesz i komplikujesz. Idea TBD jest właśnie taka by to wszystko uprościć, a Ty to przeinaczasz i próbujesz nadmiernie nad tym filozować.

Poza tym weź pod uwagę że to co się powinno robić lub nie to nie jakieś żelazne zasady, i tak gdzie ma to sens się je łamie.

0

@Aventus:
Według tego co jest na stronce, release branch jest kompletnie nieaktywny. Nie tylko nie robi się na nim nowych ficzerów, ale nie robi się również poprawek błędów. Zgadza się to z twierdzeniem również zawartym na wspomnianej stronce: This ensures the codebase is always releasable on demand and helps to make Continuous Delivery a reality, które sam przytoczyłeś.

Rozumiem również, że sam proces release'u może być bardziej skomplikowany niż "wypchnijmy to na produkcję" i nie jest zdefiniowany przez TBD (np. przejście artefaktów przez środowiska testowe, A/B testing itp. - kompletnie osobny temat).

Może faktycznie nadmiernie komplikuję temat, staram się po prostu zrozumieć problem. Moje aktualne wnioski są takie:

Jeżeli kod w trunku ma być "produkcyjny" i "gotowy do releasu na produkcję w każdym momencie" to musi mieć zapewnioną jakość.
Jeżeli nie mamy ficzer branchy (za wyjątkiem technicznych pod code review) to możliwe momenty zapewnienia tej jakości są podczas pisania kodu (np. XP), code review i testów przeprowadzanych przed wykonaniem merge'a.
Skoro tak, a taki proces ma być przeprowadzany wiele razy w ciągu dnia, to nie ma miejsca na jakiekolwiek testy manualne. Wszystko powinno być pokryte automatami działającymi szybko. Mogę sobie wyobrazić, że część testów jest robiona nightly, ale to już trochę łamie zasadę "always releasable".
Skoro automaty nie są w stanie pokryć wszystkiego (np. testy eksploracyjne), to musi istnieć sposób na łatwy i bezbolesny rollback zmian wykrytych już post factum, czy to na produkcji, czy na środowisku testowym (czyli 2 częściowy release - na środowisko testowe, blue/green, po wykonaniu dodatkowych testów promocja rozwiązania na produkcję. Tutaj wyzwaniem jest zalecana przez podejście CD zdolność do releasu zmian w ciągu < 1h.

1 użytkowników online, w tym zalogowanych: 0, gości: 1, botów: 0