Zero-downtime deployment pro WordPress s Trellis: atomicky, bez stresu a s rollbackem

V moderním vývoji aplikací je samozřejmost, že nasazení nové verze neznamená několik minut „přechodového stavu“, kdy produkce servíruje napůl starý a napůl nový kód. U WordPressu je tohle bohužel pořád běžný scénář — a často to končí rozbitým frontendem, fatálními errory nebo tím, že se uživatelům zrovna při nasazení nenačte košík, formulář nebo administrace.

Trellis (součást ekosystému Roots) jde na deployment stejně jako moderní aplikační stacky: atomicky (přepnutí proběhne najednou) a immutably (nasazený release se už nikdy „nepřepisuje“). Výsledek je tzv. zero downtime deployment — web je dostupný a funkční po celou dobu nasazení.

Co přesně znamená „zero downtime deployment“

V kontextu WordPressu tím obvykle myslíme to, že během nasazování nedojde k období, kdy se na serveru míchají staré a nové soubory. Tradiční nasazení často probíhá tak, že se za běhu přepisuje část PHP souborů, šablon nebo assetů — a web mezitím obsluhuje požadavky. Pokud už v tu chvíli nový kód očekává novou strukturu souborů nebo nové dependency, je zaděláno na chybu.

Atomický deployment tento mezistav eliminuje: nový release se kompletně připraví mimo živou verzi a teprve až je hotový, provede se rychlý přepínač (typicky symlink).

Proč jsou „běžné“ WordPress deploye problematické

Nejčastější způsoby nasazení WordPressu mají společný rys: aktualizují soubory přímo na místě (in-place). To je přesně ten okamžik, kdy se může produkce rozbít.

• FTP uploady: ručně přepíšeš změněné soubory; web může několik minut servírovat mix starého a nového.
• Synchronizace (např. rsync): rychlejší než FTP, ale princip je stejný — za běhu přepisuješ soubory, které web právě používá.
• Pluginové deploye na managed hostingu: pohodlné, ale často pořád jde o in-place update bez skutečně spolehlivého rollbacku.

Když se něco pokazí, bývá problém nejen samotná chyba, ale i návrat zpět: často neexistuje jednoduchý rollback, nebo je rollback ruční a pomalý.

Jak to Trellis řeší: atomické a „immutable“ releasy

Trellis používá strategii, kdy každé nasazení vytvoří nový release adresář. Ten se připraví celý bokem (checkout z Gitu, instalace závislostí přes Composer, propojení sdílených dat) a až nakonec dojde k okamžitému přepnutí.

Adresářová struktura na serveru

Na cílovém serveru se typicky vytvoří struktura, kde webserver obsluhuje vždy obsah z current/, které je jen symlink na konkrétní release ve releases/.

/srv/www/example.com/
├── current/             # Symlink na aktivní release
├── releases/            # Historie releaseů
│   ├── 20250930124530/
│   ├── 20250930083045/
│   └── 20250930141622/  # Nejnovější
├── shared/              # Sdílená data napříč releasy
│   └── uploads/
└── logs/

/srv/www/example.com/
├── current/             # Symlink na aktivní release
├── releases/            # Historie releaseů
│   ├── 20250930124530/
│   ├── 20250930083045/
│   └── 20250930141622/  # Nejnovější
├── shared/              # Sdílená data napříč releasy
│   └── uploads/
└── logs/

Klíčová je složka shared/: sem patří věci, které nesmí zmizet s releasem — typicky uploads (nahraná média). Každý release si pak do sebe jen „připojí“ (symlink) sdílené adresáře.

Co se děje při trellis deploy production

Z pohledu vývojáře jde o jeden příkaz, ale Trellis v pozadí provede několik kroků tak, aby live verze zůstala nedotčená až do poslední chvíle.

1. Initialize: ověří existenci struktury a vytvoří nový release adresář s timestampem.
2. Update: stáhne aktuální kód z Git repozitáře do separátního dočasného místa mimo live web.
3. Prepare: připraví obsah releasu (kopírování do nového release adresáře).
4. Build: spustí composer install a doinstaluje dependency.
5. Share: připojí sdílené soubory/adresáře ze shared/ do releasu (např. uploads).
6. Finalize: přepne symlink current na nový release.

To „kouzlo“ je právě ve finálním kroku: v jeden okamžik web servíruje starý release, v další milisekundě už nový. Bez přepisování souborů za běhu.

Databáze: kód bez výpadku neznamená automaticky bezrizikové migrace

Je fér říct nahlas jednu věc: Trellis řeší zero downtime pro souborovou část (kód, šablony, závislosti). Databázové migrace jsou samostatné téma — a podle dokumentace Trellis nejsou součástí samotného deploy procesu.

Pokud používáš Acorn (framework z Roots, který přináší do WordPressu část Laravel ergonomie), můžeš migrace řešit přes Laravel migrations a zajistit jejich spouštění jako součást nasazení. V praxi to typicky znamená i přemýšlet nad kompatibilitou schématu: ideálně dělat změny tak, aby starý i nový kód krátce přežily paralelně (tzv. backward-compatible migrace).

Rollback je v Trellis otázka jednoho příkazu

Atomický a immutable přístup má jeden zásadní bonus: rollback neznamená „vrátit soubory“, ale prostě přepnout symlink current zpět na předchozí release. To je rychlé a dobře predikovatelné.

trellis rollback production

trellis rollback production

Standardně se na serveru drží několik posledních releaseů (v základu pět), takže návrat zpět není závislý na tom, jestli máš někde po ruce zip, backup nebo štěstí.

Deploy hooks: jak do nasazení přidat vlastní kroky

Trellis má hooky (body v procesu, kde se dá spustit vlastní logika) pro různé fáze deploye. Hodí se, když potřebuješ nasazení doplnit o konkrétní provozní kroky bez toho, aby ses vzdal atomického modelu.

• deploy_build_before a deploy_build_after pro vlastní build kroky
• deploy_finalize_before a deploy_finalize_after pro úlohy těsně před/po přepnutí
• Hooky i pro jednotlivé hlavní fáze: initialize, update, prepare, build, share, finalize

Typické použití v praxi: záloha databáze před nasazením, pročištění cache po nasazení, posílání notifikací týmu nebo jednoduché smoke testy proti novému releasu ještě předtím, než se přepne current.

Jak začít: minimum kroků, maximum efektu

Pokud chceš Trellis využít čistě pro spolehlivější nasazování, typický postup vypadá takto:

1. Postav projekt na Bedrocku (čistší struktura WordPress projektu a dependency přes Composer).
2. Nainstaluj Trellis a nastav deployment konfiguraci.
3. Doplň wordpress_sites.yml o informace o Git repozitáři.
4. Spusť trellis deploy production.

První deploy bývá pomalejší (vytvoření struktury, stažení závislostí). Další nasazení už jsou obvykle rychlá — a hlavně bez toho nepříjemného momentu, kdy si nejsi jistý, jestli se zrovna někomu nerozbila produkce uprostřed kopírování souborů.

Shrnutí: proč to dává smysl i u menších WordPress projektů

• Žádné přepisování souborů za běhu → méně náhodných chyb při deployi.
• Každý release je izolovaný a neměnný → lépe se diagnostikuje, co je nasazeno.
• Okamžitý rollback → menší stres, rychlejší reakce na incident.
• Hooky → možnost doplnit deployment o provozní hygienu (cache, backupy, notifikace).