Zero-downtime WordPress izvietošana ar Trellis: atomiskie deploy bez stresa

WordPress pasaulē joprojām bieži sastopama “klasiskā” izvietošanas (deployment) pieeja: augšupielādē failus un cer, ka pa vidu neviens lietotājs netrāpīs uz brīdi, kad sistēma ir nekonsistentā stāvoklī. Modernā lietotņu izstrādē tas sen vairs nav pieņemami — un tieši te Trellis ienes ļoti praktisku ideju: atomisku izvietošanu (atomic deployment), kas pēc noklusējuma dod zero downtime pieredzi.

Ko reāli nozīmē “zero downtime” WordPress kontekstā

Ar zero downtime deployment parasti saprot, ka vietne visu izvietošanas procesu laikā paliek pieejama un funkcionāla: nav brīža, kurā apmeklētājs redz daļēji atjauninātu kodu (vecas PHP klases + jauni šabloni, mainīts JS bez atbilstošiem CSS u.tml.).

Atšķirība ir pieejā: nevis pārrakstīt esošos failus turpat public_html, bet sagatavot pilnu jauno relīzi izolēti un tikai pašās beigās pārslēgt trafiku uz jauno relīzi ar vienu ātru darbību.

Kāpēc tradicionālais WordPress deploy mēdz “salūzt”

Lielākā daļa WordPress izvietošanas scenāriju iekrīt vienā no šiem modeļiem — un visiem ir kopīga problēma: failu maiņa notiek, kamēr vietne strādā.

• FTP augšupielāde: manuāli pārraksti mainītos failus. Process var vilkties minūtes, un pa to laiku lietotāji saņem failu “kokteili” no vecās un jaunās versijas.
• Failu sinhronizācija (piem., rsync): ātrāk nekā FTP, bet būtība tā pati — live vidē tiek pārrakstīti faili, kamēr pieprasījumi turpinās.
• Hostinga spraudņu/risinājumu deploy: ērti, bet nereti tas joprojām ir “in-place update” bez īstas atomikas un bez vienkārša rollback mehānisma.

Rezultāts: izvietošanas logā var parādīties 500 kļūdas, trūkstoši faili, “class not found”, nekorekti asseti, un, ja kas aiziet greizi, atgriešanās iepriekšējā stāvoklī bieži ir manuāla un lēna.

Kā Trellis panāk atomisku izvietošanu

Trellis izmanto pieeju, kas modernā lietotņu pasaulē ir standarts: katrs deploy izveido jaunu relīzes direktoriju, sagatavo tajā visu nepieciešamo un tikai tad pārslēdz web serveri uz šo relīzi.

Šo modeli bieži raksturo ar diviem atslēgas vārdiem:

• Atomic — pārslēgšanās notiek vienā momentā, bez “starpposma”, kur strādā puse vecā un puse jaunā.
• Immutable — jau izvietota relīze netiek labota/pārrakstīta uz vietas. Katrs deploy ir jauna, atsevišķa direktorija.

Direktoriju struktūra, uz kuras turas viss triks

Pēc izvietošanas uz servera Trellis uztur skaidru struktūru ar releases, shared un galveno “slēdzi” — current simbolisko saiti (symlink). Web serveris apkalpo tieši current.

/srv/www/example.com/
├── current/             # symlink uz aktīvo relīzi
├── releases/            # visas izvietotās relīzes
│   ├── 20250930124530/
│   ├── 20250930083045/
│   └── 20250930141622/  # jaunākā
├── shared/              # koplietojamie faili starp relīzēm
│   └── uploads/
└── logs/

/srv/www/example.com/
├── current/             # symlink uz aktīvo relīzi
├── releases/            # visas izvietotās relīzes
│   ├── 20250930124530/
│   ├── 20250930083045/
│   └── 20250930141622/  # jaunākā
├── shared/              # koplietojamie faili starp relīzēm
│   └── uploads/
└── logs/

No lietotāja viedokļa viss “maģiskais” moments ir tas, ka current pārslēdzas no vienas relīzes direktorijas uz citu praktiski uzreiz.

Kas notiek, kad palaiž trellis deploy production

