---
title: "Null-seisakuga WordPressi deploy Trellisega: atomic release’id ja kiire rollback"
url: "https://helloblog.io/et/null-seisakuga-wordpressi-deploy-trellisega-atomic-released-ja-kiire-rollback/"
date: "2025-10-02"
modified: "2026-01-20"
author: "Martin Kask"
language: "et_EE"
categories: ["WordPressi ökosüsteem"]
tags: ["Bedrock", "Deploy", "DevOps", "Trellis", "WordPress"]
featured_image: "https://helloblog.io/app/uploads/sites/18/2026/01/featured-2-1024x572.png"
excerpt: "Kui sul on kunagi deploy ajal mõni leht korraks “katki” läinud või vales versioonis faile serveerinud, siis atomic deployment on lihtsaim viis see probleem ära lõpetada. Trellis teeb null-seisakuga WordPressi deploy out-of-the-box — ka siis, kui sa ei kasuta Trellist kohaliku arenduse jaoks."
---

# Null-seisakuga WordPressi deploy Trellisega: atomic release’id ja kiire rollback

WordPressi maailmas on “deploy” liiga tihti sünonüüm olukorrale, kus keegi lükkab failid serverisse ja loodab, et külastajad ei satu täpselt samal hetkel vale kombinatsiooni vana ja uue koodi otsa. Ka siis, kui kasutad Git’i ja automatiseerid protsessi, jääb paljudel setup’idel üks põhiprobleem: *failid kirjutatakse live’is üle*.

Roots’i Trellis lahendab selle sama loogikaga, mida modernses rakenduste arenduses peetakse ammu standardiks: **atomic deployment** (atomaarne väljalase). Tulemus: kood deploy’itakse eraldi “release’i” kausta, kontrollitakse/ehitatakse valmis ja alles siis tehakse hetkeline ümberlülitus. Külastaja jaoks ei ole deploy akent, kus sait poolenisti katki oleks.

## Mis asi on “zero downtime deployment” WordPressi kontekstis?

Null-seisakuga (zero downtime) deploy tähendab, et sait püsib kogu deploy protsessi ajal kasutatav: HTTP vastused tulevad, WordPress töötab ja kasutaja ei näe “valget lehte”, 500 vigu ega katkist fronti, mis tekib siis, kui server serveerib korraga vanu ja uusi faile läbisegi.

Oluline detail: Trellis saavutab selle **koodibaasi** tasemel. Andmebaasi skeemi muutused (migratsioonid) on eraldi teema ja vajavad teadlikku käsitlust.

## Miks klassikaline WordPressi deploy kipub katki minema?

Enamik WordPressi saite jõuab tootmisesse ikka ühe kolmest teest, mis kõik jagavad sama nõrkust: live’is kirjutatakse olemasolevad failid üle.

- **FTP üleslaadimine**: aeglane ja “akna” jooksul serveeritakse segu vanast ja uuest. Kui tabad hetke, kus näiteks üks PHP fail on uus, aga sõltuv fail veel vana, on tulemus ettearvamatu.
- **Failide sünk (nt `rsync`)**: kiirem kui FTP, aga olemuselt sama — live’i faile asendatakse järk-järgult.
- **Hosti/plugin’i-põhine deploy**: mugav, kuid tihti samuti in-place uuendus ilma selge rollback-mehhanismita.

Kõigi nende puhul on tüüpilised mured: deploy ajal võib sait ajutiselt katki olla, rollback on kas ebamugav või puudub ning probleemide korral hakkad käsitsi “tagasi kerima”.

## Kuidas Trellis teeb atomic deploy: “release’id + current symlink”

Trellis kasutab atomic deployment strateegiat: iga deploy loob serverisse **uue isoleeritud release’i kataloogi** ning live liiklus lülitatakse ümber ühe hetkega sümboolse lingi (symlink) abil. Lisaks on see lähenemine **immutable**: deploy’itud release’i faile ei muudeta hiljem kohapeal.

### Tüüpiline kataloogistruktuur serveris

```
/srv/www/example.com/
├── current/             # Symlink aktiivsele release’ile
├── releases/            # Kõik deploy’itud release’id
│   ├── 20250930124530/
│   ├── 20250930083045/
│   └── 20250930141622/  # Kõige värskem
├── shared/              # Jagatud failid release’ide vahel
│   └── uploads/
└── logs/
```

Siin on võtmekohaks `current`. Web server (Nginx) serveerib alati `current` kataloogi. `current` ise ei sisalda “päris faile”, vaid osutab ühele kindlale release’ile `releases/` all.

### Mis toimub käsu `trellis deploy production` ajal?

Deploy ei tähenda Trellises “kopeeri uued failid live’i peale”, vaid pigem “valmista uus release ette ja tee see aktiivseks”.

