Moje development & deployment workflow vývojáře pro Drupal, Symfony, WordPress a Hugo

Jak vytvářím a nasazuji do produkce webové stránky, o tom jsem na Maxiorlovi psal už vícekrát v různých článcích. Ale vždy jen dílčí věci. Rozhodl jsem se připravit ucelený přehled. Ostatně i proto, abych jej mohl sdílet při vysvětlování, proč pro většinu projektů, na kterých pracuji, nevystačím s obyčejným hostingem s FTP.

Není to nic objevného, kdokoli, kdo pracuje na velkých projektech, tak by asi sepsal zajímavější povídání. Mou realitou je malý tým dvou vývojářů (backend, frontend), případně dalších kolegů z agentury Lesensky.cz, kteří se do tvorby webu zapojují – projekt, UX, grafika.

Na druhou stranu, je spousta malých vývojářů, tak třeba si při čtení následujících řádků alespoň řeknete, že to děláte podobně nebo lépe a udělá vám to radost.

Příprava projektu a grafika

Úplné začátky přípravy webového projektu se v mém případě dosti liší. K řadě z nich se dostávám ve chvíli, kdy už je to připraveno pro programátora. Pokud jde o projekty u nás v agentuře, to je jiná věc, tam jsem v různé míře intenzity už od počátků. Ale většina práce je v tuto chvíli u kolegů.

Určitě mohu prozradit, že pro přípravu a svou i klientovu představu o velikosti webu používáme Octopus. Občas není zbytí a použijeme Balsamiq. U firemního či obsahového webu nám bohatě stačí Octopus, wireframy si pomáháme třeba u e-shopů.

Já sám jsem pro wireframy a návrh struktury několikrát používal Moqups a v případě potřeby bych si je bez váhání opětovně předplatil.

Grafiku dnes kreslíme výhradně v nástroji Figma. Mimo agenturu se mi dostávají do rukou projekty také z 90 % v tomto nástroji. Sem tam výjimečně někdo pošle či nasdílí XD, za poslední rok to ale byl snad už jediný případ. Jednorázové úlety náhodných poptávek typu grafika v Corelu a podobně už neřeším.

Figma má výhodu v možnosti snadného sdílení náhledu pro klienta, já si zase užívám, že kolegové mi v ní připraví samostatné stránky s výkresy upravenými pro potřeby vývoje a nemusím se zatěžovat tím, co dalšího tam kreslili. Fajn jsou bezesporu nejrůznější animační pluginy, které nám všem šetří práci a weby oživí.

Image

Úkoly a procesy řešíme v mém oblíbeném Trello. Nepoužíváme to úplně stylem kanban, tj. tři sloupečky a přetahování kartiček. Slouží nám jako informační nástěnka ke každému projektu a úkolníček pro každého člena týmu. Já sám si nejvíce cením možnosti vytváření seznamů v rámci karty, přiřazování lidí a data. Tím se mi vše hezky promítá do kalendáře v Planyway, kterým začínám a končím pracovní den.

Vývoj webu a deployment

Tady je to bezesporu zajímavější. Co se vývojářských nástrojů týče, pravidelně reportuji v softwarové inventuře. Letos se stále držím oblíbené dvojice PhpStorm a Visual Studio Code v MacOS. Byť teda pořád lavíruji, jestli z VS Code konečně přesedlám na editor Zed, ale stále jsem se definitivně nerozhodl.

Webové stránky tvořím na následujících platformách. Řazeno dle obliby a četnosti:

• Drupal
• WordPress
• Symfony
• Hugo
• Backdrop

Workflow pro WordPress

WordPress nasazujeme hlavně na menší weby a poslední rok mě téměř stoprocentně nahradil brácha, který má WordPress zmáknutý. Používá především výchozí blokový editor Gutenberg, okolo kterého se vše točí. V případě složitějších věcí se zapojím též, to když stavíme něco čistě s využitím Advanced Custom Fields a bez Gutenbergu. Ale dává mi to smysl čím dál méně, z hlediska pracnosti jsem pak v takovém scénáři efektivnější a rychlejší s Drupalem.

