---
title: "Zero-downtime deployment za WordPress s Trellisom: kako rade atomic releaseovi i rollback"
url: "https://helloblog.io/hr/zero-downtime-wordpress-deployment-trellis-atomic-rollback/"
date: "2025-10-02"
modified: "2026-01-20"
author: "Ivana Babić"
language: "hr_HR"
categories: ["WordPress ekosustav"]
tags: ["Bedrock", "Deploy", "DevOps", "Trellis", "WordPress"]
featured_image: "https://helloblog.io/app/uploads/sites/22/2026/01/featured-2-1024x572.png"
excerpt: "Ako si ikad deployao WordPress preko FTP-a i nadao se da korisnici baš tada neće klikati, Trellisov atomic deployment model rješava taj stres: nova verzija se pripremi odvojeno, a prebacivanje je trenutno."
---

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

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

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](https://roots.io/bedrock/) strukturu (uređeniji WordPress projekt, Composer-first).
2. Instaliraj i konfiguriraj [Trellis](https://roots.io/trellis/) za deployment postavke.
3. U `wordpress_sites.yml` upiši podatke o repozitoriju i target environmentu.
4. Pokreni `trellis deploy production`.

#### Napomena o prvom deployu

Prvi deploy tipično traje dulje jer se inicijalno postavlja struktura direktorija i povlače dependencyji. Kasniji deployevi su brži — i najvažnije, bez prekida rada.

## Reference / Izvori

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