Melyik Git repo struktúra a szimpatikus neked?

 ( Vamp | 2019. március 12., kedd - 15:57 )
Master branchban a stabil kiadás, a többit (test, beta, etc...) olvasztják a masterbe.
62% (153 szavazat)
A master ág mindig a latest commit, ebből lesz alpha, beta, RC, etc... majd külön branch a stable/release.
38% (93 szavazat)
Összes szavazat: 246

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

Valami rendes opcio miert nincs? Pl. gitflow.

+1

A gitflow mar egy "idealis" allapot, en csak a ket leggyakoribb felepites kozul akartam kerdezni.

+1

A gitflow az gyakorlatilag az elso pont egy variansa.

Igy mar ertelek, koszi.

Szerintem az első opcióba belefér a gitflow is...

Ismerem a gitflow-t, de nem szerettem meg.

-----
„Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben.”
rand() a lelke mindennek! :)
Szerinted…

Az első a gitflow...

hat az durva lenne ha gitflow-ban test meg beta nevu brancheket olvasztgatnanak be master-be...

van egy rossz hírem akkor xd
amúgy az, hogy minek nevezed a brancheidet, rajtad áll...

ha szerinted test meg beta tipusu branchek (szandekosan nem nevet irtam hogy ne nezz hulyenek mint az elobb) beolvasztasa a masterbe gitflow, akkor inkabb nekem van szamodra rossz hirem :))))))

Attól függ.
Alapvetően: az origin/master mindig stabil és mindig a latest commit. Hogy a helyi repodoban mit csinálsz magánügy.
Nagy változtatásoknál origin/feature_xxx mindig stabil és mindig a latest commit. Amikor elkészült a feature akkor beolvad a master -be.

+1 ez
Esetleg meg annyi, hogy a feature_xxx eloszor a development/staging branch-be megy be, majd onnan a masterbe.

-------------------------
Roses are red
Violets are blue
Unexpected '}' on line 32

Kivéve ha CI/CD akkor master latest commit mindig megjelenik stagingen.


return signResponse.getSignForUser("zeletrik").map(SignResolvable::getSign).orElse(StringUtils.EMPTY);

+1

Trunk based development ahol csak lehet.

-1

Teleszemeteli a kodot felesleges es az uzleti logika megertesre hatranyos feature-flagekkel.

Nem is beszelve a kotelezo CI-police felallitasarol...

Halott (!hasznalt), felkesz kod tarolasara a VCS valo, nem a production kodbazis.

Mindkettot kerulni kell, amennyire csak lehet.

Vonatkozo cikk:

https://debitoor.com/blog/trunk-based-development-how-we-fixed-it-with-koritsu

Ki mondta, hogy
- kellenek feature flagek
- ha vannak is feature flagek, akkor örökre benne is maradnak?
- halott meg szar kódokat kell commitolni?

Linkelhetnék én is százfélét, bizonygathatnám hogy ez a módszer nekünk kiválóan és évekig mindenféle fákápp nélkül működött nem kevés felhasználóval, de felesleges. Azt, hogy a kollégáidat fegyelmezni kell, mert leszarják ha törik a buildet vagy képtelenek körültekintően dolgozni az szomorú és ilyen esetben valóban ez nem tud működni. De ki mondta, hogy fegyelmezetlen, igénytelen és/vagy nemtörődöm embereket kötelező felvenni?

A kommentedet nem a megértés, nyíltság sokkal inkább az ítélkezés vezette. Úgy látom neked nem jött be és nem is való mindenkinek, de hogy kategórikusan kijelented hogy SZAR - na hát ezt visszautasítom.

Sajnálom.

Itelkezes bizony, mert tapasztaltam minden hatranyat a TBD-nek.

> kellenek feature flagek

Nehezen tudom elkepzelni egy uj feature fejleszteset valami switch mechanizmus nelkul trunk based alapon.

> akkor örökre benne is maradnak?

Mert szeretunk duplan dolgozni... takaritani... tesztelni...

> halott meg szar kódokat kell commitolni?

Hat ha egy kommit - egy feature, akkor igazad van.

Viszont oszinten erdekel a te tapaszalatod is. Elonyokkel, hatranyokkal :)