Tím, co na WordPressu stavíme, je dáno i workflow. Toto je jediný případ, s výjimkou nějakých ministránek v HTML, kde si opravdu vystačíme s obyčejným „hloupým“ hostingem, který poskytuje maximálně připojení přes FTP. Žádný Git a složitější workflow, nedává mi to zde smysl. Podobné projekty velmi zřídka stavíme na Backdropu, což je něco jako modernizovaná předchozí generace Drupalu bez Symfony.

Workflow pro Drupal

Naopak u Drupalu už zapojujeme celou řadu dalších nástrojů:

• Virtuální server u Akamai/Linode pro vývojovou verzi webu
• Git storage s nástrojem Gitea
• Deployment přes Git nebo nástroj Drone.io
• Webhosting s podporou SSH, Composeru a Gitu

Je to dáno také tím, že na webech pro Drupal nepracuji sám, ale v týmu minimálně dvou lidí. U většího týmu by to samozřejmě chtělo poněkud odlišný scénář. Rád bych si jej někdy zkusil, třeba k tomu dorosteme ještě před důchodem.

Začátek vývoje nemám řešený úplně nejlépe. Používám výchozí instalaci systému v lokálním počítači, která má připraveny věci, co se mi na všech projektech opakují. Nakonfigurované doplňkové moduly, kostru tématu vzhledu, single directory components, různé JavaScripty, stylování atd. 

Rozsáhlým shell skriptem vytvořím z připraveného balíčku kopii, odpovídáním na příkazovém řádku vkládám hodnoty, které se mají v nové instalaci nastavit (název webu, tématu vzhledu, výchozí adresy, hash salt atd.). Následně se automaticky vytvoří pomocí naskriptovaného VirtualMinu nová instance webu na vývojovém virtuálním serveru a rovněž se vytvoří projekt v git storage Gitea.

Gitea je modernější a více udržovaná verze gitového úložiště Gogs, se kterým jsem začínal. Běží mi v Dockeru nas Synology NAS. Má své API, proto jej mohu skriptovat a volat. Nejenom pro vytvoření projektu, ale i pro přidání spolupracovníků.

Image

Rozběhnutá nová lokální instalace se tedy skriptem pushne do Gitu, odkud putuje na server nebo hosting. Nasazování z Gitu řeším dvěma způsoby. Momentálně můj oblíbenější a výrazně rychlejší je prostý post-receive hook, který se přes SSH spojí s vývojovým nebo development serverem, provede tam git pull a spustí případné další skripty (composer install, update databáze Drupalu, vymazání cache). Chvíli mi trvalo vyzkoumat, jak mít vše potřebné mimo Docker, včetně klíčů, ale podařilo se.

Pokud nemohu použít SSH, pak využívám nástroj Drone.io. Ten opět hostuji v Dockeru na Synology NAS a pro tyto projekty pak používám jednoduchou pipeline, která rozběhne image s nástrojem phploy, který kopíruje upravené soubory přes prosté FTP. 

Má to řadu nevýhod, od výrazně pomalejšího zpracování až třeba k tomu, že v Gitu musím mít vše, neboť composer na serveru nezavolám a nechci jej volat lokálně a následně po FTP kopírovat úplně vše. Takto se z Gitu přenesou jen změněné soubory. Bohužel pak musím provádět ručně úpravy databáze, je tam určitá prodleva a zkrátka vůbec to není dobré řešení. Ale je mnohem lepší, než když jsem vyvíjel přímo na produkci nebo vše kopíroval ručně.

Image

S bratrem máme rozdělené role, já se starám o Drupal jako takový, programování modulů, implementaci a nastavení, některé JavaScripty, on řeší CSS a zbytek JS. Sesynchronizování díky Gitu máme téměř bez zádrhelů.

Workflow pro Symfony

