Workflow vývoje Joomla webů a verzování GIT

Ahoj vespolek,
měl bych dotaz na místní vývojáře a stavitele webů:

Chtěl bych pojmout moderně vývoj svých webů postavených na Joomle tak abych měl kompletní vývoj pouze na localhostu s možností verzování v Gitu. Potom co web dodělám a odskouším, použiju ftp-deployment na zkušební hosting, kde si ověřím plnou funkčnost na hostingu a následně web nahodím na ostrý live hosting.

Napadá mě spousta otázek jak to dělat ale základní otázka je tato:

Verzujete na localhostu kompletní instalaci joomly nebo pouze její části? Když části, tak jaké? Jen šablony?

Moc díky za vaše názory, nápady a informace.

Leoš

Děkuji že jste položil tento dotaz.

Jak se zdá, je vidět, že stejně jako většina programátorů co pro mě kdy pracovala (a přesvědčovala že jejich systém je nejlepší, nejrychleší a vůbec), jsou i ostatní z joomla prostředí v české republice zvyklí pracovat jen na localhost (maximálně verzovat změny pomocí interního systému jednotlivého pracovníka v netbeans nebo phpstorm na lokální počítač každého pracovníka samostatně) a následně změny kopírovat na ftp.

My jsme to dělali od roku 2011 (a nadále v tom pokračujeme) úplně jinak.

- Celý web (původně i DB, nyní bez DP a bez fotek) verzujeme pomocí gitlabu (ještě předtím než byl, tak pomocí interního systému git).
- Každé issues (úkol v systému redmine nebo easyredmine nebo jira) má vlastní branch a do ní programátoři a kodéři umísťují změny.
- Následně vedoucí programátor nebo ten kdo otestuje a schválí funkcionalitu úprav a má práva provede merge a nasadí úpravy do vývojové branch (devel) a nakopíruje na vývojovou verzi webu na ftp.
- Následně projektový manager projde úpravy a otestuje s klientem a nechá schválit
- Následně jsou úpravy zmergovány do produkční verze webu (master) a nasazeny na produkční verzi hostingu (ftp).
- Všechny změny v kódu jsou navíc označeny ID issues v systému redmine, aby se daly dohledat - popis, zadání, průběh, korektury a porovnat s původním kódem
- Seznam změn se pak archivuje pro případný upgrade

Tohle se opakuje neustále dokud není celý web dokončený

V případě exponovaných webů a eshopů ještě existuje mezistupeň - stage - který je přesná kopie produkčního webu a slouží k odladění funkcioanlity, kdy je nutné překlápět změny za chodu (jak jsem psal, jde o oexponované a VIP projekty).

Takže máme ve výsledku v gitu 3 hlavní branch:
- devel
- stage
- master

a tři vytvořené domény pro jeden projekt.

Tímto systémem je:
- neustálá kontrola nad celým procesem změn všech pracovníků
- nejsme závislí na jednotlivých pracovnících (při odchodu z firmy, výpadku, ukončení spolupráce)
- zákazník je součástí procesu a může průběžně kontrolovat nasazení změn a schvalovat - je součástí vývojového týmu a porad
- případné kolize se dají vyhledat, systém také slouží k zjištění kde nastala chyba při vývoji nebo nasazení a kdo ji z pracovníků udělal nebo zda došlo k chybnému zadání ze strany zákazníka (tohle již může dělat jen support manager na helpdesku při případném požadavku od zákazníka a není třeba používat programátora)

Tento systém jsem bohužel nevymyslel, jen jsem dotáhl během 3 let k dokonalosti a použití pro Joomla/wordpress a práci v týmu externistů, protože na stejném systému pracují kolegové například na eshopu pro Vodafone.

Pro použití tohoto systému je potřeba
- několik přesně daných software (pro PC nebo mac) a nastavení
- přesně dané postupy a bezpečnostní přístupy
- lidi, kteří znají systém práce s gitem (pull, push, fetch, merge a řešení konfliktů) a mají vše odladěno i na localhostu
- nadefinovaný systém gitlab (uživatelé, přístupy..)
- přizpůsobené přístupy na hosting

