Zero downtime WordPress deploy Trellis-szel: atomikus kiadás, azonnali rollback

Ha WordPress-t üzemeltetsz, valószínűleg találkoztál már azzal a kellemetlen jelenséggel, amikor egy frissítés alatt a site pár percre „furcsán” viselkedik: admin oldalak 500-at dobnak, a frontenden hiányzik egy asset, vagy egyszerűen csak valami nem kompatibilis félállapotban töltődik be. Ez tipikusan nem (csak) WordPress-probléma, hanem deployment (telepítési/kitelepítési folyamat) probléma.

A Trellis (a Roots eszközkészlet része) erre ad egy modern, alkalmazásfejlesztésben bevett választ: zero downtime deploymentet (leállás nélküli telepítést) atomikus kiadáskezeléssel. A jó hír, hogy a Trellis-t nem muszáj a teljes fejlesztői workflow-dhoz hozzáadni: sokan kifejezetten csak deployolásra használják Bedrock-alapú projektekhez, miközben lokálban marad a megszokott környezet (Valet, Lando, DDEV, stb.).

Mit jelent a „zero downtime” deploy a gyakorlatban?

Zero downtime deploynál a weboldal a telepítés teljes ideje alatt kiszolgálható és működőképes marad. A trükk nem az, hogy „nagyon gyorsan másolunk fel fájlokat”, hanem az, hogy nincs olyan köztes állapot, amikor a látogatók egyszerre kapnak régi és új fájlokat.

A hagyományos WordPress deploynál gyakori, hogy a frissített fájlok helyben felülíródnak. Ez feltűnés nélkül is okozhat hibákat: egy új PHP osztály már fent van, de a hozzá tartozó autoload még régi; egy új JS bundle már betölt, de a hozzá tartozó CSS még nem; vagy pont fordítva. A végeredmény random hibák a deploy ablaka alatt.

Miért problémás a „klasszikus” WordPress deploy?

A legtöbb WordPress telepítés valamilyen, fájlokat helyben módosító módszerrel megy élesbe. Tipikus minták:

• FTP feltöltés: manuálisan felülírod a változott fájlokat. Lassú, és amíg tart, a site könnyen kevert állapotban fut.
• Fájlszinkron (pl. rsync): gyorsabb, de alapvetően ugyanazt csinálja: élőben írja át a fájlokat.
• Host által adott bővítményes deploy: kényelmes, de sok esetben szintén in-place frissít, és rollback (visszagörgetés) nélkül kockázatos.

A közös nevező: deploy közben el tud romlani a site, és ha gond van, gyakran nincs egy gombnyomásos visszaút. Legjobb esetben is „gyorsan visszatöltöd” a régit, ami stresszes és hibalehetőségekkel teli.

A Trellis megoldása: atomikus (és immutábilis) deploy

A Trellis atomikus deploy-stratégiát használ: az új verzió külön könyvtárba kerül felépítésre, a futó verziót pedig nem piszkálja. Amikor minden kész, a váltás egyetlen lépés: a webszerver által használt current symlink átmutat az új kiadásra.

Ez a megközelítés immutábilis is: egy már kitelepített kiadás fájljait nem módosítja helyben. Minden deploy egy új, önálló release könyvtár.

Milyen könyvtárstruktúrát hoz létre?

/srv/www/example.com/
├── current/             # Symlink az aktív release-re
├── releases/            # Minden kitelepített kiadás
│   ├── 20250930124530/
│   ├── 20250930083045/
│   └── 20250930141622/  # Legfrissebb
├── shared/              # Megosztott erőforrások a release-ek között
│   └── uploads/
└── logs/

/srv/www/example.com/
├── current/             # Symlink az aktív release-re
├── releases/            # Minden kitelepített kiadás
│   ├── 20250930124530/
│   ├── 20250930083045/
│   └── 20250930141622/  # Legfrissebb
├── shared/              # Megosztott erőforrások a release-ek között
│   └── uploads/
└── logs/

A lényeg a current: a webszerver mindig innen szolgál ki, de ez valójában csak egy symlink valamelyik releases/... könyvtárra. A váltás így atomi művelet: egyik pillanatban a régi release-re mutat, a következő pillanatban az újra.

Mi történik egy trellis deploy production során?

A Trellis a deployt több, jól elkülöníthető lépésben futtatja le. Nagyjából ez a folyamat:

1. Inicializálás: ellenőrzi/létrehozza a szükséges könyvtárakat, és létrehoz egy új release mappát időbélyeggel (pl. 20250930141622).
2. Update: a legfrissebb kódot a Git repository-ból egy ideiglenes forráskönyvtárba klónozza (nem a live kód fölé).
3. Prepare: a forrásból átmásolja az anyagot az új release mappába.
4. Build: lefuttatja a composer install-t, hogy a függőségek letöltődjenek.
5. Share: a megosztott erőforrásokat (például feltöltések) a shared könyvtárból symlinkeli be az új release-be.
6. Finalize: frissíti a current symlinkelést az új release-re.

A kritikus rész az, hogy a felhasználók nem találkoznak „félkész” állapottal: a váltás a current symlink cseréje, ami gyakorlatilag azonnali.

Adatbázis: a deploytól független kérdés

Fontos korlát: a Trellis a kódbázis zero downtime kitelepítését oldja meg. Az adatbázis-séma módosítás (migráció) külön téma, és a Trellis dokumentációja is jelzi, hogy a database migrations nem része a Trellis deploynak.

Ha Acorn-t használsz (Roots-projekt, ami Laravel-szerű keretet ad WordPress mellé), akkor lehetőséged van Laravel migration-öket készíteni WordPress projekthez, és gondoskodni arról, hogy ezek a deploy folyamat részeként lefussanak.

Azonnali rollback: a legnagyobb stresszcsökkentő feature

Az atomikus/immutábilis modell egyik legnagyobb előnye a gyors visszagörgetés. Mivel minden release teljes, érintetlen mappában él, rollback esetén csak a symlinket kell egy korábbi kiadásra visszaállítani:

trellis rollback production

trellis rollback production

Alapértelmezetten a Trellis az öt legutóbbi release-t megtartja a szerveren, így általában van mihez visszanyúlni, ha egy frissítés után derül ki valami kellemetlen.

Deploy hookok: testreszabás a kritikus pontokon

A Trellis deployja nem fekete doboz: több hookot (beakasztható pontot) ad, amelyekkel a folyamat egyes lépései elé vagy mögé tudsz saját feladatokat rakni. Példák:

• deploy_build_before és deploy_build_after: extra build lépésekhez
• deploy_finalize_before és deploy_finalize_after: élesítés előtti/utáni feladatokhoz
• Hookok a fő deploy fázisokhoz: initialize, update, prepare, build, share, finalize

Ezekkel olyan mintákat lehet kulturáltan megvalósítani, mint például deploy előtti adatbázis-mentés, cache ürítés a váltás után, értesítések küldése, vagy akár smoke testek futtatása a frissen elkészült release ellen.

Hogyan indulj el (minimum lépések)?

A Trellis-es zero downtime deploy tipikusan Bedrock-alapú projektre épül (a Bedrock a Roots modernebb WordPress projektstruktúrája). A bejelentés szerinti alapfolyamat:

1. Állítsd be a projektet Bedrock-kal.
2. Telepítsd a Trellis-t, és konfiguráld a deploy beállításokat.
3. A wordpress_sites.yml fájlban add meg a Git repository információit.
4. Futtasd: trellis deploy production.

Az első deploy jellemzően lassabb, mert ekkor épül fel a könyvtárstruktúra és kerülnek fel a függőségek. A további deployok gyorsabbak, és a lényeg: a kódváltás közben nem kell a látogatók által tapasztalt hibákkal számolni.

Plusz praktikus opció: ha nem akarsz mindent Trellis-szel megoldani, használhatod kizárólag kitelepítésre is, miközben a lokális fejlesztés megmarad a saját eszközeiddel, és akár olyan szerverre is deployolhatsz, amit nem Trellis-szel provisionáltál.

Összefoglaló: mikor éri meg Trellis-szel atomikus deployra váltani?

• Ha fontos, hogy deploy közben se lássanak hibát a felhasználók (nincs kevert fájlállapot).
• Ha kell egy biztos, gyors rollback lehetőség pánik nélkül.
• Ha szeretnél modernebb release-kezelést WordPress-hez is, a megszokott appos minták mentén.
• Ha Bedrock-ot használsz (vagy tervezel), és Git-alapú deployban gondolkodsz.