Ésszel kell csinálni mindent. Illetve a legnagyobb hibák közé tartozik a verziókezelést a szoftver architektúrától függetlenül kezelni. Láttam már sok millió EUR-os fejlesztést bedőlni emiatt (is).

Az egy valós veszély, amit írsz, hogy szemetes lesz a trunk based dev miatt a kód, viszont pont a trunk based dev miatt ki is lehet dobálni a már nem használt kódot gyorsan.

Ha külön branchon nagyon elágaznak a fejlesztések, esetleg jó kis szaftos refaktorálások történnek egymástól függetlenül különböző branchokon, veszélyességi pótlékot kell fizetni annak, aki majd összemergeli a kettőt. Ezt a divergenciát próbálja megakadályozni a trunk based development. Nem véletlen, hogy a Facebook és a Google is ezt nyomja, mert az ő méretükben egyszerűen nem megy másképp. A trükk, amit alább már írtam, hogy nagyon megnehezítik a commitok bejutását a fába. Ahhoz, hogy valami bejusson, code-review-knak, teszteknek mind le kell futniuk hibátlanul.

És itt kapcsolódik hozzá a szoftver architektúra: a (runtime) feature flagek azért is jók, mert pl. tudsz rolling release-t csinálni és ami még fontosabb, ha gáz van, mindenhol kikapcsolni anélkül, hogy a legtöbb user egyáltalán észrevenne egy akármilyen súlyos hibát, ami a leggondosabb tesztelés mellett is előfordulhat. Ezek mellett nyilván szükség van compile time feature flagekre is, hogy feleslegesen ne menjen ki olyan, ami még messze nincs kész, vagy egy adott régióban, ahova a build kerül, nem is tervezik bekapcsolni.

Ui: nyilván nem atomerőmű- vagy repülővezérlés esetleg autó ECU firmware fejlesztésre gondoltam elsősorban a fentieknél.

> Ésszel kell csinálni mindent.

Ezt szoktam en is mondani. Gondolkozzon el az ember, hogy adott szituacioban melyik altala ismert (vagy nem ismert, ld. research) technika/technologia a legmegfelelobb valasztas. Ha a trunk based, akkor az. Ha a feature branches, akkor az. Ha valamilyen teljesen agyament a logikus, akkor az. De biztos, hogy nem "ahol csak lehet". Ahol logikus, igen.

Az a problema az egesszel, hogy kodbol akarnak megoldani annal melyebben fekvo problemakat. Ezeknek a gyokere a nem megfelelo teszteles, a nem megfelelo infrastruktura, illetve a nem megfelelo kod-, es munkaszervezes. Esetleg a bandwagonra pattanas is szerepet jatszhat, "a tobbiek is ezt csinaljak, ez csak jo lehet" effektus.

Ha a kod rendesen van strukturalva, akkor merge conflict nem szabad hogy felmeruljon, mert ket kulonbozo valtoztatas nem erinti ugyanazt a teruletet (ld. SRP vs. spagetti kod).

Ha a csapat rendesen van struktulralva, akkor ha megis ugyanazon a teruleten dolgoznak, akkor ezt elotte megbeszelik, es fejlesztes kozben folyamatosan egyeztetnek (ld. agile, standup, "Individuals and interactions over processes and tools").

Ha az infrastruktura nem tamogatja a folyamatos release-t, a releasenkenti feature-szamot megfeleloen alacsonyan tartva, akkor nincs mas lehetoseg, mint a feature flageles. Ha az infrastruktura tamogatja a gyakori release/rollbacket, akkor semmi ertelme a kodot teleszemetelni, mert elegendo monitorozasi idoablak utan vagy mehet a kovetkezo release, vagy rollback kell. Ez webapplikacio eseten a gyakori release megoldhato, egy mobil app eseten mondjuk kevesbe.

Ha nincs megfelelo automata teszt es regression lefedettseg, akkor megette a fene az egeszet. Ha ezeket manualisan kell elvegezni, akkor nem marad ido a feature rendes manualis/exploratory tesztelesere, gyakorlatilag a happy path lesz lefedve, meg talan egy-ket error eset. Ennek hatasara bugos kod jelenik meg eles kornyezetben, mely vagy tamogatja annak rollbackeleset, vagy nem. Megfelelo tesztelessel a hibak aranya ezaltal a rollbackek szama minimalizalhato.