Podobný systém používáme při vývoji aplikací a rozšíření, tam se ale systém liší v použití branch (devel, master, hotfix, features, J25. J3).

Volbu jakým systémem ve firmě pracovat nechávám na každém samostatně.

Kolegové od Vodafonu používají Jiru a Mercurial, kolegové z Nette používají Redmine a Mercurial, my na Joomla používáme EasyRedmine/Redmine/Jiru a Gitlab.

No a nyní přímo k dotazu:

- neverzujeme DB - ta se ukládá 3 měsíce do backupu
- neverzujeme složky images, cache, logs a další podle typu webu
- neverzujeme dynamické soubory
- verzujeme vše ostatní

Rudolf

P.S.
Myslím že podobným systémem se pracuje při vývoji Joomla jako takové, jen používají Git.

Myslím že základní dotaz je proč chcete verzovat úpravy na webu (verzovat jen pro verzování je nesmysl):

- co tím sledujete a co očekáváte že Vám to přinese

Podle odpovědi se dají nadefinovat metody jaké je možné použít a které ve výsledku odpovídají požadavku.

Cony,

Rudo, jak řešíte instalaci rozšíření / aktualizaci Joomly apod.?

Řešíme jako samostatnou branch aktualizace. Ta jede průběžně a do ní se vkládají instalace. Průběžně se také merguje z master.

Před spuštěním produkce stačí jen mergovat do master a devel, následně se překlopí celá DB.
Po spuštění produkce se provádí manuální instalace nejprve v branch aktualizace na vývojovém webu (FTP == propíše se i do DB) a následně po zmergování do devel a master, se provede:

- pull master na ftp produkce
- manuální instalace stejných aktualizací

Výsledkem jsou na ftp stejné soubory jako v master, které nevytvoří nutnost commitu.
Co je dynamického se negituje (např. některé soubory akeeba)

Tohle je důležité, protože při aktualizaci je provést také vyřešení konfliktů == my upravujeme Virtuemart asi na 50 místech v core, joomla na 2-3 místech (podle typu webu), o ostatních aplikacích nemluvím.

Ze začátku jsem si nebyl jistý jestli to bude fungovat a požadoval jsem od programátorů vymyslet přírůstky v DB a gitovat i tyto změny, ale protože celý systém jsem musel vymyslet sám a otestovat a tu mysql opravdu neumím a kluci na hostingu nebyli za 7 let schopni tento systém vymyslet, jedeme tímto způsobem.

Rád bych měl ale lepší systém, jako používají kolegové při vývoji eshopu Vodafone. Používají konfigurační soubory (YAML), takže jsou schopni z PHPStormu přímo spouštět synchronizace a vytvářet branch v gitlabu včetně kontroly kvality kódu (joomla, virtuemart, less soubory).

Bohužel v prostředí programátorů joomla v CZ je tohle jen moje zbožné přání a žádný z programátorů, kteří pro mě pracovali, tohle neumí. Většinu jsem musel učit já jako neprogramátor

Co se týká DOCKER for Joomla, na ten se chystáme tento rok (moc ho ještě neumíme )). Chceme ho nasadit pro naše klienty, zatím využíváme jen oddělené vhosty z důvodu bezpečnosti
Stage děláme jako samostatnou branch, která jede na dalším hostingu.
Docker se bude tedy teprve vyvíjet (snad).

Také chceme naprogramovat nový Elastic Seach pro Virtuemart a Joomla (kdysi jsme použili existující řešení a nasadili na VirtueMart a použili Amazon DB. Účet byl tak mastný, že po 3 měsících jsme ho vypnuli) a nové filtrování pro VirtueMart. Aspoň jsem to v prosinci zadával programátorovi, že tohle bude hlavní práce na tento rok.

Aktuálně jsme na filtrování pro kolo-park.cz (přeprogramované CF Filtering) strávili 80 programových hodin (bez testování a stylování) == 6 měsíců práce junior programátora Joomla a senior programátora Virtuemart.

