---
title: "Zero downtime WordPress deploy Trellis-szel: atomikus kiadás, azonnali rollback"
url: "https://helloblog.io/hu/zero-downtime-wordpress-deploy-trellis/"
date: "2025-10-02"
modified: "2026-01-20"
author: "Kovács Anna"
language: "hu_HU"
categories: ["WordPress ökoszisztéma"]
tags: ["Bedrock", "Deploy", "DevOps", "Trellis", "WordPress"]
featured_image: "https://helloblog.io/app/uploads/sites/2/2026/01/featured-3-1024x572.png"
excerpt: "A klasszikus WordPress deploy (FTP, rsync, hostos bővítmény) gyakran azt jelenti, hogy élesben „félúton” áll a kód, és a látogatók hibákat látnak. A Trellis atomikus deploy-stratégiája ezt úgy kerüli el, hogy a teljes új kiadást izoláltan készíti elő, majd egyetlen symlink-cserével vált."
---

# 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/
```

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.

#### Gyakorlati megfontolás

Zero downtime kódváltás mellett is lehet „downtime-szerű” hatása egy rosszul időzített vagy nem kompatibilis adatbázis-migrációnak. A kód- és DB-változások visszafelé kompatibilitása kulcskérdés.

## 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
```

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.

## Hivatkozások / Források

- [Zero Downtime WordPress Deployments with Trellis](https://roots.io/zero-downtime-wordpress-deployments-with-trellis/)
- [Deployments | Trellis Documentation](https://roots.io/trellis/docs/deployments/)
- [Creating and running Laravel migrations | Acorn Documentation](https://roots.io/acorn/docs/creating-and-running-laravel-migrations/)
- [Bedrock](https://roots.io/bedrock/)
- [Trellis](https://roots.io/trellis/)