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/

/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).

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

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 Bedrockiga (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.