No a ještě máme na jednoduchých webech nasazenou automatiku aktualizací.

Cože je super, jen mi přijde email:
- aktualizován JCE
- aktualizováno RSForm
- aktualizováno RSFirewall

O nic se nestarám, nic neinstaluji, nic nestahuji jen na konci roku zákazníkovi vyúčtuji roční aktualizace a licence.

protože se nepočítá s tím, že se mezitím změní DB na produkčním webu.

Počítá

Při určitém stavu nekonzistentnosti se zmerguje master do develu (mimochodem to by se mělo dělat pravidelně po nasazení várky úprav == úkolů == branches) se také MANUALNE zkopíruje DB z master na devel, se všema náležitostma (rozdílné configy, co se ukládají do DB, v našem případě OPC)

A jede se dále....

Oddělení DB a Gitu má svou jednu výhodu - úpravy můžete gitovat i při nekonzistentosti DB

Ahoj kluci,
moc vám všem děkuji za zapojení do diskuze. Vysvětlení je opravdu výživné.
Ano, jsem jednotlivec dělající weby. Jen jsem chtěl konzultovat právě verzování do GITu. Hlavně pro přehled všech změn kódu, který jsem udělal. Už po půl roce si nepamatuji proč, kde ale kouknu do repozitáře a mám tam okomentované změny.
Verzování obsahu článků je super pomocí samotné Joomly, to je fakt. Override souborů je také samozřejmost.

Z toho všeho mi vyplývá, že by stačilo hodit do GITu poprvé celou Joomlu se vším rozšířením a potom už si verzovat do GITu jen co je potřeba.
Databázi zálohuji pravidelně po každé změně, která ji ovlivní. Manuálně pomocí PhpMyAdmina.

Nějaké velké zásahy do core kódu nedělám, spíše jen frontend. To verzování mám i jako jednu z forem zálohy.

Je hodně zajímavé sledovat, jak to každý dělá trochu jinak A je to i poučné.
Dík moc a kdyby měl někdo ještě nějaký tip, neváhejte se mi svěřit

Z toho všeho mi vyplývá, že by stačilo hodit do GITu poprvé celou Joomlu se vším rozšířením a potom už si verzovat do GITu jen co je potřeba.

Ano.¨
Dnes mi programátor doprogramoval úpravu naši pro discontinued produkty pro plugin catproduct-content (vypadá to že vývojáři skončili, tak to bude asi další rozšíření, které převezmeme a budeme rozvíjet) a core plugin VirtueMartu - generická varianta productu (Customfield typu A).

Protože úkol má číslo 17013,
- v gitu si vytvořil z mastera branch - 17013
- do ní commitnul změny s poznámkou - 17013 - discontinued v catproduct (vmcustom) + customfield(type A)
- v kódu označil změny - // #17013 - discontinued product
- udělal screen po nasazení
- přidal URL testovacího produktu po úpravě == že to funguje, aby testér mohl otestovat
- odeslal úpravu do gitu
- vložil do poznámky v úkolu URL commitu, abych si prohlédl kód nebo jiný programátor a zkontroloval

Jakmile schválím výsledek:
- udělám merge do branch devel a nasadím na vývoj, kde to již zkontroluje zákazník.
- následně merge do master a nasazení na ftp produkce
- vyfakturuji

Celkem programátorovi přibyla práce v řádu 1-2 minuty aby takto postupoval + zápis do úkolu (to by ale musel dělat tak jako tak).

Jakmile si takto zvyknou kolegové pracovat, již nic neřeší, protože to následně ušetří mnoho hodin práce při chybách nebo dalších úpravách.

P.S.
Mimochodem,celý tento dotaz v kostce byla plánovaná přednáška, kterou jsem chtěl udělat v Olomouci (pokud tam někdy tedy dorazím

Obrovská výhoda tohoto postupu je ta, že následně na další eshop prostě vezmu všechny úpravy v branch Discontinued a nasadím na další eshop (to už mohu nasazovat já jako admin a ne programátor).