--- title: "Zero-downtime deployment pre WordPress s Trellis: ako funguje „atomic release“ v praxi" url: "https://helloblog.io/sk/zero-downtime-deployment-wordpress-trellis-atomic-release/" date: "2025-10-02" modified: "2026-01-20" author: "Zuzana Horváthová" language: "sk_SK" categories: ["Ekosystém WordPress"] tags: ["Bedrock", "Deploy", "DevOps", "Trellis", "WordPress"] featured_image: "https://helloblog.io/app/uploads/sites/16/2026/01/featured-2-1024x572.png" excerpt: "Nahrávanie súborov na produkciu „cez živý web“ je najrýchlejšia cesta k tomu, aby návštevníci pri deployi videli chyby. Trellis to rieši moderným atomic deployment prístupom: nový release pripraví bokom a na konci len prehodí symlink." --- # Zero-downtime deployment pre WordPress s Trellis: ako funguje „atomic release“ v praxi V WordPress svete sa deployment často berie ako nutné zlo: pár súborov prepísať cez FTP, prípadne `rsync`, a dúfať, že to nikto práve neotvára. V modernej aplikačnej praxi je však bežné, že deploy prebehne bez výpadku a bez medzistavu, v ktorom server servuje mix starých a nových súborov. Trellis (nástroj z ekosystému Roots, postavený na Ansible) má zero-downtime deploymenty pripravené „out of the box“. Dôležité je aj to, že Trellis nemusíš používať na celý workflow – veľa tímov ho využíva čisto na nasadzovanie Bedrock projektov na rôznych hostingoch, zatiaľ čo lokálne si bežia v prostredí, ktoré im vyhovuje (Valet, Lando, DDEV a pod.). ## Čo presne znamená „zero downtime deployment“ pri WordPress webe Zero downtime deployment znamená, že web je počas celého nasadenia dostupný a funkčný. Nie je tam okno, keď sa postupne prepisujú súbory a používateľ náhodou trafí stránku, ktorá už načítala nový PHP kód, ale ešte staré assety (alebo naopak). Kľúčový princíp je **atomic switch**: nový release sa kompletne pripraví izolovane a až keď je hotový, prepne sa naň naraz. V ideálnom prípade je to operácia na úrovni filesystemu (preklopenie symlinku), ktorá je prakticky okamžitá. ## Prečo tradičný WordPress deploy tak často bolí Najbežnejšie prístupy pri WordPress deployoch majú spoločný problém: **menia súbory priamo v živom adresári**. - **FTP uploady:** zmena prebieha po súboroch. Počas uploadu môže web servovať kombináciu starých a nových súborov, čo vie rozhodiť šablóny, autoloading aj cache. - **Synchronizácia súborov (napr. `rsync`):** rýchlejšie než FTP, ale stále prepisuje súbory „in-place“ počas toho, ako web beží. - **Plugin-based deployment na managed hostingu:** pohodlné, ale často s rovnakým základným problémom – update súborov priamo na mieste a bez skutočne okamžitého rollbacku. Výsledok je typicky kombinácia troch rizík: (1) krátkodobé rozbitie webu počas deployu, (2) zložitý návrat späť, keď sa niečo pokazí, (3) návštevníci môžu dostať chybu práve v čase, keď sa to „prelieva“. ## Ako to Trellis rieši: atomic a immutable releases Trellis používa model, ktorý je známy z deployov moderných aplikácií: **atomic deployments**. Nasadenie vytvorí **nový release adresár**, pripraví ho kompletne bokom a až na konci prepne web na nový release. Zároveň ide o **immutable** prístup: keď je release raz nasadený, jeho súbory sa už spätne neupravujú. Každý ďalší deploy vytvorí ďalší adresár. Vďaka tomu je rollback triviálny. ### Typická adresárová štruktúra na serveri ``` /srv/www/example.com/ ├── current/ # symlink na aktívny release ├── releases/ # všetky nasadené releasy │ ├── 20250930124530/ │ ├── 20250930083045/ │ └── 20250930141622/ # najnovší ├── shared/ # zdieľané súbory medzi release-mi │ └── uploads/ └── logs/ ``` Najdôležitejší je adresár `current`. V skutočnosti to nie je „klasický“ adresár, ale **symbolický link (symlink)**, na ktorý je nasmerovaný webserver. Pre používateľa je jedno, kam ukazuje – pre Trellis je to prepínač medzi release-mi. ### Čo sa deje pri `trellis deploy production` Pri deployi Trellis typicky prejde niekoľko fáz (názvy krokov uvidíš aj v logu deployu): 1. **Initialize:** skontroluje/vytvorí štruktúru na serveri a založí nový release adresár (často podľa timestampu). 2. **Update:** stiahne najnovší kód z Git repozitára do dočasného zdroja – mimo live webu. 3. **Prepare:** pripraví súbory pre nový release adresár. 4. **Build:** spustí `composer install` a dotiahne PHP závislosti. 5. **Share:** pripojí zdieľané adresáre a súbory (typicky `uploads`) zo `shared/` do nového release cez symlinky. 6. **Finalize:** prehodí symlink `current` na nový release. Toto je ten „atomic“ moment. Pointa: kým sa všetko pripravuje, návštevníci stále idú na starý release. Až keď je nový release hotový, `current` sa prehodí a web okamžite začne servovať nové súbory. ## Databáza je samostatná téma: migrácie nie sú automaticky súčasťou deployu Je fér povedať, že zero-downtime v Trellis sa týka primárne **kódu a súborov**. Zmeny databázovej schémy (migrácie) sú samostatný problém a podľa dokumentácie Trellis nie sú automaticky zahrnuté do deploy procesu. Ak používaš Acorn (frameworkový základ od Roots, ktorý prináša Laravel štýl do WordPress projektu), vieš pracovať s **Laravel migrations** a naplánovať ich spúšťanie ako súčasť nasadenia. Pri návrhu migrácií sa oplatí myslieť na kompatibilitu dopredu/dozadu, aby si minimalizoval riziko problémov pri prechode medzi release-mi. ## Rollback: prečo je to pri atomic deployoch taká veľká vec Keď každý deploy vytvorí plnohodnotný, oddelený release adresár a nič sa neprepisuje „na mieste“, rollback je v princípe len návrat symlinku na predchádzajúci release. ``` trellis rollback production ``` Trellis štandardne drží na serveri niekoľko posledných releasov (podľa nastavenia; bežne sa ponecháva posledných pár), takže návrat späť je otázka okamihu – bez kopírovania súborov a bez „rušenia“ živého webu. ## Deploy hooks: prispôsobenie bez hackovania core procesu V praxi málokedy chceš deploy „len“ prehodiť kód. Trellis má preto deploy hooks (hook = bod v procese, kde vieš doplniť vlastné kroky), ktoré pokrývajú viacero fáz – napríklad pred/po build krokoch alebo pred/po finálnom prepnutí release. Vďaka hookom sa dá elegantne implementovať napríklad: - backup databázy pred deployom - čistenie cache po deployi - notifikácie tímu o nasadení - smoke testy proti novému release (ideálne ešte pred prepnutím, ak to workflow dovolí) ## Ako začať bez toho, aby si musel meniť celý lokálny setup Ak chceš Trellis využiť primárne kvôli nasadzovaniu, zvyčajne dáva zmysel postaviť WordPress projekt na Bedrocku (lepšia štruktúra projektu a správa závislostí cez Composer) a Trellis použiť na deployment. 1. Založ projekt s [Bedrock](https://roots.io/bedrock/). 2. Nainštaluj a nakonfiguruj [Trellis](https://roots.io/trellis/) pre svoj server/prostredie. 3. V `wordpress_sites.yml` nastav Git repozitár a deployment parametre. 4. Spusť deploy (napr. `trellis deploy production`). Prvý deploy býva pomalší, lebo sa pripravuje adresárová štruktúra a sťahujú sa závislosti. Ďalšie nasadenia sú už rýchlejšie – a hlavne bez okna, v ktorom by bol web v nekonzistentnom stave. #### Praktická poznámka Trellis vieš použiť aj na servery, ktoré neboli provisionované cez Trellis. A rovnako ho vieš používať iba na deployment, zatiaľ čo lokálne ostaneš na nástroji, ktorý ti sedí. ## Zhrnutie: čo si z Trellis atomic deployov reálne odnáša WordPress tím - Web počas deployu neprejde do medzistavu so zmiešanými súbormi. - Každý deploy je nový, izolovaný release (immutable prístup). - Rollback je rýchly, lebo ide primárne o prehodenie `current` symlinku. - Proces sa dá rozširovať cez deploy hooks. - Databázové migrácie treba riešiť vedome (napr. cez Acorn migrations), nie spoliehať sa, že sa „nejako“ stanú. ## Referencie / Zdroje - [Zero Downtime WordPress Deployments with Trellis](https://roots.io/zero-downtime-wordpress-deployments-with-trellis/) - [Trellis deployments documentation](https://roots.io/trellis/docs/deployments/) - [Bedrock](https://roots.io/bedrock/) - [Trellis](https://roots.io/trellis/) - [Creating and running Laravel migrations (Acorn)](https://roots.io/acorn/docs/creating-and-running-laravel-migrations/)