Se Symfony je život trochu jednodušší. Na projektech, které s tím stavím, si vystačím s webovým serverem v PHP, tedy vždy si jej zavolám příkazem symfony serve. Pro deployment opět používám převážně post-receive hook v Gitea. Od Drupalovského se liší tím, že volá migrace, dumpy assetů a jiné specifické věci pro projekty v Symfony.

Jedinkrát jsem se nechal přesvědčit, abych projekt v Symfony s databází dal na Wedos. Je s tím velké mrzení ve chvíli, kdy je potřeba změna struktury databáze a vlastně i dump assetů (používám Asset Mapper).

Máme zde jedno specifikum. Vytvářím interní aplikaci pro agenturu a pomáhá mi s ní kolega z PR oddělení. Naučil se bez předchozí zkušenosti Git, minimálně základy PHP, zvládne si editovat Twigové šablony, s pomocí AI doplní i nějakou funkcionalitu. To říkám jen na to konto, že občas slýchám, jak je složité do Symfony proniknout.

Workflow pro Hugo

Abych byl zcela kompletní, zmíním ještě pár projektů na platformě Hugo. Většinou jde o mé vlastní projekty a u nich jsem se rozhodl využívat GitHub s jeho GitHub Actions. V nich mám naskriptované sestavení webu a jeho následný deployment do produkce, pro jejíž hostování používám GitHub Pages. Není to kdovíjak rychlé, ale spolehlivé řešení. A samotné ty stránky jsou bleskurychlé.

Šel jsem do GitHubu proto, abych se naučil něco nového, co třeba zatím nemám šanci využít pro klienty, ale je to poměrně používaná záležitost a zkušenost s GitHub Actions se do budoucna hodí.

Image

Co bych změnil a neměnil?

Urazil jsem docela dlouhou cestu od chvíle, kdy jsem žasl na jednoduchým deploymentem na bázi rsync pro aplikace ve frameworku Silex. Přesto vidím nějaké rezervy:

• U většího projektu bude potřeba zapojit automatizované testy a nespoléhat na lokální ladění.
• Je otázka, zda se pak nevrátím zase k Drone. Láká mě vyzkoušet spíše Gitea Actions, ale nepodařil se mi nakonfigurovat jejich Docker image v Symfony.
• Zaujal mě nedávno Dagger, po přednášce na SymfonyCon ve Vídni jej vyzkouším.
• Rozběhnutí Drupalu. Bude to chtít něco univerzálnějšího, co nebude závislé pouze na mém lokálním počítači. Přemýšlím nad doprogramováním nástroje do VirtualMinu, bylo by jistě zajímavé se něco takového naučit. Mám i požadavky provozovat vývoj rovnou na hostingu, ale tam si nedovedu představit, jak bych vše výše uvedené naskriptoval.
• Rád bych někdy pracoval se Symfony Cloud, resp. s Platform.sh nebo Pantheonem. Acquia Cloud jsem už v českých podmínkách odpískal.

Budu rád, když mi pod článkem nebo někde na sociální síti dáte vědět, co používáte vy. Případně od zkušenějších harcovníků uvítám tipy na vylepšení mého workflow.

Bonus: zálohování

Bez zálohy už ani ránu. Celý počítač se mi zálohuje přes Time Machine do NAS a na externí disk. Dále používám Synology Drive, což je taková obdoba Dropboxu pro synchronizaci a zálohování vybraných složek. Celý NAS pak zálohuji do Backblaze B2. Některé věci ještě synchronizuji mezi Gitea a privátním GitHubem.

Zálohovaný mám i virtuální server, každodenní záloha webů ve VirtualMinu kopírovaná samozřejmě mimo server, udržování 14 záloh dozadu. Celý image serveru pak zálohuje i Akamai. Na produkci používáme především Websupport, rovněž s pravidelným zálohováním a především snadnou obnovou vybraných souborů i databáze bez nutnosti kontaktovat podporu.

A celý postup mám popsaný v Notion, abych byl schopen, až dojde na nejhorší, jej restaurovat.