Zero-downtime deployment za WordPress s Trellisom: kako rade atomic releaseovi i rollback

U modernom web developmentu je normalno očekivati da deploy ne prekida aplikaciju. U WordPress svijetu to i dalje često izgleda kao “uploadaj nove fajlove pa se moli da sve prođe”. Roots Trellis tu donosi pristup koji je bliži onome što rade ozbiljni app deploy pipelineovi: atomic deployments (atomski deploy), uz immutable releases (nepromjenjive verzije) i brzi rollback.

Bitno: Trellis ne moraš koristiti za cijeli workflow. Puno timova ga koristi samo za deployment Bedrock projekta na razne hosting okoline (uključujući managed hostove), dok lokalno rade u okruženju koje im već paše (Valet, Lando, DDEV…).

Što “zero downtime deployment” stvarno znači u praksi

Zero downtime deployment znači da je web u cijelom procesu deploya i dalje funkcionalan i dostupan. Nema perioda u kojem server poslužuje mješavinu stare i nove verzije koda, niti trenutaka kad su neke datoteke već prepisane, a neke još nisu stigle.

Ključna ideja je izolirana priprema nove verzije i onda trenutno prebacivanje na nju (bez postupnog prepisivanja live fajlova).

Zašto su klasični WordPress deployi rizični

Najčešći načini kako se WordPress i dalje deploya na produkciju imaju isti temeljni problem: ažuriranje ide “in-place” dok je site live.

• FTP upload: ručno prebacivanje i prepisivanje fajlova. Kako upload traje, produkcija može posluživati polu-staro/polu-novo stanje, što često rezultira greškama.
• rsync / file sync alati: brže od FTP-a, ali i dalje radiš prepisivanje postojećih fajlova dok korisnici surfaju.
• plugin-based deployment na managed hostovima: zgodno za kliknuti, ali često bez pravog rollback mehanizma i opet s in-place updateom.

Rezultat: deployment prozor u kojem se mogu pojaviti 500 greške, fatal errori, missing class, nedostajuće asset datoteke ili napuknuti cache. A kad nešto krene po zlu, vraćanje na staro zna biti sporo i ručno.

Kako Trellis radi atomic deployment (atomski deploy)

Trellis preuzima provjereni obrazac iz svijeta aplikacija: svaka verzija se deploya u novi release direktorij, potpuno odvojeno od aktivne verzije. Tek kad je sve spremno (kod, dependencyji, symlinkovi), Trellis jednim potezom prebaci web na novu verziju.

Struktura direktorija na serveru

Kod Trellisa je najvažniji detalj current — to je symlink (simbolička poveznica) na release koji je trenutno aktivan. Web server uvijek poslužuje iz current, a current se samo preusmjeri na novu verziju.

/srv/www/example.com/
├── current/             # Symlink na aktivni release
├── releases/            # Svi deployani releaseovi
│   ├── 20250930124530/
│   ├── 20250930083045/
│   └── 20250930141622/  # Najnoviji
├── shared/              # Dijeljeni fajlovi između releaseova
│   └── uploads/
└── logs/

/srv/www/example.com/
├── current/             # Symlink na aktivni release
├── releases/            # Svi deployani releaseovi
│   ├── 20250930124530/
│   ├── 20250930083045/
│   └── 20250930141622/  # Najnoviji
├── shared/              # Dijeljeni fajlovi između releaseova
│   └── uploads/
└── logs/

Što se dogodi kad pokreneš deploy

Kad izvršiš trellis deploy production, Trellis odradi deployment u više faza, ali bez diranja live releasea do samog kraja:

• Initialize: provjera/kreiranje strukture direktorija i otvaranje novog release direktorija (timestamp).
• Update: kloniranje najnovijeg koda iz Git repozitorija u odvojeni source direktorij (izvan live patha).
• Prepare: kopiranje pripremljenih datoteka u novi release direktorij.
• Build: pokretanje composer install za dependencyje.
• Share: symlinkanje dijeljenih direktorija/fajlova (npr. media uploads) iz shared u novi release.
• Finalize: prebacivanje current symlinka na novi release.

Efekt je jednostavan: u jednom trenutku web servira releases/…stari…, a odmah nakon toga releases/…novi…. Nema “međustanja” i nema prepisivanja fajlova koje korisnici mogu uhvatiti usred requesta.

Baza podataka: deploy koda nije isto što i migracije

Ovdje treba biti realan: Trellis rješava zero downtime za kod i filesystem, ali promjene sheme baze (migracije) su zasebna tema. Prema dokumentaciji Trellisa, migracije baze nisu automatski dio Trellis deploya.

Ako koristiš Acorn, možeš raditi migracije na Laravel način (Laravel migrations) i ugraditi njihovo izvođenje u deployment proces. To je često najčišći put ako želiš disciplinirano verzioniranje promjena u bazi, ali zahtijeva da migracije pišeš “production-safe” (npr. kompatibilnost unazad dok traje rollout).

Rollback u par sekundi (i zašto je to velika stvar)

Atomic + immutable releaseovi znače da se release nakon deploya više ne mijenja. Ako nova verzija napravi problem, rollback je samo prebacivanje symlinka natrag na prethodni release.

trellis rollback production

trellis rollback production

Po defaultu Trellis na serveru zadržava zadnjih pet releaseova, što je obično dovoljno da se brzo vratiš na stabilnu verziju bez ikakvog “kopiraj nazad fajlove” scenarija.

Deploy hookovi: gdje ubaciti svoje korake

Trellis ima hookove (točke proširenja) za prilagodbu deployment flowa. Praktično: možeš dodati vlastite korake bez forkanja deploy logike.

• deploy_build_before i deploy_build_after za custom build korake.
• deploy_finalize_before i deploy_finalize_after za pre/post switch zadatke.
• Hookovi postoje i po fazama (initialize, update, prepare, build, share, finalize).

To otvara tipične obrasce iz “pravog” DevOpsa: backup baze prije deploya, čišćenje cachea nakon switcha, slanje notifikacija timu, ili pokretanje smoke testova na novom releaseu.

Kako krenuti (minimalni put do prvog zero-downtime deploya)

Ako ti je cilj samo dobiti stabilniji deployment bez prekida rada, najkraći put izgleda ovako:

1. Postavi projekt na Bedrock strukturu (uređeniji WordPress projekt, Composer-first).
2. Instaliraj i konfiguriraj Trellis za deployment postavke.
3. U wordpress_sites.yml upiši podatke o repozitoriju i target environmentu.
4. Pokreni trellis deploy production.