--- title: "Deploy-uri WordPress fără downtime cu Trellis: atomic, imutabil și cu rollback instant" url: "https://helloblog.io/ro/deploy-uri-wordpress-fara-downtime-cu-trellis/" date: "2025-10-02" modified: "2026-01-20" author: "Elena Popescu" language: "ro_RO" categories: ["Ecosistem WordPress"] tags: ["Bedrock", "Deployment", "DevOps", "Trellis", "WordPress"] featured_image: "https://helloblog.io/app/uploads/sites/10/2026/01/featured-2-1024x572.png" excerpt: "Dacă ai făcut vreodată deploy pe WordPress și ai prins fix atunci erori „random” sau pagini încărcate pe jumătate, problema e aproape mereu aceeași: fișiere suprascrise live. Trellis rezolvă asta cu deploy-uri atomice și rollback printr-un simplu symlink switch." --- # 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/ ``` 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. #### Atenție la compatibilitate în migrații Chiar și cu deploy atomic la nivel de fișiere, o migrație care schimbă schema poate introduce incompatibilități dacă noul cod și vechiul cod nu pot funcționa pe aceeași schemă pentru o perioadă scurtă. Ideal: migrații compatibile înapoi (backwards-compatible) sau strategii în doi pași. ## 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 ``` 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. ## Referințe / Surse - [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/)