Kicsit kezd elegem lenni abbol, hogy mindent (is!) a fejleszto oldjon meg. Nyilvan ertsen az uzemelteteshez, legalabb egy picit, mert az uzemeltetok basznak megtanulni, hogy kell a szoftvert rendesen uzemeltetni (flamebait!). Mert nincs ido automata tesztekre/olyan szar a kod, hogy lehetetlenseg ertelmesen tesztelni, tehat a fejleszto azert manual teszterkedjen is, mert nincs kapacitas. Hogy az infrastruktura es a processzek akadalyozzak a folyamatos release/rollback ciklust, igy a mar igy is elegge komplex kodbazisba meg egy retegnyi komplexitas epitese a megoldas termeszetesen, hogy a fejlesztonek meg azt is folyamatosan fejben kelljen tartania, hogy eppen mi van bekapcsolva/masik team miket kapcsolgat (ld. fentebb kommunikacio)/a live issue keresest feleslegesen komplexsze teszi. Nagyon cool, olyan erzes, mint egy Forma 1-es kocsit tav-finomhangolni a garazsbol, de azert na... itt nem errol van szo elsosorban (az a GC futasidobeli tutujgatasa eseten lenne megfelelo analogia).

aham..ahogy a feature branch hivok latjak a trunk based developmentet mikor nem ismerik a megfelelo toolokat hozza :D
a dev vs. sys flamebait-ed meg ari. tok cuki naaaa :D

Mik azok a megfelelo toolok?

Gondoltam rakerdezek, ha mar igy fogoval kell kihuzni beloled...

Amik pl. ezeket https://hup.hu/szavazasok/20190312/melyik_git_repo_struktura_szimpatikus_neked?comments_per_page=9999#comment-2328409 megtamogatjak :D

Oh, God! They are so many of them!!! Arrggghhh!!! :D

bamulatos, hogy tudsz ennyire semmitmondo kommenteket irni

vegyel peldat Hevirol, ahelyett, hogy belekotne a nyelvtani hibaba, inkabb tanulni akart toled

+1, koszi

Tenyleg erdekel, hogy milyen toolsettel lehet trunk based developmentet kenyelmesse es biztonsagossa tenni; aztan meg a vegen meg is gyozodhetek az ervek sulya alatt.

Szerk: na jo, csak hogy beinduljon a szal konstruktiv resze is :)

Trunk based development ellen szoktak felhozni (koztuk en is), hogy nehezze / lehetetlenne teszi a code review-t. Ugye ha nincs branch/fork akkor nincs merge/pull request, nincs code diff, stb, stb.

Erre a megoldas a TBD fele hajlok szerint a pair programming/mobbing, ami teljesen jogos is, es mukodik. Egyszerre ket ember dolgozik ugyanazon a gepen ugyanazon a kodon, periodikusan cserelgetve, hogy ki gepel es ki vezet, minketten kontextusban vannak, stb, stb. En ezt el is fogadom, hogy ilyen helyeken a TBD mukodhet, es jol mukodhet. A problemam ket dologgal van:

- azert egy feature elesitese elott jo atnezni meg egyszer a modositasokat, megvan-e minden, tesztek megvannak-e, config is frissitve lett-e stb. Illetve a pair programming ugyan baromi jo, de azert igy se art, ha egy harmadik fel is vegig megy a kodon. Kevesebb dolga lesz, de azert neha akad.

- nem mindenki szeret pairelni / mobolni. En azt vettem eszre magamon, hogy ha pair-elni kell, akkor altalaban hagyom a business logic kitalalasat a paromra, es inkabb csak kijavitgatom / segitek neki. Ez abbol fakad, hogy ha nem tudok a sajat tempomban, a sajat logikam alapjan, a sajat megszakitasaimmal gondolkozni egy adott dolgon, akkor az nyilvan nehezebb; es ha van ott valaki mas, aki szinten gondolkodik, akkor minek duplikaljunk effortot :) Oke, nem ennyire veszes a helyzet, de pairing eseten vagy fel kell keszulni elore (es akkor meg mar egyedul is megoldhattam volna), vagy pedig potencialisan diszkomfortot okoz.

