Zero downtime deploy za WordPress s Trellis: atomarni releasi brez panike

V modernem razvoju aplikacij je samoumevno, da novi release na produkciji ne sme prekiniti delovanja. Pri WordPress projektih pa se še vedno pogosto dogaja ravno to: datoteke se prepisujejo “v živo”, uporabniki vmes zadenejo čuden miks stare in nove kode, rezultat pa so napake, prazne strani ali nedelujoči admini.

Trellis (del ekosistema Roots) ima to težavo rešeno zelo elegantno: uporablja atomarne deploye (atomic deployments), kjer se nova verzija pripravi ločeno od live strani, nato pa se na koncu v trenutku preklopi. To pomeni zero downtime za kodo – in v praksi precej manj stresa pri vsakem deployu.

Kaj v praksi pomeni “zero downtime” pri deployu

Zero downtime deploy pomeni, da je spletna stran za obiskovalce ves čas dosegljiva in funkcionalna. Ključna razlika do klasičnega WordPress deploya je, da se obstoječe datoteke ne prepisujejo postopoma. Namesto tega se celoten novi release pripravi v izolaciji, šele nato se naredi instant preklop.

Pri tradicionalnem pristopu (FTP, rsync ali “deployment” prek vtičnika) se pogosto zgodi, da med nalaganjem del kode že kaže na novo stanje, del pa je še star. WordPress je občutljiv na takšne vmesne faze: dovolj je, da se plugin posodobi, tema pa še ne, ali obratno, in dobimo napake, ki jih je težko reproducirati.

Zakaj so klasični WordPress deployi problematični

• FTP upload: ročno prepisovanje datotek. Časovno potratno, med prenosom pa strežnik servira mešanico starega in novega.
• Sinhronizacija datotek (npr. rsync): hitrejše, ampak konceptualno enak problem – datoteke se še vedno prepisujejo na live sistemu.
• Deploy prek vtičnika na managed hostingu: udobno, a pogosto brez pravega rollback mehanizma in še vedno z “in-place” posodobitvami.

Skupni imenovalec: med deployem je možno, da stran za kratek čas deluje napačno, in če gre kaj narobe, je vračanje na prejšnje stanje zamudno (ali pa sploh ni jasno, kaj točno je treba povrniti).

Kako Trellis to reši: atomarni in nespremenljivi releasi

Trellis uporabi pristop, ki je v drugih ekosistemih standard: vsak deploy ustvari nov, popoln release direktorij, ki se po koncu deploya nikoli več ne spreminja (immutable release). Live promet pa vedno gleda v mapo current, ki je v resnici samo simbolna povezava (symlink) do aktivnega release direktorija.

Tipična struktura direktorijev na strežniku

/srv/www/example.com/
├── current/             # symlink do aktivnega releasa
├── releases/            # vsi deployani releasi
│   ├── 20250930124530/
│   ├── 20250930083045/
│   └── 20250930141622/  # najnovejši
├── shared/              # deljene datoteke med releasi
│   └── uploads/
└── logs/

/srv/www/example.com/
├── current/             # symlink do aktivnega releasa
├── releases/            # vsi deployani releasi
│   ├── 20250930124530/
│   ├── 20250930083045/
│   └── 20250930141622/  # najnovejši
├── shared/              # deljene datoteke med releasi
│   └── uploads/
└── logs/

Web server je nastavljen tako, da servira iz current. Ko je nov release pripravljen, Trellis samo preusmeri current symlink na novo mapo. Preklop je praktično takojšen, brez vmesne faze prepisovanja datotek.

Kaj se zgodi ob trellis deploy production

Trellis deploy je sestavljen iz več jasnih korakov. Pomembno je, da se “nevarni” del (priprava nove kode in dependencyjev) izvaja ločeno od live direktorija:

