Verzování software, udržování forků a implementace oprav

Doporučili byste prosím zdroj kde by byla popsána "teorie" nebo zavedená praxe jak verzovat SW, udržovat forky pro mírně odlišné implementace, jak udržovat informace co je kde implementováno apod.?  Požadavky na změny vedeme v mantisu, schází se nám tam jak bug reporty, tak požadavky na zákaznické úpravy, včetně vývojových požadavků na verze budoucí/experimentální. A výsledkem je celkem solidní bordel :-(
Chtěl bych si někde nastudoval jaká je praxe při vytváření forků, udržování větví, jak se řeší budoucí vývoj a podobně...
« Poslední změna: 11. 07. 2023, 17:18:22 od Petr Krčmář »
Gréta je nejlepší.


RDa

  • *****
  • 2 539
    • Zobrazit profil
    • E-mail

alex6bbc

  • *****
  • 1 498
    • Zobrazit profil
    • E-mail
tak to jsem zazil v jedne firme.
kdyby to byly 3 ruzne verze, tak by asi i rucne v klidu slo aplikovat zmeny do vsech verzi.
ale v te firme bylo asi 8 ruznych verzi a kazdy zakaznik chtel jen tu svoji verzi a ani zadarmo nechteli prejit na nejvyssi
spolecnou verzi, bali se co vsecko muze prestat fungovat.

takze kdyz se na jedne verzi neco fixlo, tak se to rucne mergeovalo do vsech ostatnich a pokud byl rozdil mezi verzema ponekud vetsi, tak to bylo na samostatny debugging jestli to tam pasuje, zda je stejne api a podobne.

proste opruz jako prase.

CPU

  • *****
  • 659
    • Zobrazit profil
    • E-mail
Je produkční verze a pak custom verze, pokud zákazník trvá na speciálním supportu, no tak si to taky zaplatí.
Peníze jsou řešení na hromadu problémů a pokud to peníze neřeší, je potřeba víc peněz.

Díky za ten GitFlow, to je myslím to co hledám. Je to dost zapeklitá situace, mladý team, nadšený ale nepříliš zkušený, takže s množstvím oprav, změn a forků roste chaos...
Gréta je nejlepší.


Kit

  • *****
  • 704
    • Zobrazit profil
    • E-mail
Hlavně nedělat forky, ale branche.

Kit

  • *****
  • 704
    • Zobrazit profil
    • E-mail
Taková jednoduchá pravidla, která samozřejmě mohou mít výjimky:
  • pokud chci svou vývojovou verzi aktualizovat podle větve master, použiji git rebase
  • pokud chci do master zahrnout hotovou vývojovou verzi, použiji git merge --no-ff

alex6bbc

  • *****
  • 1 498
    • Zobrazit profil
    • E-mail
souhlas delan branchu na bugy a featury, a pak hned mergnout do master vetve, at ty branche nehnijou dlouho.

Re:Verzování software, udržování forků a implementace oprav
« Odpověď #8 kdy: 11. 07. 2023, 17:29:52 »
Zazil jsem vyvoj netrivialniho sw, kde hlavni modul byl udrzovan v nekolika verzich. Ke kazde verzi hlavniho modulu se navic udrzovalo N verzi podpurnych modulu z duvodu externi kompatibility podpurnych modulu. Ve vysledku pak bylo velke mnozstvi vetvi v ruznych repozitarich a nebylo to jednoduche. Testovani bylo narocne, taktez udrzovani build infrastruktury. 

Bohuzel nevim o zadnem cteni na toto tema.

Dobre je mit systematickeho cloveka, co produktu rozumi, je schopny udrzovat jeden zdroj pravdy (jira and/or wiki / ...) a je schopen to uridit.

Jeste poznamka: git --contains se mi osvedcil v situaci, kdyz se potrebuje vedet, jestli se commit dostal na branch, tag.

Re:Verzování software, udržování forků a implementace oprav
« Odpověď #9 kdy: 12. 07. 2023, 08:23:58 »
Celkom dobra prax je niektore upravy zahrnut do hlavnej vetvy, a v programe zapinat/vypinat podla zakaznika.
Najma, ak ide o veci, ktore by teoreticky v buducnosti vyuzilo viac ludi.
A asi je lepsie davat to ako samostatne branche, lepsie sa to potom udrzuje, ak sa v hlavnej vetve robia zmeny. Tiez, ak nieco ide do produkcie, a nieco su buduce zmeny, tak to vies udrzovat pekne v hlavnych vetvach, a hlavne vies lepsie urobit merge.

JmJ

  • ****
  • 322
    • Zobrazit profil
Díky za ten GitFlow, to je myslím to co hledám. Je to dost zapeklitá situace, mladý team, nadšený ale nepříliš zkušený, takže s množstvím oprav, změn a forků roste chaos...
Minimalne vyjit z GitFlow je fajn. Urcite mejte jednu vetev, ve ktere mate uzavrene releasy oznacene tagama. Takova vetev je zpravidla master. Zvlast mejte vetev, ve ktere probiha vyvoj, ktery vice mene na nic nehledi a jede dopredu. Takovou vetvi je vetsinou develop. A urcite mejte vetev, ve ktere se resi release. Tedy v momente, kdy si reknete, ze tenhle stav developu chcete pustit do sveta, tak se udela release vetev. V release vetvi uz pak delat opravy a pripadne i nejake nove veci s velkym ohledem na to, ze to uz nekde bezi a ze se fakt nesmi nic vic rozbit atd.

Pokud mozno nedrzte vetve prilis dlouho od sebe. Release je potreba mergovat do developu, ruzne drobne vyvojove vetve zpet do developu ci releasu atd. Pokud dlouho makam na necem, co mam odvetvene z developu, tak si pravidelne merguju z developu do sve vetve.

Je spousta pravidel, co se pry MUSI delat a co se NESMI delat. Kazdy druh sw se pri vyvoji chova krapet jinak a je potreba podle toho git flow ohnout. Napr. se rika, ze release veteve ma byt jedna. Mozna je to realne u nejake appky pro mobil, ale u aplikace pro prumysl je potreba umet pracovat s hlubsi historii a tak se muzou drzet release vetve treba tri.

Hlavne rozum do hrsti a kdyz neco delam s repem, tak idealne prvni lokalne a dokud to v grafu nevypada tak jak chci, tak nedelam push do remote a tak podobne ;-).