Persze nem muszaj folyamatosan pair-elni, lehet napi 2-3 orat is, esetleg ad-hoc ("gyere, segitsel mar legyszi...!"), na de akkor meg ott van a context switch.

Nyilvan, a pairingnek szamos elonye van, knowledge sharing / manyeyeballs / folyamatosan jelenlevo gumikacsa, de eszre kell venni a hatranyokat is. Ha a csapattagok szeretnek egyedul (is) dolgozni, akkor a pair programming nem tudja helyettesiteni a code review-t, szoval mindenkepp kell egy ideiglenes tarolo a felkesz kodnak, ha a nap vegen mindenki commitolni akar.

A gond ott kezdődik, hogy mit értesz trunk based dev alatt. Mert én (ahogy írtam is) azt, hogy a commit csak code review + CI (automata tesztek) után kerül be a trunkra (masterra). Az, hogy ez a code review milyen formában történik (pull request, vagy gerrit / phabricator changeset) a módszer szempontjából irreleváns.

Addig, amig a CR + CI megtortenik, hol lakik a kod? Delutan 5 es reggel 8, pentek es hetfo kozt?

TBD alatt azt ertem, hogy folyamatos, napi tobbszori committal/push-sal, csak a masteren/trunkon/mainlineon tortenik a fejlesztes, jellemzoen valamilyen feature switch mechanizmus moge rejtve a meg keszulo logikat.

A code review rendszerben lakik. Ez lehet, hogy valamilyen formában integrálva van a Git repóval (GitHub / Gitlab - Pull / Merge Request, végülis a Gerrit is ilyen), vagy attól külön. A lényeg, hogy a masterre csak reviewzott, ellenőrzött módosítások kerülnek. Ettől még feature flagekre szükség lehet, mert egy reviewzott módosítás nem egy teljes feature hanem annak egy egyben tesztelhető minimális része.

És pontosan ebben különbözik a feature branch megoldástól, ahol egy teljes feature hetekig - hónapokig párhuzamos branchon van fejlesztve és a végén (súlyos áldozatok árán) mergelve.

Az ellenőrzés nélkül trunkra kommitolás legalább 5 éve kiment a divatból, és én is letagadom, hogy valaha ilyet csináltam volna... :) Tehát szerintem nem ezt jelenti a "Trunk Based Development" 2019-ben.

Ez miben kulonbozik a branchelt megoldastol, amikor a master minden reggel be van mergelve a feature branchbe (minimalizalva a merge conflictokat a vegen)? A frissitetlen branchen fejlesztes legalabb 5 eve kiment a divatbol ;)

Hiszen merge conflictot trunk based development eseten is kezelni kell; a commit es a code review kozti ido alatt a branch elmaszhat az eredeti allapotatol. Ismerem, Perforce-szal egy evig toltunk TBD-t, de nem igazan gyozott meg. Viszont a P4 merge toolja az valami zsenialis.

Mondjuk azon a projecten a trunk based development a VCS sajatossagai miatt lett bevezetve (szornyu vele branchelni), es ugyan mukodgetett, de nem volt egy leanyalom.

Ehhez kepest, ha a CI rendszer rendesen van felepitve, akkor a branch push-olasakor az automatikusan bemergeli a mastert, ha merge conflict van akkor fail-fast, ha meg megy az automatikus merge, akkor lefuttatja rajuk a teszteket.

Ezt hivjak automatizalasnak, mikor levetetjuk a problemat a geppel az ember vallarol.

