Udv!
Adott egy darab git repo, amin nehany fejleszto dolgozik. Van nehany development es nehany production szerver, de az egyszeruseg kedveert minden szerverbol legyen egy darab.
Egy olyan konstrukciot keresek, amivel megoldhato az, hogy ha egy hiba javitasanal / feature- nel, ha Geza fejleszto letrehoz egy G branchet, erre nyom egy git push- t, mikozben Jozsi fejleszto letrehoz egy J branchet, melyet szinten git push- sal terminal, akkor mindket branch egyszerre tesztelheto legyen a development szerveren (mintha egy G + J merge lenne checkoutolva), de a production serveren csak azok a branchek legyenek meg, amik jova lettek hagyva (nyilvan itt csak azok lesznek master- be beolvasztva).
Elmeleti konkstrukcio, workflow, program, minden erdekel.
Koszi a valaszokat!
Hozzászólások
Ez igy eleg cumi, szukseg lesz meg egy merge/rebase-re minden feature branch eseten. Teszt elott brancsoltok master (vagy development-bol) es abba Geza es Jozsi belemergeli a szarjat.
De ez igy nagyon cumi, ha gaz van, nem lesz evidens, hogy melyik brancsrol jott a bug, vagy hogy nem-e merge soran keletkezett. Geza meg Jozsi kozul amelyik utoljara mergel (vagy rebase-el) a teszt brancsba, megint kulon tesztelnie kene, fejleszto nem ad ki kezebol olyan modositasokat, amiket nem tesztelt a cel branch-be mergelve...
Szerk: nem tiszta, mit akartok, a ket uj feature-t egyszerre tesztelni? Erre szerintem szar megoldas. Vagy release elott egy vegleges tesztet nyomni?
----------------------
"ONE OF THESE DAYS I'M GOING TO CUT YOU INTO LITTLE PIECES!!!$E$%#$#%^*^"
--> YouTube csatornám
+1
Mi gitlabot használunk.
Bizonyos projektek esetében pont az van amit mondtál.
Ba van lőve, hogy egy branch elnevezésre ugrik a CI és kilöki az adott teszt szerverre egy vhost alá.
Pl teszt-branch-jozsi esetében vagyis csak akkor ha egy teszt\-branch\-[.]+ az elnevezés.
A mappa neve szintén a branch neve. A vhost-é szintén, pl teszt-branch-jozsi.blabla.hu
gitlab alatt ez könnyen megoldható, valszeg github-nál is.
Sima mezei csupasz git-nél meg kell tolni 1-2 hook-al a dolgot. (nem tudom merre, kézzel eddig csak svn-nél meg cvs-nél hookoltam)
Nálunk a teszt és a master is védve van (protected). Csak merge request-el lehet beletolni a fejlesztéseket, push-al nem.
A master kiélesítéséhez mindig emberi "erő" kell. Egy gombnyomás vagy egy parancs.
Nem olyan bonyolult sztori, de egyszer jól össze kell rakni.
Igen, csakhogy o tobb kulon brancsrol szeretne egyszerre kitolni egy buildet.
----------------------
"ONE OF THESE DAYS I'M GOING TO CUT YOU INTO LITTLE PIECES!!!$E$%#$#%^*^"
--> YouTube csatornám
Én úgy értelmeztem, hogy ezeket a brancheket csak tesztelni akarja, aztán ha mindne oké, akkor elfogadják, azaz belemergelik a masterba. Mi egyébként minden nagyobb feladatra külön branchet hozunk létre. Ezek a külön useres branchek ugyanolyanok mint a test vagy a master. Az ember belemergeli a cuccait és tesztelhető anélkül, hogy telbebaxta volna a testet vagy a mastert.
Ha már nagyon teleszemetelte a branch-jét, akkor max létrehozhatja újra a master-ből tiszta lappal.
Csinál egy branchet amibe bemergeli a feature brancheket. Nincs ebben semmi extra. A featureuket meg a prod ba is mergeli, amikor akarja. A minden egybe test branchet meg deployolja.
Ja, csak az A+B mergelt feature branchen minden oké, de külön-külön kell A-ra meg B-re igent mondani, akkor a jóskönyvek szerint nem jársz jól.
Ha A-ra külön kell igent mondani, akkor A-t külön kell tesztelni minden mástól.
+1
Jah. De a valóságban a featureök fejlesztésének a nagy része lehet eléggé független területen kódilag, hogy ne okozzon gondot a merge sorrend, vagy conflict.
Jobb nem erre hagyatkozni, foleg ha ilyen 40-es nagysagrendu uj ficsort omlesztene egy branch-be. Ha a tesztelok talalnak valami gebaszt, akkor az valahogy egyik fejlesztonek sem lesz ismeros, es senki nem fog foglalkozni vele egeszen addig, amig a projektmenedzsernek felfo az agyvize es kijelol egy embert, aki azt teljesen uj bugkent kezelve elbasz egy csomo idot.
Elso fazisban jobb kulon-kulon tesztelni a modositasokat, majd jovahagyas utan, es release elott mehet a teszteles az osszes tobbi modositassal master brancsrol.
----------------------
"ONE OF THESE DAYS I'M GOING TO CUT YOU INTO LITTLE PIECES!!!$E$%#$#%^*^"
--> YouTube csatornám
Nalunk minden branch atmegy automatikus tesztelesen, including integracios tesztek, UI tesztek, esatobbi. A lenyeg, hogy egy fizikai szerveren fel tudunk loni tobb teljes rendszert is, teljesen automatikusan, adatbazissal, esatobbi.
Tehat ha G+J-t akarod tesztelni, akkor csinalsz egy teszt branchet amibe G+J is mergelve van, es kesz. Nem igazan ertem egyebkent, hogy mi ebben a bonyolult.
----------------------
while (!sleep) sheep++;
Az leginkább sajnos, hogy példától eltérően változó számú G és J branch létezik, általában 15- 20, de van, hogy 40... .
Különböző brancheket "gyárilag" nem fogsz tudni együtt kitenni, maximum valami csúnya CI-s hackel, ami temporálisan összemergeli őket, de ezt kár tesztelni, mert a következő pillanatban már más lesz a kód - magyarul teszteltetek valamit ami 5 percig se élt.
Én a helyedben megkövetelném hogy amit tesztelni akarnak azt rebaseljék/mergeljék masterre. Ami azon van, az tesztelhető, ami meg nem, az nem. Ez megkövetel némi csoportmunkát a jómunkásfejlesztőktől, magyarul kicsit össze kell dolgozniuk hogy a különféle branchek simán bemenjenek masterre, és el kell dönteni kinek a munkája mehet be előbb.
--
arch,debian,retropie,osmc,android,windows
Ennek sok értelme így nincs.
Miért tesztelnéd őket egyszerre, ha egymástól függetlenül hagyod jóvá őket?
Szerintem a build szerveren egyedi triggert kell írnod - bármely branch változására induljon a build, és egyedi kód-kicsekkoló szkriptet - branch1 kicsekkol, branch2, branch3, stb rámerge-öl. De ez talán nem egy nagy was.
A probléma az lesz, amit már mások is írtak, nevezetesen hogy a két branch vagy automatikusan merge-ölhető, vagy nem. Ha vannak ütköző változtatások egyazon fájlon, akkor nem (azt hiszem a git paraméterezhető, hogy milyen merge stratégiát használjon, azon is múlhat). Ha nem, akkor kézzel kell merge-elni, mese nincs.
Nyilván a helyzet szüli, hogy hányszor lesz ütközés, ha egymástól független részeit piszkálják a kódnak, akkor menni fog az automerge. Ha meg ugyanazt, akkor nem.
Én azt csinálnám, hogy best-effort jelleggel menne automerge-gel, ha pedig az nem megy, akkor arról kapnak a fejlesztők vagy az integrációs manager értesítést, és eldönthetik, hogy merge-ölnek-e kézzel, vagy úgy döntenek, hogy nem érdekes.
Development szervernek el kell kuldeni valamilyen modon az utolso commit hash-t (githubon webhook, de nyilvan hasonlo midenhol van, vagy git post push hook), a szerver csinal egy uj konyvtarat mondjuk a hash alapjan (akarmi._HASH_), clone (vagy copy a master konyvtarat), checkout, megcsinalja amit kell, es remelhetoleg egyik teszt sem modositja a kozos adatbazist :) Commit message-eket is el tudod kuldeni, ez arra jo hogy pl. ha beirod hogy "[skip ci] 2000 lines of new code. No new tests." akkor nem tesztel.
Fejlettebb valtozat amikor minden buildre felhuzol egy kulon virtualis gepet db-vel, igy nem kavarhatnak be egymasnak a parhuzamosan futo tesztek, mi ezt csinaljuk, de igy mukodik pl a travis-ci is.
Nalunk csak a master van production-on, es csak azt a pull requestet lehet bemergelni aminel lefutott minden teszt, ha megvan a merge akkor erre triggerelodik a deploy.
Edit. Mi ezeket hasznaljuk: github, shippable, deploybot. Push es pull request-re github triggereli shippable-t, lefutnak a buildek, github kiirja hogy folyamatban van a build, ha kesz akkor zold pipa, ha nem akkor piros kereszt, rakattintasz es meg tudod nezni mi tortent a build alatt. Vissza lehet nezni regebbi build logokat is, lehet rebuildet nyomni, egyszerre tobb kornyezetben is lefuthat ugyanaz a build, pl php5, php7.
Amikor master-be van merge akkor a deploybot intezi a deployt. Pusholni nem lehet (lehet, csak nem szabad) masterbe, csak pull requestet mergelni.
Deploybottal egy gombnyomasra lehet rollbackelni, lehet branchet valtani, tud tobb szerverre deployolni, tudsz felhuzni vele mas environmentet is, pl beta, stage, meg tudod mondani melyik branch legyen melyik stage-en.
Jenkins+Gerrit
vagy
Jenkins+git hooks
vagy
Jenkins+sajat plugin
vagy
barmilyen Jenkins fele megoldas + barmifele megoldas
a lehetosegek tarhaza vegtelen :D
Egyfelől +1, képes rá, másfelől viszont a use case nekem nem eviláginak tűnik.
Ha jol ertelmezem a problemat, akkor ez igazabol tipikus use-case nagyceges kornyezetben. Branch-testing, lenyege, hogy verifikalod, hogy a feature/bugfix mukodik. Ezutan merge developra, abbol release branch, ami meg atmegy regressionon, meg meg egy feature testingen (stage-testing).
Ja, hogy ontopic is legyek, a Bamboo pont erre valo.
Nem, a probléma nem ez. A probléma az, hogy ő egyszerre KÉT branchet akar tesztelni egy tesztkörnyezeten, de külön-külön kell rámondani az igent, hogy X branch működik, Y meg nem. Ez így nem oké.
+1
Akkor felreertettem :)
Az alapkérdés még mindig az, hogy két branchet _egyszerre_ akar tesztelni, ami eleve szerintem egy hülye ötlet, bármilyen hacket találunk is ki rá.
--
arch,debian,retropie,osmc,android,windows
Ez így van, hülye ötlet nagyon. Totál értelmetlen két branchet egyszerre tesztelni, ha külön-külön kell rájuk rámondani az áment.
Nekem egyszer azt mondta valaki, hogy amikor mar a harmadik ember mondja, hogy hulye vagy, akkor erdemes feltenni a kerdest magadnak. Ennek okan ideirom harmadiknak. Hulye otlet :)
-
Kiterjesztések írása Go nyelvi környezetben
Szerintem nem hülye ötlet, egy test branchben lehet manuál tesztelni, egyszerre több dolgot. Hátrányai ismertek. Előnye, hogy egy teszt deploy van, és egy helyen lehet tesztelni, ennyi. Kicsiben jó ez.
Szerintem remek ötlet, mert így a fejlesztők hamar értesülnek róla, hogy bár a két branch önmagában rendben van, de a kettő együtt már nem.
Az egy masik dolog, amirol beszelsz. Az ki fog derulni, amikor kozos brancher kerulnek, amit majd szinten kell tesztelni. A kulcs dolog itt, hogy kulon kell oket kezelni, de egyutt is. Ez paradoxon :D
-
Kiterjesztések írása Go nyelvi környezetben
Nem így tesztelünk szoftvert. Egy branchet tesztelünk, ami ha sikeres, mergeljük masterre. Ha nem sikeres, tovább patcheljük, és addig tesztelünk újra, amíg sikeres nem lesz. Ha ez megvan, mergeljük / rebaseljük / whatever, és onnantól az az új master.
A következő branch ezután jöhet csak, amit természetesen az időközben frissült master tetejére kell tenni.
Annak semmi értelme hogy két short lived branchet egyszerre teszteljünk, mert abban a pillanatban hogy bármelyiket masterre mergeltünk, a tesztelt változat eltűnik, tehát felesleges volt tesztelni.
--
arch,debian,retropie,osmc,android,windows
"Nem így tesztelünk szoftvert."
Szoftvert tesztelni és brancheket kezelni nem csak egyféleképpen lehet.
"Egy branchet tesztelünk, ami ha sikeres, mergeljük masterre."
A teszt sikeressége nem feltétlenül elégséges feltétel. Van még code review meg egyebek, amik szintén szükségesek lehetnek, és eltarthatnak egy ideig ezért...
"A következő branch ezután jöhet csak"
... ennek semmi értelme nincsen.
"amit természetesen az időközben frissült master tetejére kell tenni."
Természetesen nem "kell" a frissült master tetejére tenni. Lehet úgy is, de nem csak úgy lehet.
"Annak semmi értelme hogy két short lived branchet egyszerre teszteljünk, mert abban a pillanatban hogy bármelyiket masterre mergeltünk, a tesztelt változat eltűnik, tehát felesleges volt tesztelni."
Ez marhaság, a merge-elt branch változtatásai azután ott lesznek a master branchben.
"A teszt sikeressége nem feltétlenül elégséges feltétel. Van még code review meg egyebek, amik szintén szükségesek lehetnek, és eltarthatnak egy ideig ezért..."
Hat mondjuk pont a code review az egyik olyan dolog, amit teszteles elott van ertelme megejteni, mert gyakran vezet kod modositashoz.
----------------------
"ONE OF THESE DAYS I'M GOING TO CUT YOU INTO LITTLE PIECES!!!$E$%#$#%^*^"
--> YouTube csatornám
Szerintem pont fordítva: amíg a tesztek nem sikeresek, addig nincs értelme a review-nak, mert egyrészt nyilvánvalóan hibás kódot kell átnézni, másrészt a javítások után újra át kell nézni.
Te milyen tesztekrol beszelsz? Automata tesztek? MAnualis, amit a fejleszto vegez? Manualis, sokkal alaposabb, amit a QA vegez? Az utobbi a legidoigenyesebb, ciki lenne megismetelni egy refaktoralas miatt, pedig szukseges lenne. Review ezzel szemben sokkal kevesebb idot vesz igenybe es sok bugra mar ott feny derul. Automata tesztek meg nyilvan lefutnak review elott.
----------------------
"ONE OF THESE DAYS I'M GOING TO CUT YOU INTO LITTLE PIECES!!!$E$%#$#%^*^"
--> YouTube csatornám
Az egész téma automatizált tesztekről szól.
Melyik tema? Irt a temaindito ilyent?
----------------------
"ONE OF THESE DAYS I'M GOING TO CUT YOU INTO LITTLE PIECES!!!$E$%#$#%^*^"
--> YouTube csatornám
Feltételeztem, hogy automatizált tesztekről van szó, mert manuálisan mindenki azt csinál, amit csak akar, beleértve két branch merge-elését is.
A mondanivalóm lényege az, hogy aki két feature branchet valahogy összeborogat csak azért hogy egy runban tudjanak a tesztelők kattogtatni (nevezzük most ezt tesznek), az egyáltalán nem érti a szoftvertechnológiát, és vissza kéne ültetni az iskolapadba.
--
arch,debian,retropie,osmc,android,windows
+1 persze lehet egyeb modszerekkel probalkozni, csak a fentihez hasonlo kerdeseket szul :D
Szerintem ez rossz branching strategia es kultura, de megvalosithato:
Jenkins + Multibranch pipeline (Github vagy Gitlab mogotte)
A PR-ekre torteno buildet be tudod allitani ugy, hogy a PR merge vegeredmenyet teszteli le elore.
Amikor szeretnetek ra CI buildet, akkor Geza vagy Jozsi nyit egy PR-t a masik branch-ere es indul is ra CI.
Mi Bamboo-t használunk és gitflow branchelést.
Nagyon jó nektek, de ennek semmi köze a problémafelvetéshez.