Izvietošana ar Trellis ir secīgs process ar skaidriem soļiem. Svarīgākais — liela daļa darbu notiek ārpus live relīzes, tāpēc apmeklētāji nejūt failu atjaunošanu.

1. Initialize: pārbauda/izveido nepieciešamo struktūru un sagatavo jaunu relīzes direktoriju ar timestamp nosaukumu.
2. Update: paņem jaunāko kodu no Git repozitorija uz atsevišķu avota (source) direktoriju, nevis pārraksta live failus.
3. Prepare: sagatavo relīzi — kopē failus uz jaunās relīzes direktoriju.
4. Build: palaiž composer install, lai ielādētu atkarības (dependencies).
5. Share: pievieno koplietojamās direktorijas (piem., augšupielādes) no shared/ uz jauno relīzi ar symlink.
6. Finalize: atjauno current symlink, norādot uz jauno relīzi.

Praksē tas nozīmē: vienu mirkli vietne tiek apkalpota no releases/20250930124530, un nākamajā — jau no releases/20250930141622. Nav “upload loga”, kurā kaut kas ir pusceļā.

Datubāze: zero downtime kodam nenozīmē automātiskas migrācijas

Svarīga nianse: Trellis ar savu atomisko modeli atrisina koda izvietošanas stabilitāti, bet datubāzes shēmas izmaiņas ir atsevišķa tēma. Trellis dokumentācijā ir skaidri norādīts, ka datubāzes migrācijas uz jaunu shēmu nav iekļautas kā automātiska deploy sastāvdaļa.

Ja izmanto Acorn (Roots rīks, kas WordPress vidē ienes Laravel ergonomiku), vari veidot un palaist Laravel migrations (migrācijas) arī WordPress projektos un pieslēgt tās izvietošanas procesam. Tas palīdz disciplinēti un atkārtojami mainīt shēmu, bet joprojām jādomā par saderību (backward/forward compatibility), lai izvairītos no situācijām, kur kods un DB izmaiņas nav savietojamas pārejas brīdī.

Rollback bez panikas: viena komanda, viens symlink

Atomiska/immutabla pieeja uzreiz dod vēl vienu lielu ieguvumu: ātru rollback. Tā kā katra relīze ir pilnīga un netiek modificēta pēc izvietošanas, atgriešanās iepriekšējā versijā ir tikai current symlink pārslēgšana uz vecāku relīzi.

trellis rollback production

trellis rollback production

Pēc noklusējuma Trellis uz servera patur vairākas pēdējās relīzes (tipiski piecas), lai rollback būtu momentāns.

Deployment hook-i: kur ielikt savas darbības

Reālās komandās izvietošana reti ir tikai “ieliec kodu”. Trellis piedāvā deployment hook-us (āķus) — definētas vietas procesā, kur vari pieslēgt savus soļus.

• deploy_build_before un deploy_build_after — papildu build darbībām.
• deploy_finalize_before un deploy_finalize_after — uzdevumiem tieši pirms/pēc pārslēgšanās uz jauno relīzi.
• Hook-i katram lielajam solim: initialize, update, prepare, build, share, finalize.

Praktiski piemēri, ko ar to parasti dara: pirms deploy izveido DB backup, pēc deploy iztīra kešus, nosūta paziņojumus (piem., Slack), vai palaiž vienkāršus smoke testus pret jauno relīzi.

Kā sākt: Trellis var izmantot tikai deploy vajadzībām

Trellis nav obligāti jāizmanto visam izstrādes workflow. Bieži sastopams scenārijs: lokāli strādā ar sev ērtu vidi (piem., Valet, Lando, DDEV u.c.), bet uz serveri izvieto ar Trellis — īpaši, ja projekts balstās uz Bedrock (sakārtotāka WordPress projekta struktūra).

1. Sagatavo projektu ar Bedrock (labāka struktūra un atkarību pārvaldība).
2. Uzstādi Trellis un nokonfigurē izvietošanas iestatījumus.
3. wordpress_sites.yml norādi Git repozitoriju un pārējo nepieciešamo konfigurāciju.
4. Palaiž trellis deploy production.

Pirmais deploy parasti ir lēnāks — jāizveido direktoriju struktūra un jāielādē atkarības. Nākamie deploy ir ātrāki, un galvenais — tie ir paredzami un bez dīkstāves.