Mert TBD eseten mi tortenik (javits ki ha tevednek)? A sajat, felkesz, halott kodod karbantartasat sajat magadrol/a csapatodrol atharitod az osszes fejlesztore, aki az adott kodreszleten dolgozik, hiszen ha mar be van mergelve, akkor az mar ugye shippelve van, szoval az onnantol kozos kod. Nyilvan, Masvalaki Problemajava tenni a karbantartast baromi jo otletnek tunik, viszont a masik oldalon ez baromira felesleges energia befektetes. Ha feature switch mogott van a kod, akkor az osszes tobbi fejlesztonek kell kitalalnia, hogy az o logikajat hogy integralja bele a te felig kesz kododba, ugy, hogy ertsd is, hogy mi a fene van. Meg majd o refaktoralgassa a te felkesz kododat... A fentebbi feature branches megoldasnal a felkesz kod karbantartasa a csapatban marad. Majd kepzeled, hogy mas szarat fogom lapatolni, mi? :)

Nem. Senki nem varhatja el a tobbi csapattol, hogy helyettuk vegezzek a munkat. Foleg azert, mert ez alapvetoen infrastrukturalis probema. Ha meg lehet oldani infrastrukturaval, akkor azzal kell, mert a kod mar onmagaban is komplex, nem kell bele meg tobb. Minel kisebb a (production) kodbazis, annal jobb. Annal egyszerubb debugolni, fejleszteni, atlatni es megerteni. Halott kodnak semmi keresnivaloja a production kodbazisban.

"A tökéletesség nem az, amihez nincs mit hozzátenni, hanem amiből nincs mit elvenni."
Antoine de Saint-Exupéry

Szerk: fentebb javitottam a CVS-t VCS-re (Version Control System), amire eredetileg gondoltam. Pedig at szoktam olvasni a hosszabb kommenteket bekuldes elott :)

Én a másodikat jelöltem meg, de implicit úgy értelmeztem, hogy az a "latest commit" már a code review rendszerből ellenőrzés után került be. Hogy ez a code review rendszer az egy github / gitlab jellegű megoldás vagy gerrit, phabricator ... etc., ebből a szempontból irreleváns.

Igen igy van, a latest commit merge elott review-olva van, de attol fuggetlenul konkret tesztelesre (felhasznaloi, tehat beta ag pl) nem kerult bele.

Szerintem ez hely és processz függő lehet. Pár éve volt szó valamelyik F8 konferencián a Facebook rendszeréről, ott elég durva integrációs tesztek is futottak még commit előtt, arra nem emlékszem, hogy a manuális tesztek már a release branchon mentek-e. Én egyébként külön beta ágat nem tartok, hanem van egy pont, amikor masterből release branchot csinálunk, ahol onnantól code freeze van, és csak release critical bugok kerülnek javításra, amiket visszamergelünk a masterbe is.

megint egy rossz szavazas, olyan nincs, hogy kit erdekel hogy a leenugz huszarok hogy hasznaljak a gitecskejuket? ;))

Az IBM-nél még mindig kötelező ClearCase-t használni, természetesen UCM + MultiSite + ClearQuest, hogy igazán fájjon? :D

mar reg github van :)

Nálatok ez hogy megy?

Amúgy szerintem leginkább méretfüggő, hogy ki hogyan dolgozik. Én pl egyedül fejlesztek és bocsátok ki kódot az élesbe, innentől kezdve vannak a commitek (főleg fixek) amik mehetnek a masterbe és vannak olyan elhúzódó feature-ők amelyekre kell egy új branch. A gyorsan elkészülő feature-őkre nem szoktam új branchet létrehozni mennek azok is a masterbe (nem a legjobb gyakorlat).
Volt olyan, hogy ez utóbbit megszívtam. Belekezdtem egy egyszerű ficsőrbe ami mégsem lett egyszerű, közben jött egy bugjelentés, amit így nem tudtam gyorsan kijavítani illetve a javított kódnak várnia kellett, mire kibocsátás éretté válik újra a master. Nálam az ilyen "hiba" belefér, mert nem katasztrofális, csak kellemetlen.

nincs global policy, kulonbozo csoportok kulonbozokeppen kezelik ezt.

szamomra a legszimpatikusabb az, ahogy az openstack is csinalja (meg sokan masok is): a master mindig master, es branchben vannak a kulonbozo stable releasek, tehat 2.

+1

Nekem is az a szimpibb. Követhetőbb, kevesebb kommunikáció kell. Talán kevesebb kód megy a kukába is.

Ez mi ez?

gitflow vs TBD szavazás