Údržba customizací rubrika: Programování: Jiné

3 Petr Hubík
položil/-a 9.5.2013

Píšu takový malý eshop na zakázku a klient se rozhodl, že chce ten stejný kód s mírnými úpravami zprovoznit na jiné doméně. Změny se týkají především v povinnosti registrace před nákupem, jiným způsobem zobrazování cen a pár dalšími úpravami.
Řeším problém, jak vlastně takový kód udržovat. Nechci mít dva z 90 % stejné kódy úplně oddělené a když budu opravovat nějakou součást, muset ji opravit v obou (a v budoucnu možní i ve více) repozitářích.
Určitě někdo musel podobný problém řešit, existuje spousta firem co vyvíjí „krabicový“ software a pak jej mírně poupraví pro potřeby zákazníka. Nevěřím, že by měli repozitáře úplně oddělené.
Máte někdo nějaké zkušenosti?

Díky

odkaz Vyřešeno
9 Vašek Ch.
odpověděl/-a 9.5.2013

Podle mě máš dvě možnosti:
1) Všechno můžeš udržovat v jednom produktu. Pokud shledáš, že ty změny nejsou tak velké, můžou to být dva eshopy s úplně totožným kódem, jen jiným konfigurákem (který něco zapne, něco přepne, něco vypne). O složitosti těch rozdílů si ale musíš rozhodnout sám, tedy zejména, jestli je tohle trvale udržitelná cesta.

2) Mít kód ve dvou, resp. třech branchích. Prakticky bych ze současné verze vytvořil jakousi "base" branch se základní funkcionalitou. Pak bych vytvořil další dvě branche, každou pro jednu verzi eshopu. Pokud by se týkala změna jen jedné nebo druhé verze (tj. třeba jednu chceš přemalovat na růžovo a v druhé chceš nahoře přidat banner), prováděl bys takové změny v těch konkrétních branchích. A pokud bys dělal změny, které mají ovlivnit oba eshopy (typicky bugfixy atp.), měnil bys to v oné "base" branchi, kterou bys potom vždycky mergnul do obou specializovaných branchí.

V praxi bych to udělal v GITu dokonce jako dva repozitáře (byť to není nutnost), které mají sdílenou tu jednu base branch, kterou bych držel v repozitáři třetím. Tím pádem společné změny děláš jen jednou a merguješ pak do kolika různých verzí produktu potřebuješ.

Komentáře

  • Vašek Ch. : Ještě mě napadá, byť to situaci komplikuje, ale osobně bych šel touhle cestou kvůli, řekněme, čistší architektuře -- že pro třetí a další verze eshopu by bylo vhodné mít všechny "odbarvovací" commity (tj. ty, které mění současnou konkrétní verzi eshopu spíše na nějakou neutrální šablonu, na níž lze stavět verze další) taky někde stranou. Ve výsledku bys teda měl base branch(1), z níž by vycházely první verze eshopu(2) a odbarvená branch(3), a z odbarvené branche by pak vycházely branch s druhou a každou další verzí eshopu (4 atd.). Všechny společné fixy i fičury bys commitoval do base branche a rozmergovával do všech ostatních branchí s eshopy, a všechny odbarvující commity bys commitoval do odbarvené brachne a rozmergovával do všech verzí eshopu vyjma toho prvního. 10.5.2013
  • Petr Hubík : Tohle je dobrý a dostatečně jednoduchý způsob, budu se držet jeho. Díky 10.5.2013
  • arron : Zní a vypadá to moc hezky, ale z dlouhodobého hlediska se ukázalo (prošel jsem tím), že ani tenhle způsob není dlouhodobě udržitelný. Mějme například usecase: V base branchi udělám změnu, který není uplně zpětně kompatibilní. U některých klientů to nevadí (takže udělám merge), u některých klientů to vadí (takže merge neudělám). Pak udělám nějaký bug-fix. Ten ale chci mergnout všude. Jenže tenhle bug-fix je závislý na předchozí nekompatibilní změně => mám problém. Časem se z toho stane trochu chaos a udělat merge je čím dál tím obtížnější. Samozřejmě je ale potřeba mít společné věci oddělené. Osobně bych dneska už šel cestou jednotlivých verzí společného projektu a oddělených repozitářů jednotlivých projektů. Base se do tohoto repozitáře dostane skrz composer (pokud se bavíme o php) jako závislost. U base projektu pak vydávám jednotlivé verze (čísla verze musí jít jistá pravidla, aby v tom nevznikl chaos, viz. například http://semver.org/) a u projektů, kde je to nutné provádím upgrade (jistě na to půjde udělat i nějaký hezky skriptík, aby se to nemuselo dělat ručně). Jistě se i tady dají najích chyby a problémy, ale z dlouhodobého hlediska se to zatím ukázalo jako nejlepší cesta. A pokud je to celé podpořeno testy (alespoň unit testy), může být i upgrade na nekompatibilní verzi docela jednoduchý. :-) 15.5.2013
  • Vašek Ch. : No, jasně, můj přístup nepředpokládá, že vytvoříš nějakou změnu, kterou bys nemergnul. To pak, věřím, začne peklíčko :-). Dle mého názoru ale musí principiálně vyjít nastejno, jestli si různé brachne společné library držíš někde vedle separátně v balíku dotahovaným composerem, nebo jestli je merguješ do projektu přímo. (Že to může být krapet pohodlnější, uznávám; ale nejsem si tím tak úplně jistý.) Každopádně taky schůdná cesta :-). 16.5.2013

Pro zobrazení všech 4 odpovědí se prosím přihlaste:

Rychlé přihlášení přes sociální sítě:

Nebo se přihlaste jménem a heslem:

Zadejte prosím svou e-mailovou adresu.
Zadejte své heslo.