L..

  • ****
  • 309
    • Zobrazit profil
    • E-mail
Re:Verzování software, udržování forků a implementace oprav
« Odpověď #11 kdy: 12. 07. 2023, 09:44:39 »
Celkom dobra prax je niektore upravy zahrnut do hlavnej vetvy, a v programe zapinat/vypinat podla zakaznika.

Tak tak. Neznám tu konkrétní situaci - záleží jak moc / v čem se ty verze liší. Ale snažil bych se mít pokud možno všechny varianty v jednom stromu a zapínat / modifikovat jednotlivé featury konfigurací.

Dělám teď na SW který je sice interní, ale běží v několika různých nasazeních, kde jsou asi tři hlavní typy a v rámci nich je vždycky několik podtypů. A všechno je to jedno repo, jedna větev a konkrétní chování se nastavuje konfiurací.

Re:Verzování software, udržování forků a implementace oprav
« Odpověď #12 kdy: 12. 07. 2023, 21:49:06 »
Karmelos mal otázku na zdroj informácií a preto nejdem do detailov.

V minulosti sa mi najviac osvedčila kniha Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation (Addison-Wesley Signature Series). Má síce nejaký ten rok od vydania, ale aj teraz ju považujem za dostatočne aktuálnu.

Online zdroj od toho istého autora je na webe https://continuousdelivery.com/ .

Na prácu s git odporúčam knihu "Pro Git", Scott Chacon voľne dostupnú na webe https://knihy.nic.cz/ .

Kit

  • *****
  • 704
    • Zobrazit profil
    • E-mail
Re:Verzování software, udržování forků a implementace oprav
« Odpověď #13 kdy: 13. 07. 2023, 16:32:39 »
Celkom dobra prax je niektore upravy zahrnut do hlavnej vetvy, a v programe zapinat/vypinat podla zakaznika.

Tak tak. Neznám tu konkrétní situaci - záleží jak moc / v čem se ty verze liší. Ale snažil bych se mít pokud možno všechny varianty v jednom stromu a zapínat / modifikovat jednotlivé featury konfigurací.

Dělám teď na SW který je sice interní, ale běží v několika různých nasazeních, kde jsou asi tři hlavní typy a v rámci nich je vždycky několik podtypů. A všechno je to jedno repo, jedna větev a konkrétní chování se nastavuje konfiurací.

Kdysi jsem dělal jednu aplikaci, kde jsem měl podobné dilema. Vyřešil jsem to konfigurací v databázi, kdy u nezaplacené featury jednoduše nebyla přítomna odpovídající tabulka a ta část aplikace se řídila její strukturou, tedy reflexí. Fungovalo to skvěle, aplikace byla jednotná pro všechny.

jjrsk

  • ****
  • 400
    • Zobrazit profil
Re:Verzování software, udržování forků a implementace oprav
« Odpověď #14 kdy: 13. 07. 2023, 17:04:45 »
Celkom dobra prax je niektore upravy zahrnut do hlavnej vetvy, a v programe zapinat/vypinat podla zakaznika.

Tak tak. ...

Tohle ne vzdy chces/muzes udelat, a ty duvody nemusi byt jen technicke. Rekl bych ze vhodnejsi je system "hacku" = mas v kodu mista, do kterych napojis customizaci pro jednotlivy zakazniky. Typicky treba na zacatku/konci funkci = muzes upravit vstup a vystup. Coz muzes ve finale udelat i tak, ze mas oddelene i binarky = mas main appku, a ta si nacte ty modifikacni moduly, ktere na prislusnem miste zavola. Neni modul, neni modifikace.

Kazdopadne predpoklad je, ze si pro zakazniky dostatecne duveryhodny partner na to, aby vubec byli ochotni aplikaci aktualizovat. Protoze pokud maji zkusenost, ze aktualizace = obskurni postup podle 30ti strankoveho blabolu a 1/2 rocni ladeni a hledani toho, proc X nebo Y nedela co ma, tak je uplne jedno jak to delas.