Zero downtime WordPress diegimai su Trellis: atominių release’ų praktika

WordPress pasaulyje vis dar labai dažnai matau „klasikinį“ diegimą: įkeli kelis failus per FTP, arba paleidi rsync, arba pasitiki hostingo įskiepiu, kuris „kažką atnaujina“. Kol procesas vyksta, svetainė aptarnauja mišrų senų ir naujų failų rinkinį — ir būtent čia prasideda atsitiktinės 500 klaidos, trūkstami asset’ai, neveikiantys PHP include’ai ir panašūs siurprizai.

Trellis (Roots infrastruktūros įrankis, paremtas Ansible automatizacija) siūlo tai, kas moderniuose web’app projektuose jau seniai norma: zero downtime diegimus, paremtus atominiu release’ų perjungimu. Svarbiausia: Trellis gali būti naudojamas vien diegimui, net jei lokaliai dirbi su Lando, DDEV, Valet ar kitu įprastu setup’u.

Kas iš tikro yra „zero downtime“ diegimas?

„Zero downtime“ reiškia, kad diegimo metu svetainė išlieka pilnai pasiekiama ir funkcionali. Nėra intervalo, kai vartotojai pataiko į pusiau atnaujintą būseną (pvz., naujas šablonas jau įkeltas, bet dar neatkeliavo nauji JS failai, arba atvirkščiai).

Tai pasiekiama ne „greitesniu upload’u“, o atomine strategija: nauja versija paruošiama izoliuotai, o tada viena operacija perjungiama į ją. Praktikoje tai dažniausiai yra symlink’o perstatymas.

Kodėl tradicinis WordPress diegimas lūžta (net jei „atrodo veikia“)?

Dažniausi scenarijai:

• FTP įkėlimas: kol keli failus, svetainė gyvai aptarnauja dalį senų ir dalį naujų failų. Jei užtrunka kelias minutes — vartotojai tikrai pataikys į nekonsistentišką būseną.
• Failų sinchronizacija (pvz., rsync): greičiau nei FTP, bet problema ta pati — failai perrašomi „in-place“, kai sistema veikia.
• Hostingo/įskiepio diegimas: patogu, bet dažnai be tikro rollback’o ir su tais pačiais „in-place update“ minusais.

Bendra šių metodų bėda: nėra aiškios izoliacijos tarp „seno“ ir „naujo“, rollback dažniausiai reiškia rankinį failų perkopijavimą, o diegimo langas realiai matomas lankytojams.

Kaip Trellis daro atominius (immutable) diegimus?

Trellis diegimo modelis paremtas dviem idėjomis:

• Atomic: perjungimas į naują release’ą įvyksta momentiškai (vienu veiksmu).
• Immutable: release direktorijos po diegimo neberedaguojamos. Kiekvienas diegimas sukuria naują atskirą katalogą.

Serverio direktorijų struktūra: kur slypi „magija“

Tipinė struktūra, kurią Trellis sukuria deploy’inant projektą:

/srv/www/example.com/
├── current/             # Symlink į aktyvų release
├── releases/            # Visi išdiegti release’ai
│   ├── 20250930124530/
│   ├── 20250930083045/
│   └── 20250930141622/  # Naujausias
├── shared/              # Bendri failai per release’us
│   └── uploads/
└── logs/

/srv/www/example.com/
├── current/             # Symlink į aktyvų release
├── releases/            # Visi išdiegti release’ai
│   ├── 20250930124530/
│   ├── 20250930083045/
│   └── 20250930141622/  # Naujausias
├── shared/              # Bendri failai per release’us
│   └── uploads/
└── logs/

Web serveris (Nginx/Apache) visada aptarnauja turinį iš current/. Bet current/ nėra „tikras katalogas“ — tai symlink, rodantis į vieną iš releases/... direktorijų. Todėl perjungimas tarp versijų yra tiesiog symlink’o perstatymas.

Kas vyksta paleidus trellis deploy production?

Aukštu lygiu, Trellis daro tokį pipeline’ą (pavadinimai gali skambėti pažįstamai iš CI/CD):

