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/

/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 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.
2. Nainštaluj a nakonfiguruj 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.

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ú.