Přesunuto: z diskuse o změně Git workflow
- Tharos
- Člen | 1030
Přesunuto z diskuse https://forum.nette.org/…e-frameworku, DG
Já bych se za lepší release management rád přimluvil. Spolu s ním se nabízí i vylepšení workflow, třeba v duchu tohoto profláklého článku.
Vyvíjet téměř vše v masteru mi přijde hrozně neohrabané. Třeba jen opravy chyb: kdybych nyní nalezl nějakou chybu v Nette 2.1 a zítra David pushnul opravu do masteru, musel bych pak čekat pravděpodobně až několik měsíců, než se oprava dostane do stable vydání. Zítra by přechod na dev-master asi nebyl problematický, ale třeba za měsíc by už kvůli novým featurám a BC breakům být mohl (nehledě na to, že bych přešel na docela neodzkoušenou verzi, ve které by mohly být zase další bugy :–P).
Editoval Tharos (9. 1. 2014 9:42)
- David Grudl
- Nette Core | 8118
hrach & Honza: můžu to teda chápat tak, že si release management berete na starost?
Tharos: ale on ten vývoj tak v podstatě funguje, prakticky v každém okamžiku je master „production ready“ a features branches jsou pull requesty.
- enumag
- Člen | 2118
Už tu bylo několik výskytů kdy master production ready rozhodně nebyl (teď je v masteru nový Ndb bug a není to tak dávno co přestaly fungovat formuláře).
EDIT: A hlavně když potřebuju jen opravit chybu ve stable na běžícím projektu, není možné kvůli opravě chyby přecházet na master když ve stable větvi bude až za měsíc. Tzn. musím ten měsíc používat vlastní fork, měnit composer.json…
Mnohem lepší by bylo dělat PR s bugfixy vůči stable a později mergovat stable do masteru.
Editoval enumag (8. 1. 2014 13:48)
- Filip Procházka
- Moderator | 4668
@Tharos Nette používá github workflow, tedy master je vždy stabilní, větve se nemergují pokud by rozbily master.
@enumag jenom ten problém posuneš o abstrakci dál, tedy do větve stable ve které bude bug místo masteru a celý se to jenom komplikuje. Prostě master musí běžet a když se najde bug tak se opraví asap.
Konkrétní implementace release managementu by bylo fajn řešit na posobotě, nebo alespoň v samostatném tématu.
- Šaman
- Člen | 2634
A právě o podobných tématech bych se rád něco dozvěděl na
PoSobotě. Nějakou základní teorii o verzování a deployi mám, ale
určitě s tím bude mít někdo i praktickou zkušenost.
Plus takové věci jak má vypadat správný pull request, nebo do jaké míry
testovat, aby nějaká fičura měla šanci na schválení do Nette.
- Tharos
- Člen | 1030
@David Grudl: V podstatě bych právě neřekl, protože je tam jeden fundamentální rozdíl. Rád bych ho popsal na úplně realistickém případu užití:
• Používám Nette stable a narazím v něm na nějaký bug.
• Zjistím, že bug už je opraven v masteru, ale v masteru je zároveň několik zásadních BC breaků, které aktuálně prostě nechci řešit (může to být refaktorované NDB, předělané DI…).
⇒ Opruz. Nejsem schopen se s bugem jednoduše vypořádat. Musím
cherry pickovat, opravit si to ručně (a vyhodit Nette z Composeru), anebo
přejít na dev-master s řadou negativních dopadů: kromě
nutnostli vypořádat se se všemi BC breaky se musím také smířit s tím,
že od té doby se kdykoliv po zavolání composer update může celá
aplikace rozsypat. To mě děsí.
Kdyby Nette používalo analogii k výše odkázanému branching modelu (jen s více stable větvemi), vrchol vybrané stable větve (například 2.1.x) by nesl nějaký tag (například 2.1.0). Jakmile by někdo nareportoval chybu, odvodila by se z relevantní větve větev hotfix-XYZ, v ní by se chyba opravila a pak by se ta větev mergnula do 2.1.x a podle potřeby i do dalších větví (určitě do vývojové větve a také do všech chybou dotčených stable větví). Následně se ta hotfix větev odstranila a merge commity ve stable větvích by se rovnou mohly otagovat (takže by vznikl například tag 2.1.1) atp.
Dokonale to řeší výše uvedený problém. a já v tom nevidím absolutně žádné nevýhody.
Editoval Tharos (9. 1. 2014 9:45)
- Tharos
- Člen | 1030
Filip Procházka napsal(a):
master je vždy stabilní
No to právě není ani náhodou :).
Stabilní (rozuměj bez významných známých bugů) zdaleka není vždy.
Doplnění: Jak může být master stabilní, když se do něj normálně commituje (tj. nejen merguje)… To by musel být daný vývojář neomylný…
Do masteru by se IMHO mělo jen mergovat. Až na nějaké naprosté výjimky… (Nebo se může pro docílení lineární historie na otestované feature větve přeskládávat… Ale asi je jasné, co tím celým chci říct.)
Editoval Tharos (8. 1. 2014 14:00)
- Jan Tvrdík
- Nette guru | 2595
IMHO by stačilo, kdyby se pull requesty s opravami stavěly nikoliv na
masteru, ale na nejnižší relevantní release větvi (aktuálně
v2.1).
To, co @Tharos navrhuje, nebude pro Nette fungovat.
- David Grudl
- Nette Core | 8118
Master vnímej jako větev 2.2.0-dev (nebo 3.0.0-dev, to je fuk). Pokud narazíš na bug v 2.1.0, je nesmysl přecházet na úplně jinou dev verzi, ale použij prostě v2.1-dev verzi. Pokud tam není oprava cherry-picknutá, tak je věcí pár kliknutí to udělat.
- llook
- Člen | 407
Vývojová větev není určená pro produkční prostředí, od toho jsou stabilní větve. Krom toho, že není úplně vždy stabilní, tak na ní také můžou vznikat BC breaky.
Že teď už @dev nepoužívají pouze odvážní early adopteři, je způsobeno pomalým uvolňováním stabilních verzí. Pokud se podaří nastartovat pravidelné a hlavně časté releasování, tak se uživatelé můžou vrátit na stable a občasná nestabilita masteru pro ně nebude problém.
- enumag
- Člen | 2118
Jan Tvrdík napsal(a):
IMHO by stačilo, kdyby se pull requesty s opravami stavěly nikoliv na masteru, ale na nejnižší relevantní release větvi (aktuálně
v2.1).
Přesně to jsem navrhnul o kousek výše.
@fprochazka: Nerozumím proč by to co s Honzou navrhujeme podle tebe nemohlo fungovat. Jak bys to řešil lépe? Mám pocit, že jsi mne špatně pochopil.
Editoval enumag (8. 1. 2014 15:08)
- hrach
- Člen | 1834
Vývojová větev není určená pro produkční prostředí, od toho jsou stabilní větve. Krom toho, že není úplně vždy stabilní, tak na ní také můžou vznikat BC breaky.
Že teď už @dev nepoužívají pouze odvážní early adopteři, je způsobeno pomalým uvolňováním stabilních verzí. Pokud se podaří nastartovat pravidelné a hlavně časté releasování, tak se uživatelé můžou vrátit na stable a občasná nestabilita masteru pro ně nebude problém.
Podepisuju.
Osobně nechápu master jako vždy stabilní. Je to prostě místo, kde se vyvíjí.
Release managment: už jsem min. 2 navrhoval, abyste se s Honzou Tvrdíkem domluvili. Co jsem pochopil, tak by o to min. zájem měl. Určitě jsem schopen dělat release managment Nette\Database, protože vím o tom kódu hodně. Pro ostatní věci se mi bude dělat hůře, ale jsem ochoten se do toho pustit.
- xificurk
- Člen | 121
Tharos napsal(a):
Kdyby Nette používalo například výše odkázaný branching model, vrchol master větve by nesl například tag 2.1.0. Jakmile by někdo nareportoval onu chybu, odvodila by se z masteru větev hotfix-XYZ, v ní by se chyba opravila a pak by se ta větev mergnula do masteru a i do develop větve. Následně se ta hotfix větev odstranila a merge commit v masteru by se rovnou mohl otagovat jako 2.1.1. Dokonale to řeší výše uvedený problém. a já v tom nevidím absolutně žádné nevýhody.
Pokud zaměním v tomto textu master → v2.1 a develop → master, tak vznikne momentálně používané workflow, ne?
- Tharos
- Člen | 1030
Jan Tvrdík napsal(a):
To, co @Tharos navrhuje, nebude pro Nette fungovat.
Nechci to vyvracet, je to možné.
V podstatě jsem chtěl jenom popsat reálný problém, který jsem s Nette už několikrát zažil a o kterém si myslím, že by jej šlo vyřešit vylepšením release managementu.
Spíš jen pro inspiraci jsem odkázal na model, který popsaný problém elegantně řeší.
xificurk napsal(a):
Pokud zaměním v tomto textu master → v2.1 a develop → master, tak vznikne momentálně používané workflow, ne?
Ani ne, protože to mnou odkázané workflow není jenom o tom, že existuje
nějaký master a develop, ale také o tom, že se
například bugfixy řeší v samostatných větvích, které se pak mergují
do stabilní i vývojové větve.
Toho jsem si v Nette jaksi nevšiml, v něm když se opraví nějaká chyba, tak prásk: commitne se do vývojové větve, kde je od posledního stable release jako bonus řada BC breaků a v horším případě i nějaké nové chyby…
Prostě viz problém, který jsem popsal.
- Jan Tvrdík
- Nette guru | 2595
@Tharos: Jsem měl za to, že už jsem ti kdysi vysvětlil, že opravování chyb v setinkových verzí funguje poměrně dobře (za což vděčíme Davidovi), kromě NDB, kterou nikdo opravit neumí. Nebo máš problém i s něčím jiným, než NDB?
- jasir
- Člen | 746
Musím se trochu přiznat, že moc nechápu, proč je takový problém přijmout workflow, kdy je branch master – aktuální vývoj, jednotlivé produkční branche (třeba 2.1-dev), feature branche a hotfix branche.
Oprava chyby (hotfix) se prostě udělá v jednotlivé branchi hotfix-123, která se mergne do obou/více branchí (master, 2.1-dev). Tharosem odkazovaný workflow je ověřený a prostě funguje. A je to jenom o tom říct: tak, a teď jsme chytřejší, protože starší, a zkusíme to takhle. Gitu (si myslím) rozumím dost dobře, přesto ze stavu repozitáře nedokážu snadno říct – aha, tenhle commit v masteru je oprava chyby #xy, a bude součástí další setinkové verze, a tohle je uber-cool featura, jejíž genialitu docením teprve až David napíše článek na phpfashion.
Kdyby přechod k lepšímu workflow byl nějak kuva těžkej neřeknu, ale jenom v týhle diskuzi podle mě prosvištělo víc energie, než kolik by stálo zavedení průhlednějšího způsobu. Stejně, jako se člověk snaží, aby z API třídy bylo zřejmé co dělá, z git clone nette by mělo být zřejmé co se chystá a přijde.
#drunkenpost
A ještě dodatek, vždycky jsem obdivoval, jak to vlastně ten David dělá, že v tom i přes ten bordel(rozumějme si – hromada commitů v masteru) dokáže udržet pořádek. To zase teda respekt a možná to zjednodušení vlastně potřeba není. Ale za mě – na aktuálně aplikované workflow je potřeba minimálně o 100% větší obsah mozkové hmoty, než kterou disponuji já.
Editoval Jan Tvrdík (9. 1. 2014 2:17)
- Tharos
- Člen | 1030
Jan Tvrdík napsal(a):
To, co @Tharos navrhuje, nebude pro Nette fungovat.
Ahoj, tak jsem ještě lépe zkoumal aktuální řešení a jsem si jist, že by to fungovalo. Spíš jste mě špatně pochopili…
Mně nejde o to, aby existovala jenom jedna stable větev pojmenovaná
master, to je úplně nepodstatné. master se klidně
může jmenovat vývojová větev a bokem může být X stabilních větví (jak
je tomu teď). Mně jde čistě jenom o to, jakým způsobem se vyvíjí a
začleňují (a kam) nové featury a bugfixy.
A do toho píše David, že teď *podobu repositáře měnit nebude*… Vždyť to přece nikdo nechce (minimálně já ne). Viz také, co píše jasir.
Mám tu trochu pocit, že jeden o koze, druhý o voze, a že není vůle pochopit některé návrhy (asi ani se nad nimi zamyslet). Ale uzavřme to, tyhle diskuze jsou fakt jenom černá díra na čas a energii.
Edit: Upravil jsem ještě své příspěvky v tomhle vláknu tak, aby to sedělo na repositář s více stable větvemi (jako má nyní Nette). Snad to tak bude lépe pochopitelné…
Kdyby Nette používalo analogii k výše odkázanému branching modelu (jen s více stable větvemi), vrchol vybrané stable větve (například 2.1.x) by nesl nějaký tag (například 2.1.0). Jakmile by někdo nareportoval chybu ve verzi 2.1.0, odvodila by se z relevantní větve větev hotfix-XYZ, v ní by se chyba opravila a pak by se ta větev mergnula do 2.1.x a podle potřeby i do dalších větví (určitě do vývojové větve a také do všech chybou dotčených stable větví). Následně se ta hotfix větev odstranila a merge commity ve stable větvích by se rovnou mohly otagovat (takže by vznikl například tag 2.1.1 atp.)
Editoval Tharos (9. 1. 2014 12:39)
- Filip Procházka
- Moderator | 4668
Objeví se chyba, někdo pošle pullrequest proti masteru (hotfix- feature- branch ve forku), pokud je potřeba vydat opravnou verzi cherrypickne releasemaster potřebné commity do větve která odpovídá release řadě (release-2.0, release-2.1, …) a otaguje.
To je to vaše „otestované a prověřené workflow“ jenom aplikované s terminologií githubu. Funguje to výborně tisícům jiných opensource projektů a není žádný přínos v přejmenování několika větví. Jenom v tom vznikne bordel.
Tohle přesně se děje teď jenom David vydává patch verze za feature verze a seká v nich BC breaky (uznávám že některým se nešlo vyhnout, ale to je teď jedno). Jediné co současnému systému chybí je začít dodržovat sémantické verzování.
- jasir
- Člen | 746
No až na ten cherry-pick vs merge. Takže stejný commit má v různých branchích jiný hash. Ale nechci flameovat evidentně to funguje. Ale (sorry za OT), umíš mi poradit jak si tedy v gitu vyjedu „commity, které jsou/nejsou v masteru vs branch xxx“?
Editoval jasir (9. 1. 2014 13:15)
- David Grudl
- Nette Core | 8118
@jasir git cherry -v v2.1
ad merge vs cherry-pick: mergovat by se dalo, pokud by autor fix (třeba po schválení a mergnutí do masteru) připravil do i pro další větve. Obávám se, že to dělat nikdo nebude. Pro mě, jakožto správce dalších větví, je cherry-pick značně jednodušší.
- enumag
- Člen | 2118
David Grudl napsal(a):
ad merge vs cherry-pick: mergovat by se dalo, pokud by autor fix (třeba po schválení a mergnutí do masteru) připravil do i pro další větve. Obávám se, že to dělat nikdo nebude. Pro mě, jakožto správce dalších větví, je cherry-pick značně jednodušší.
Osobně nemám problém své PR po mergnutí do masteru takto připravit pro stable větev, otázka je zda to má smysl pokud to nebudou dělat všichni – mohlo by to naopak zkomplikovat pozdější snahy o cherry-pickování protože něco by tam už bylo.
Editoval enumag (9. 1. 2014 16:09)