---
title: "Zero downtime WordPress diegimai su Trellis: atominių release’ų praktika"
url: "https://helloblog.io/lt/zero-downtime-wordpress-diegimai-su-trellis/"
date: "2025-10-02"
modified: "2026-01-20"
author: "Mantas Jonaitis"
language: "lt_LT"
categories: ["WordPress"]
tags: ["Bedrock", "Deploy", "DevOps", "Roots", "Trellis"]
featured_image: "https://helloblog.io/app/uploads/sites/20/2026/01/featured-2-1024x572.png"
excerpt: "Kai WordPress atnaujinimas vyksta per FTP ar rsync, realūs lankytojai dažnai pirmi pamato klaidas. Trellis diegimo modelis sprendžia šią problemą atominiu perjungimu ir leidžia turėti greitą rollback be streso."
---

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

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

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ų“.

#### Svarbi praktinė detalė

Trellis zero downtime efektas galioja kodo bazei ir failams. Jei darai schema-breaking DB pokyčius, diegimą planuok taip, kad perėjimas būtų saugus (pvz., dviejų etapų migracijos), arba įtrauk papildomą strategiją.

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

## Nuorodos / Šaltiniai

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