Trunk based development - hit, czy kit?

3

@piotrpo: stronka mówi

Bugs should be reproduced and fixed on the trunk, and then cherry-picked to the release branch.

Zresztą po to mamy release branch, jakby się nie dało nic tam zmieniać, to taki branch byłby bezużyteczny

Jeżeli kod w trunku ma być "produkcyjny" i "gotowy do releasu na produkcję w każdym momencie" to musi mieć zapewnioną jakość.

Wszystko zależy od jakości kodu i procedur testujących. Ten punkt bardziej rozumiem w taki sposób, że do mastera nie jest mergowany kod, który nie ma prawa działać np. częściowy refaktor, jakieś dupa debugi, kod rozgrzebany w połowie. Kod ma być na tyle "dobry", że inny deweloper będzie mógł klepać jakiś inny task bez obawy, że testy nie przechodzą albo kod się nie kompiluje. To w jaki sposób i kiedy wdrażasz się na produkcję nie jest ściśle określone jak w Git Flow: możesz używać wspomnianych już feature branczy, możesz też używać danego commita z mastera

3

Według tego co jest na stronce, release branch jest kompletnie nieaktywny.

No i znów- to jest nieprawda. Na release branch commituje się hotfixy, najczęściej do problemów pojawiających się podczas testowania. https://trunkbaseddevelopment.com/branch-for-release/

Ciekawostka- u mnie w pracy stosujemy odwrotność tego co na tej stronie jest zalecane, i hotfix branch bierzemy z release, następnie cherry-pick na release i dopiero później na master. Łamiemy "zasadę" i jakoś świat się nie zawala od tego...

4

TBD jak i Continuous Delivery działają w oparciu o jeden ciężki warunek - programiści są odpowiedzialni. I w samym procesie CD chodzi o to, że jesteśmy w miarę pewni, że programiści nie lecą w kulki i mamy na tyle testów automatycznych, żeby wiedzieć, że appka raczej odpali i główne funkcje będą działać, a jak coś jest nie tak to jesteśmy w stanie wyłączyć dany feature lub nawet zrobić rollback kilkoma kliknięciami.
W takim procesie TBD wpasowuje się bardzo dobrze. W tym wszystkim powinno wystarczyć dodanie warunku, że merge do mastera da się zrobić tylko jak przejdzie build i unit testy, a z doświadczenia wiem, że nawet to jest dla niektórych ciężkie do ogarnięcia.
U nas robiliśmy tak, że wszystkie feature branche były mergowane do mastera regularnie i od razu automatycznie budowane i wrzucane na środowisko developerskie, więc był serwer, gdzie był uruchomiony zawsze najnowszy kod, potem jak testerzy powiedzieli, że są gotowi na kolejne zmiany, bo np. przetestowali poprzednie featury, to po prostu ostatnia zbudowana paczka, która była na developie była wpuszczana na środowisko testowe, jak tam przeszła testy to już zmierzała na UAT i produkcję. A w tym czasie master i środowisko developerskie cały czas dostawały nowe zmiany.

1
piotrpo napisał(a):

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.

No więc testy się dodaje z ostatnim taskiem w ramach danego feature, tym który wystawia endpoint czy UI.
Albo po prostu można mieć się branch per feature i cały ficzer merdżować na raz - niezależnie czy zajmuje on 4h czy 4dni. Jeśli religia TBD tego zabrania, to znaczy, że to jest zła religia, więc zamiast ją wyznawać trzeba pracować po ludzku.

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.

Może i nie oni wymyślili, ale mogli.
Istnienie wielu długoterminowych gałęzi i cała ta orgia merdżowania między nimi brzmi jak scenariusz niemieckiego filmu nieromantycznego.

0
mar-ek1 napisał(a):