1. Initialize: preveri/ustvari strukturo map in pripravi nov release direktorij z timestamp imenom.
2. Update: iz Git repozitorija pridobi najnovejšo kodo v ločen prostor (ne v live mapo).
3. Prepare: pripravi release direktorij za novo verzijo.
4. Build: zažene composer install in s tem postavi PHP odvisnosti.
5. Share: v novi release se povežejo deljeni direktoriji/datoteke (npr. uploads) iz shared.
6. Finalize: posodobi current symlink, da kaže na nov release.

V enem trenutku produkcija še kaže na prejšnji release, v naslednjem pa na novega. Ker preklop ni postopen, uporabniki ne morejo ujeti “polovičnega” stanja aplikacije.

Baza ni del “zero downtime” čarovnije (in to je pomembno)

Trellis z atomarnim deployem poskrbi za kodo in datotečni sistem. Spremembe sheme baze (migracije) pa so ločena tema. V dokumentaciji Trellis je izrecno navedeno, da migracije baze niso samodejni del deploy procesa.

Če uporabljaš Acorn (Rootsov sloj, ki v WordPress projekte pripelje Laravel koncepte), lahko migracije vodiš kot Laravel migrations in jih po potrebi vključiš v deploy proces. Ključ je v tem, da migracije načrtuješ tako, da so kompatibilne z “rolling” prehodom med staro in novo kodo (npr. najprej dodaj stolpec, šele potem ga začni obvezno uporabljati).

Rollback: največja praktična zmaga atomarnega deploya

Ker vsak release obstaja kot samostojen direktorij in se po deployu ne spreminja, je rollback trivialen: samo preusmeriš current symlink na prejšnji release. Trellis ima za to vgrajen ukaz:

trellis rollback production

trellis rollback production

Po privzetih nastavitvah Trellis na strežniku obdrži nekaj zadnjih releaseov (v izvoru je navedeno pet). To pomeni, da se lahko v nekaj sekundah vrneš na delujočo verzijo, brez ročnega kopiranja datotek ali iskanja “kaj je šlo na server”.

Deploy hooks: ko rabiš nekaj več kot “samo” deploy

Trellis vključuje hooks (to so točke v procesu deploya, kjer lahko dodaš svoje korake), npr. pred ali po buildu ter pred ali po finalizaciji. To omogoča, da deploy prilagodiš svojemu stacku in hostingu, brez hackanja jedra Trellis-a.

• deploy_build_before / deploy_build_after: dodatni build koraki (npr. kompilacija assetov, dodatni dependency check).
• deploy_finalize_before / deploy_finalize_after: opravila tik pred preklopom ali takoj po njem.
• Hooks po posameznih fazah (initialize, update, prepare, build, share, finalize): ko želiš fino kontrolo nad flowom.

Tipični primeri v praksi: pred deployem narediti backup baze, po deployu počistiti cache, poslati obvestilo ekipi ali zagnati osnovni smoke test proti novi verziji.

Kako začeti, če Trellis še ne uporabljaš

Za Trellis zero downtime deploy ti ni nujno, da z njim vodiš celoten lokalni razvojni workflow. Veliko ekip ga uporablja predvsem kot deployment orodje za Bedrock projekte, lokalno pa ostanejo pri svojem okolju (npr. Valet, Lando, DDEV ipd.). Po opisu v izvoru je osnovni “happy path” takle:

1. Projekt strukturiraj z Bedrock (bolj predvidljiva struktura, Composer-first pristop).
2. Namesti in konfiguriraj Trellis ter deployment nastavitve.
3. V wordpress_sites.yml nastavi podatke o Git repozitoriju.
4. Zaženi deploy z trellis deploy production.

Povzetek

Trellis s atomarnimi (atomic) in nespremenljivimi (immutable) releasi pripelje v WordPress svet deployment vzorec, ki ga v drugih okoljih jemljemo kot standard. Največji praktični koristi sta dve: med deployem ne serviraš mešanice starih in novih datotek, in če gre kaj narobe, je rollback hiter in enostaven. Pri vsem tem pa ostaja pomembno, da spremembe baze obravnavaš ločeno in jih načrtuješ premišljeno.