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

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