1. Initialize: patikrina/sukuria reikalingą struktūrą, sukuria naują release katalogą su timestamp’u (pvz., 20250930141622).
2. Update: klonuoja naujausią kodą iš Git repo į laikiną vietą, atskirai nuo live svetainės.
3. Prepare: paruoštą kodą nukopijuoja į naujo release direktoriją.
4. Build: paleidžia composer install (priklausomybės atsisiunčiamos ir sudedamos į release).
5. Share: bendri katalogai (pvz., media upload’ai) prijungiami per symlink’us iš shared/ į naują release.
6. Finalize: atnaujina current symlink’ą į naują release.

Svarbiausia vieta: iki Finalize momento realūs vartotojai vis dar mato seną release’ą. O perjungimas į naują įvyksta akimirksniu — nėra „tarpinės“ būsenos.

Duomenų bazė: ko Trellis sąmoningai nedaro už tave

Trellis puikiai sutvarko kodo diegimą be prastovų, bet DB schema ir migracijos yra atskiras klausimas. Trellis dokumentacijoje aiškiai pasakoma, kad database migrations į deploy procesą nėra įtrauktos.

Jei projekte naudoji Acorn (Roots įrankį, kuris į WordPress atneša Laravel komponentus), gali naudoti Laravel migracijas ir jas įtraukti į diegimo eigą kaip atskirą žingsnį. Čia svarbu planuoti „backward-compatible“ migracijas: naujas kodas ir sena schema (ir atvirkščiai) trumpam turi sugyventi saugiai.

Rollback: greitas grįžimas atgal be failų kopijavimo

Immutable release’ai duoda labai praktišką benefit’ą: rollback tampa trivialus. Kadangi senas release’as vis dar yra diske, grįžti atgal reiškia tiesiog perjungti current symlink’ą į ankstesnį katalogą.

trellis rollback production

trellis rollback production

Pagal nutylėjimą serveryje laikomi keli paskutiniai release’ai (Trellis numatytai saugo penkis). Tai reiškia, kad blogas deploy’as nėra „incidentas su naktiniu taisymu“, o 10 sekundžių operacija, kol aiškiniesi, kas nutiko.

Deploy hook’ai: kaip prisitaikyti procesą prie realaus projekto

Trellis diegimo procesas turi hook’us (kablius) — tai vietos, kur gali įterpti savo užduotis į konkrečius žingsnius. Pavyzdžiai:

• deploy_build_before / deploy_build_after — papildomi build žingsniai (pvz., asset’ų generavimas, jei tai darai serveryje).
• deploy_finalize_before / deploy_finalize_after — užduotys prieš ir po perjungimo (pvz., cache flush, warmup, health check).
• Hook’ai kiekvienam pagrindiniam etapui: initialize, update, prepare, build, share, finalize.

Praktikoje hook’ai leidžia susidėlioti „brandų“ deploy scenarijų: pasidaryti DB backup prieš perjungimą, išvalyti page cache po perjungimo, prasukti smoke test prieš nukreipiant srautą į naują release, arba išsiųsti pranešimą komandai.

Nuo ko pradėti, jei nori Trellis naudoti tik diegimui?

Minimalus kelias atrodo taip:

1. Projektą susitvarkyti su Bedrock (Roots WordPress struktūra, kuri padeda tvarkingai valdyti priklausomybes ir konfigūraciją).
2. Įsidiegti Trellis ir susikonfigūruoti deploy nustatymus.
3. wordpress_sites.yml faile nurodyti Git repo informaciją (iš kur imti kodą).
4. Paleisti trellis deploy production.

Pirmas diegimas dažniausiai užtrunka ilgiau, nes sukuria struktūrą ir susideda priklausomybes. Vėlesni deploy’ai tampa ženkliai greitesni — ir svarbiausia, atliekami be vartotojams matomų „bangavimų“.

Reziumė: kada Trellis atominių deploy’ų modelis labiausiai atsiperka?

• Kai svetainė turi realų srautą ir net kelių minučių „pusiau atnaujinta“ būsena sukelia klaidas ar prarastas konversijas.
• Kai nori turėti realų rollback’ą, o ne „grąžinkit backup’ą“.
• Kai WordPress projektą valdai kaip aplikaciją: su Git, Composer, aplinkomis (staging/production) ir aiškiu release’ų gyvenimo ciklu.