TBD jak i Continuous Delivery działają w oparciu o jeden ciężki warunek - programiści są odpowiedzialni. I w samym procesie CD chodzi o to, że jesteśmy w miarę pewni, że programiści nie lecą w kulki i mamy na tyle testów automatycznych, żeby wiedzieć, że appka raczej odpali i główne funkcje będą działać, a jak coś jest nie tak to jesteśmy w stanie wyłączyć dany feature lub nawet zrobić rollback kilkoma kliknięciami.

Nie do końca, ludzie popełniają błędy. Każdy ma czasami gorszy dzień, śpieszy się z czymś itd. i narzędzia mają ograniczyć wpływ takich pomyłek. Oczywiście jak masz ancymonów, których odpowiedzą na sypiące się testy jest wywalenie tych testów to będzie kiepsko i to chyba nie zależy od przyjętego sposobu branczowania.

W takim procesie TBD wpasowuje się bardzo dobrze. W tym wszystkim powinno wystarczyć dodanie warunku, że merge do mastera da się zrobić tylko jak przejdzie build i unit testy, a z doświadczenia wiem, że nawet to jest dla niektórych ciężkie do ogarnięcia.

Aktualnie mamy przed wykonaniem merge puszczany build z unit testami, quality gate na sonarze + analiza podatności. Do pełnego zestawu brakuje jeszcze testów integracyjnych, ale te trwają jak na razie za długo żeby je uruchamiać inaczej niż nightly. Minus taki, że niektórych komponentach pokrycie testami jednostkowymi jest niskie.

U nas robiliśmy tak, że wszystkie feature branche były mergowane do mastera regularnie i od razu automatycznie budowane i wrzucane na środowisko developerskie, więc był serwer, gdzie był uruchomiony zawsze najnowszy kod, potem jak testerzy powiedzieli, że są gotowi na kolejne zmiany, bo np. przetestowali poprzednie featury, to po prostu ostatnia zbudowana paczka, która była na developie była wpuszczana na środowisko testowe, jak tam przeszła testy to już zmierzała na UAT i produkcję. A w tym czasie master i środowisko developerskie cały czas dostawały nowe zmiany.

Dzięki za ten opis, mamy w tej chwili wszystko ustawione bardzo podobnie. Kwestia automatycznego wyzwalania niektórych akcji.

somekind napisał(a):

No więc testy się dodaje z ostatnim taskiem w ramach danego feature, tym który wystawia endpoint czy UI.
Albo po prostu można mieć się branch per feature i cały ficzer merdżować na raz - niezależnie czy zajmuje on 4h czy 4dni. Jeśli religia TBD tego zabrania, to znaczy, że to jest zła religia, więc zamiast ją wyznawać trzeba pracować po ludzku.

Nie chodzi o wyznawanie TBD, raczej o zrozumienie jakie są haczyki i czy przypadkiem po rozmowie o Jezusie nie poproszą o przepisanie na siebie mieszkania.

0

A jak w TBD wyglądają testy manualne? Załóżmy, że mamy typową webówkę, gdzie dla wielu rzeczy - np. frontu - nie opłaca się pisać automatów - po prostu ktoś musi ocenić wzrokowo czy wszystko jest OK, sprawdzić na kilku urządzenia itp.

Jak w takim przypadku wygląda testowanie? Tester sobie sam stawia środowisko z danego brancha np. używając Jenkinsa i jak wszystko jest OK to zezwala na merg do mastera?

0

@hadwao: Wiedza czysto teoretyczna z mojej strony - testy walidujące merge'a powinny być automatyczne. W przypadku release'u masz osobna gałąź, którą można sobie testować jak się chce i dowolnie długo. Można też wyrywkowo i ciągle testować manualnie aktualny kod w trunku.
Niezależnie od tego czy się opłaca tworzyć automaty, to bez nich pójście w taki proces będzie z jednej strony trudne, z drugiej oderwane od celu jakim w moim rozumieniu jest wprowadzenie pełnego CI/CD i uzyskanie zdolności do wykonania produkcyjnego deploy'a w krótkim czasie. Rozwiązanie/ograniczenie problemu z merge postrzegam jedynie jako cel pośredni.

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