1. **Initialize**: kontrollitakse, et kataloogid/struktuur on olemas ning luuakse uue timestamp’iga release’i kaust.
2. **Update**: uusim kood tõmmatakse Git repository’st eraldi source-kausta (mitte live’i).
3. **Prepare**: kood kopeeritakse uude release’i kataloogi.
4. **Build**: käivitatakse `composer install`, et sõltuvused tuleksid õigesse seisu.
5. **Share**: jagatud asjad (nt `uploads`) linkitakse `shared/` alt uude release’i.
6. **Finalize**: `current` symlink suunatakse uuele release’ile. See on hetk, kus live liiklus “lülitub ümber” — praktiliselt koheselt.

Kasutaja vaates on erinevus suur: ühel hetkel teenindab sait näiteks `releases/20250930124530`, järgmisel hetkel `releases/20250930141622`. Vahepealset “poolikut” seisundit ei eksisteeri.

## Andmebaas: mida Trellis ei tee sinu eest automaatselt

Trellise deploy katab koodi, kuid **andmebaasi migratsioonid uuele skeemile ei kuulu automaatselt deploy protsessi**. Trellise dokumentatsioon rõhutab seda selgelt: andmebaasi skeemi muutmine on eraldi vastutus.

Kui kasutad Roots Acornit, saad WordPressi projektis kasutada **Laravel migrations**’i (migratsioonid) lähenemist ning siduda nende käivitamise deploy protsessiga. See annab distsipliini, aga eeldab, et migratsioonid on kirjutatud “safe deploy” mõtteviisiga (tagasiühilduvus, järkjärgulised muutused jne).

#### Praktiline reegel

Zero downtime koodideploy ei tähenda automaatselt zero downtime skeemimuudatusi. Kui teed DB muudatusi, planeeri need nii, et vana ja uus kood suudaksid üleminekuperioodil koos eksisteerida või tee muudatus eraldi hooldusaknas.

## Rollback on Trellises päriselt kiire (ja seetõttu kasutatav)

Atomic + immutable deploy’i üks suurimaid võite on **instant rollback**. Kuna iga release on eraldi terviklik kaust ja seda pärast deploy’d ei “lapita”, on tagasipöördumine sisuliselt symlinki ümber suunamine eelmisele release’ile.

```
trellis rollback production
```

Vaikimisi hoiab Trellis serveris alles viis viimast release’i, mis tähendab, et sul on tavaliselt olemas nii “eelmine töötav” kui ka paar ajaloolist varianti.

## Deploy hook’id: kuidas lisada enda kontrollid ja järeltegevused

Reaalses projektis ei piirdu deploy ainult `composer install`’iga. Trellis pakub hook’e (konksud) — kindlates sammudes käivitatavaid kohandusi — millega saad protsessi oma vajadustele vastavaks teha.

- `deploy_build_before` / `deploy_build_after` – lisaehitused enne või pärast build’i.
- `deploy_finalize_before` / `deploy_finalize_after` – tegevused vahetult enne või pärast ümberlülitust.
- Hook’id iga suure sammu jaoks: initialize, update, prepare, build, share, finalize.

Tüüpilised kasutusmustrid hook’idega:

- tee andmebaasi backup enne ümberlülitust
- tühjenda cache (nt page cache, object cache) pärast ümberlülitust
- saada deploy-notification Slacki/Teamsi webhook’i kaudu (webhook = HTTP callback endpoint, kuhu saad sündmuse kohta POST’i teha)
- käivita smoke test uue release’i vastu enne, kui lülitad `current` symlinki ümber

## Kuidas alustada, kui sa ei taha Trellist “kõigeks” kasutada?

Trellise hea omadus on see, et sa ei pea seda tingimata kasutama kogu arendustöövoo vundamendina. Praktikas kasutatakse Trellist tihti *ainult deploy’iks* Bedrocki-põhiste WordPressi saitide puhul, samal ajal kui lokaalne arendus käib muude tööriistadega (nt Valet, Lando, DDEV).

1. Sea projekt üles Roots **Bedrock**iga (mõistlikum struktuur ja sõltuvuste haldus).
2. Lisa **Trellis** ja defineeri keskkondade seaded.
3. Täida `wordpress_sites.yml` nii, et Trellis teaks sinu Git repository infot.
4. Käivita `trellis deploy production`.

Esimene deploy võtab reeglina kauem, sest serverisse tehakse struktuur ja tõmmatakse kõik sõltuvused. Järgmised deploy’d on kiiremad ning kõige olulisem: sa ei pea enam planeerima deploy’d “vaiksemale ajale”, sest failide ülekirjutamisest tekkivat katkemise riski sisuliselt ei ole.

## Viited / Allikad

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