Deploy-uri WordPress fără downtime cu Trellis: atomic, imutabil și cu rollback instant

În ecosistemul WordPress, „deploy” încă înseamnă prea des copiere de fișiere peste producție: FTP, rsync, sau un mecanism „one-click” de la hosting care, în spate, face același lucru. Pentru site-urile cu trafic, magazine WooCommerce sau proiecte unde pui accent pe stabilitate, metoda asta vine cu un risc constant: în fereastra de upload, utilizatorii pot nimeri un amestec de fișiere vechi și noi.

Trellis (din suita Roots) vine cu o abordare modernă, standard în lumea aplicațiilor web: zero downtime deployments pe baza unui model atomic și imutabil. Partea bună: poți să-l folosești doar pentru deploy, chiar dacă local lucrezi cu altceva (Valet, Lando, DDEV etc.) și chiar dacă serverul nu e provisionat integral cu Trellis.

Ce înseamnă, practic, „zero downtime” la deploy

„Zero downtime” nu e marketing pentru „deploy rapid”, ci o garanție de comportament: pe tot parcursul procesului de deploy, site-ul rămâne accesibil și funcțional. Diferența majoră față de un deploy clasic e că nu se suprascriu fișierele direct în directorul servit de web server.

În loc să actualizeze live fișierele, Trellis pregătește o versiune completă a release-ului într-un director separat, apoi face comutarea către noua versiune instant, într-un singur pas.

De ce se „rupe” WordPress-ul la deploy-urile tradiționale

Majoritatea metodelor comune au aceeași problemă structurală: modifică fișierele în loc (in-place), în timp ce site-ul rulează:

• FTP: upload manual peste fișierele existente; durează și servești un mix de versiuni.
• Sincronizare cu rsync: mai rapid, dar tot suprascriere live; nu există un punct atomic de comutare.
• Deploy prin plugin / mecanism de hosting: convenabil, dar de multe ori actualizează in-place și nu are rollback real, doar „re-deploy” sau intervenție manuală.

Efectele sunt previzibile: pagini cu erori intermitente, asset-uri lipsă (CSS/JS), incompatibilități temporare între PHP code și template-uri, și un rollback greoi atunci când ceva nu merge.

Cum rezolvă Trellis: deploy-uri atomice și imutabile

Trellis folosește un model de deploy atomic: trecerea de la versiunea veche la cea nouă se face instant. Și un model imutabil: odată ce un release a fost publicat, fișierele lui nu mai sunt modificate; fiecare deploy creează un director nou pentru release.

Structura de directoare: „current” e cheia

Pe server, Trellis organizează proiectul într-o structură predictibilă. Web serverul servește mereu din current/, care nu e un director „real”, ci un symlink către release-ul activ:

/srv/www/example.com/
├── current/             # Symlink catre release-ul activ
├── releases/            # Toate release-urile deploy-ate
│   ├── 20250930124530/
│   ├── 20250930083045/
│   └── 20250930141622/  # Cel mai recent
├── shared/              # Fisiere partajate intre release-uri
│   └── uploads/
└── logs/

/srv/www/example.com/
├── current/             # Symlink catre release-ul activ
├── releases/            # Toate release-urile deploy-ate
│   ├── 20250930124530/
│   ├── 20250930083045/
│   └── 20250930141622/  # Cel mai recent
├── shared/              # Fisiere partajate intre release-uri
│   └── uploads/
└── logs/

Rezultatul: nu mai există „jumătăți de deploy”. Până când nu e gata tot release-ul nou, current rămâne pe release-ul vechi.

Ce se întâmplă la trellis deploy production

Când rulezi trellis deploy production, Trellis parcurge, în esență, acești pași (fiecare într-o zonă izolată de site-ul live):

1. Initialize: verifică/creează structura de directoare și un nou director de release (timestamp).
2. Update: clonează codul din Git într-un director de surse separat de site-ul live.
3. Prepare: copiază fișierele necesare în noul director de release.
4. Build: rulează composer install pentru dependențe.
5. Share: leagă (symlink) directoarele/fișierele partajate (de exemplu uploads) din shared/ către noul release.
6. Finalize: schimbă symlink-ul current către noul release.

Momentul „atomic” este pasul de finalizare: într-o clipă, current trece de la un release la altul. Nu există fereastră în care utilizatorii să prindă fișiere amestecate.

Baza de date: nu e inclusă automat în conceptul de zero downtime

Deploy-ul atomic rezolvă partea de cod și fișiere, dar schema bazei de date e o altă discuție. Conform documentației Trellis, migrațiile de bază de date nu sunt incluse implicit într-un deploy Trellis.

Dacă folosești Acorn, ai opțiunea să gestionezi schimbările de schemă prin Laravel migrations (migrations = scripturi versionate care modifică schema în mod controlat) și să le rulezi ca parte din procesul de deploy.

Rollback instant: beneficiul care schimbă jocul

Pentru că release-urile sunt imutabile și păstrate separat, rollback-ul devine o operațiune banală: Trellis mută symlink-ul current înapoi către release-ul anterior. Comanda arată așa:

trellis rollback production

trellis rollback production

Implicit, Trellis păstrează un număr limitat de release-uri recente pe server (în materialul Roots este menționat 5). Asta înseamnă rollback rapid, fără să refaci build-ul și fără să recopiezi fișiere manual.

Hooks de deploy: cum integrezi pași custom fără să „strici” fluxul

Un detaliu foarte practic în Trellis este sistemul de hooks (puncte unde poți injecta task-uri proprii în pipeline-ul de deploy). Există hook-uri înainte/după build și înainte/după finalizare, plus hook-uri pentru fiecare etapă majoră (initialize, update, prepare, build, share, finalize).

Asta îți permite să standardizezi lucruri pe care altfel le faci manual sau cu scripturi ad-hoc:

• backup de DB înainte de deploy
• golire cache (aplicație, obiect cache, CDN) după comutarea release-ului
• notificări către echipă (Slack/Email) când s-a făcut deploy
• smoke tests rulate pe release-ul nou înainte de a-l face activ

Cum începi (minimal) dacă vrei Trellis doar pentru deploy

Dacă vrei să beneficiezi de deploy-uri zero downtime fără să-ți schimbi complet fluxul local, pașii de bază arată așa (conform recomandărilor Roots):

1. Structurează proiectul pe Bedrock (organizare mai clară a unui proiect WordPress, în special pentru dependențe și configurări).
2. Instalează și configurează Trellis pentru mediul țintă (staging/production).
3. Completează wordpress_sites.yml cu informațiile despre repository-ul Git din care se face deploy.
4. Rulează trellis deploy production.

Primul deploy durează, în mod normal, mai mult (setup de directoare, instalare dependențe). Deploy-urile următoare tind să fie mai rapide și, mai important, elimină complet fereastra clasică în care site-ul poate servi fișiere inconsistente.