Nollakatkon WordPress-julkaisut Trelliksellä: atomiset deployt käytännössä

WordPress-sivuston julkaisuhetki on yllättävän usein se hetki, jolloin sivusto on haavoittuvimmillaan: tiedostoja kopioidaan tuotantoon “elävään” hakemistoon, ja hetken aikaa palvelin tarjoilee käyttäjille sekoituksen vanhaa ja uutta koodia. Lopputulos näkyy tutusti satunnaisina fataleina, puuttuvina assetteina tai rikkinäisinä admin-näkyminä — ja usein ilman helppoa tapaa palata takaisin.

Trellis (Roots-ekosysteemin palvelin- ja deploy-työkalu) tuo WordPressiin saman perusominaisuuden, joka on arkipäivää monissa sovellustiimeissä: zero downtime -julkaisut atomisella deploy-strategialla. Hyvä puoli on se, että Trellistä voi käyttää pelkästään deployyn, vaikka paikalliseen kehitykseen käyttäisit Valetia, Landoa tai DDEV:tä.

Mitä “zero downtime” tarkoittaa WordPressin deployssa?

Nollakatkon julkaisu tarkoittaa käytännössä sitä, että käyttäjälle sivusto pysyy toimintakuntoisena koko julkaisun ajan. Uusi versio rakennetaan valmiiksi erillään live-koodista, ja vasta kun kaikki on kasassa, liikenne ohjataan uuteen julkaisuun yhdellä välittömällä kytkennällä.

Oleellinen ero perinteiseen malliin on välitilan puuttuminen: missään vaiheessa käyttäjät eivät osu tilanteeseen, jossa osa tiedostoista on jo uusia ja osa vielä vanhoja.

Miksi perinteinen WordPress-julkaisu hajoaa helposti?

Tyypilliset WordPress-deployt osuvat yleensä johonkin näistä kategorioista:

• FTP/”kopioi tuotantoon” -päivitykset: ylikirjoitat tiedostoja suoraan julkisesta hakemistosta. Siirto kestää, ja sen ajan sivusto voi ajaa epäyhteensopivalla tiedostosekoituksella.
• Synkronointityökalut kuten rsync: usein nopeampi kuin FTP, mutta perusongelma on sama — ylikirjoitus tapahtuu samalla kun sivusto palvelee liikennettä.
• Hostin tai lisäosan “deploy”-toiminto: mukava käyttöliittymä, mutta monesti sama in-place-päivitys ilman kunnollista rollback-mekanismia.

Näille yhteistä on kolme ongelmaa: (1) julkaisu voi rikkoa sivuston hetkellisesti, (2) paluu edelliseen versioon on työlästä tai mahdotonta nopeasti ja (3) virhetilanteessa käyttäjät ovat koekaniineja.

Trelliksen ratkaisu: atominen ja immuuttinen julkaisu

Trellis käyttää atomista deploy-mallia: jokainen julkaisu päätyy omaan, erilliseen release-hakemistoonsa, eikä julkaistuja tiedostoja muokata enää paikan päällä (immutability). Live-sivusto ei koskaan osoita “rakenteilla” olevaan versioon.

Käytännön taika tapahtuu current-symbolisella linkillä (symlink): web-palvelin palvelee aina current-hakemistosta, joka on vain osoitin johonkin releases/-hakemistossa olevaan julkaisuun.

Hakemistorakenne palvelimella

/srv/www/example.com/
├── current/             # Symlink aktiiviseen releaseen
├── releases/            # Kaikki julkaisut
│   ├── 20250930124530/
│   ├── 20250930083045/
│   └── 20250930141622/  # Uusin
├── shared/              # Jaettu data releasien välillä
│   └── uploads/
└── logs/

/srv/www/example.com/
├── current/             # Symlink aktiiviseen releaseen
├── releases/            # Kaikki julkaisut
│   ├── 20250930124530/
│   ├── 20250930083045/
│   └── 20250930141622/  # Uusin
├── shared/              # Jaettu data releasien välillä
│   └── uploads/
└── logs/

Tämä rakenne on olennainen erityisesti WordPressissä, koska uploads (media) pitää olla jaettua dataa: sitä ei voi “julkaista Gitistä” jokaisen releasen mukana.

Mitä tapahtuu, kun ajat trellis deploy production?

Kun käynnistät deployn, Trellis tekee julkaisun vaiheet erillään live-koodista ja vaihtaa vasta lopuksi current-symlinkin uuteen hakemistoon. Korkealla tasolla prosessi etenee näin:

1. Initialize: varmistetaan hakemistorakenne ja luodaan uusi timestampattu release-hakemisto (esim. 20250930141622).
2. Update: uusin koodi haetaan Git-reposta erilliseen lähdehakemistoon, ei live-sivuston päälle.
3. Prepare: lähdekoodi kopioidaan uuden releasen hakemistoon.
4. Build: ajetaan composer install riippuvuuksien asentamiseksi.
5. Share: jaetut tiedostot/hakemistot (kuten uploads) linkitetään shared/-hakemistosta releasen sisään.
6. Finalize: current-symlink päivitetään osoittamaan uuteen releaseen — käytännössä välitön kytkentä.

Yhdessä hetkessä current osoittaa vanhaan releaseen, seuraavassa uuteen. Koska mitään ei ylikirjoiteta “livenä”, julkaisun aikainen rikkoutuminen vähenee oleellisesti.

Tietokanta ei päivity itsestään — ja hyvä niin

On tärkeää ymmärtää raja: Trelliksen nollakatko koskee ensisijaisesti koodia ja tiedostoja. Tietokantamuutokset (schema-migraatiot) ovat erillinen huoli, eikä Trellis automaattisesti aja migraatioita osana deployta.

Jos käytät Acornia (Roots-maailmassa Laravel-tyylinen framework WordPressiin), voit tehdä Laravel-migraatiot ja varmistaa, että ne ajetaan osana julkaisuprosessia. Tällöin kannattaa suunnitella migraatiot niin, että ne ovat yhteensopivia sekä vanhan että uuden koodin kanssa (esim. “expand/contract” -malli), jotta vältät katkokset myös tietokantakerroksessa.

Rollback ilman paniikkia

Atomisen ja immuuttisen mallin iso etu on se, että rollback ei tarkoita tiedostojen “peruuttelua”. Koska vanha release on edelleen kokonaisena olemassa, paluu on käytännössä symlinkin kääntö takaisin edelliseen versioon:

trellis rollback production

trellis rollback production

Trellis säilyttää oletuksena viisi viimeisintä releasea palvelimella, jolloin rollback on nopea myös tilanteessa, jossa huomaat ongelman vasta hetken käytön jälkeen.

Deploy hookit: paikka omille rutiineille

Harva tuotantoympäristö on täysin geneerinen. Trellis tarjoaa deploy hookit (käytännössä Ansible-puolen koukut) eri vaiheisiin, jotta voit liittää mukaan omia toimenpiteitä.

• deploy_build_before ja deploy_build_after: omat build-askeleet (esim. assettien generointi omalla tavalla).
• deploy_finalize_before ja deploy_finalize_after: tehtävät juuri ennen/jälkeen symlinkin vaihdon.
• Hookit myös päävaiheille: initialize, update, prepare, build, share ja finalize.

Näillä saat toteutettua tyypillisiä tuotantokäytäntöjä, kuten varmuuskopion ottamisen ennen deployta, välimuistien tyhjentämisen julkaisun jälkeen, ilmoitukset tiimille tai kevyet smoke testit uutta releasea vasten.

Miten pääset alkuun (ilman että vaihdat koko workflow’ta)

Jos tavoite on nollakatko ja helpompi rollback, koko kehitysympäristöä ei ole pakko sitoa Trellikseen. Yleinen malli on: Bedrock-projekti + Trellis pelkkään deployyn, ja paikallisesti käytät sitä ympäristöä, mikä on tiimille luontevin.

1. Ota projektipohjaksi Bedrock, jotta WordPress-projekti on selkeämmin “sovellusmainen” (Composer-riippuvuudet, env-konfigurointi, rakenne).
2. Asenna Trellis ja määritä deploy-asetukset.
3. Konfiguroi wordpress_sites.yml niin, että Trellis tietää Git-repon ja ympäristöt.
4. Aja ensimmäinen deploy komennolla trellis deploy production.

Yhteenveto

Trelliksen atominen deploy-malli tuo WordPressiin kaksi asiaa, joita moni on tottunut pitämään “enterprise-luksuksena”: nollakatkon julkaisut ja välitön rollback. Kun koodi julkaistaan aina uuteen release-hakemistoon ja tuotanto vaihtaa versiota vain current-symlinkin avulla, vältät in-place-ylikirjoituksen riskit. Tietokanta vaatii edelleen oman suunnittelunsa, mutta koodijulkaisun osalta Trellis antaa huomattavasti vakaamman perusmekaniikan kuin perinteiset WordPress-deployt.