Zero downtime deployments για WordPress με Trellis: atomic releases, rollback και hooks

Στο WordPress οικοσύστημα, το deployment συχνά παραμένει μια διαδικασία «ανέβασε αρχεία και προσευχήσου» — ειδικά όταν το project έχει αρκετά plugins, custom theme, Composer dependencies ή build βήματα. Σε πιο “μοντέρνα” stacks, το zero downtime deployment θεωρείται δεδομένο: ο χρήστης δεν πρέπει να καταλάβει ποτέ ότι έγινε release.

Το Trellis (το server/provisioning & deployment framework των Roots, βασισμένο σε Ansible) φέρνει αυτό το μοντέλο και στο WordPress, με atomic και immutable deployments out of the box. Και το ενδιαφέρον είναι ότι δεν χρειάζεται να αλλάξεις όλο το workflow σου: αρκετοί το χρησιμοποιούν μόνο για deploy ενός Bedrock site, κρατώντας τοπικά ό,τι περιβάλλον θέλουν (Valet, Lando, DDEV κ.λπ.).

Τι σημαίνει στην πράξη “zero downtime” στο deployment

Zero downtime σημαίνει ότι το site παραμένει πλήρως λειτουργικό καθ’ όλη τη διάρκεια του deploy. Δεν υπάρχει περίοδος όπου ο server σερβίρει «μισά παλιά, μισά καινούρια» αρχεία, ούτε παράθυρο όπου λείπουν dependencies ή δεν έχει ολοκληρωθεί κάποιο build step.

Το κλειδί εδώ είναι η λέξη atomic: η μετάβαση από την παλιά έκδοση στη νέα γίνεται σε μία κίνηση (σαν “switch”), χωρίς ενδιάμεση κατάσταση.

Το κλασικό πρόβλημα στα παραδοσιακά WordPress deployments

Οι πιο συνηθισμένες προσεγγίσεις στο WordPress είναι ακόμα οι παρακάτω — και όλες έχουν το ίδιο θεμελιώδες μειονέκτημα: ενημερώνουν αρχεία in-place όσο το site είναι live.

• FTP uploads: ανεβάζεις αλλαγμένα αρχεία και γίνεται overwrite. Αν το upload κρατήσει λεπτά, ο χρήστης μπορεί να “πετύχει” μίξη παλιών/νέων αρχείων (fatal errors, missing classes, broken templates).
• File sync (π.χ. rsync): πιο γρήγορο από FTP, αλλά πάλι γράφει πάνω στο live filesystem. Το πρόβλημα της μίξης αρχείων δεν εξαφανίζεται.
• Plugin-based deployment σε managed hosts: βολικό, αλλά συχνά ακολουθεί την ίδια λογική (update in-place) και συνήθως δεν δίνει πραγματικά καθαρό rollback μηχανισμό.

Κοινά συμπτώματα: στιγμιαία 500άρια, “Class not found” λόγω Composer autoload που δεν έχει ολοκληρώσει, assets mismatch, και το πιο ενοχλητικό: όταν κάτι πάει στραβά δεν έχεις εύκολο, άμεσο γύρισμα στην προηγούμενη σταθερή έκδοση.

Πώς το Trellis το λύνει: atomic + immutable releases

Το Trellis εφαρμόζει ένα deployment μοντέλο που συναντάς σε σύγχρονα apps: κάθε deploy δημιουργεί ένα νέο, απομονωμένο release directory. Τα αρχεία ενός release δεν “πειράζονται” μετά (immutable). Όταν όλα είναι έτοιμα, γίνεται το switch με ένα symlink.

Η δομή φακέλων στον server

Με Trellis, ένα τυπικό site στον server καταλήγει να έχει αυτή τη λογική δομή:

/srv/www/example.com/
├── current/             # Symlink προς το ενεργό release
├── releases/            # Όλα τα deployed releases
│   ├── 20250930124530/
│   ├── 20250930083045/
│   └── 20250930141622/  # Πιο πρόσφατο
├── shared/              # Κοινά/shared ανάμεσα σε releases
│   └── uploads/
└── logs/

/srv/www/example.com/
├── current/             # Symlink προς το ενεργό release
├── releases/            # Όλα τα deployed releases
│   ├── 20250930124530/
│   ├── 20250930083045/
│   └── 20250930141622/  # Πιο πρόσφατο
├── shared/              # Κοινά/shared ανάμεσα σε releases
│   └── uploads/
└── logs/

Ο web server (Nginx) σερβίρει πάντα από το current/, το οποίο στην πραγματικότητα είναι symlink που δείχνει σε ένα release μέσα στο releases/.

Τι κάνει το trellis deploy production βήμα-βήμα

Όταν τρέχεις:

trellis deploy production

trellis deploy production

το Trellis εκτελεί μια ακολουθία σταδίων που κρατά το live site «καθαρό» από ενδιάμεσες καταστάσεις:

1. Initialize: διασφαλίζει ότι υπάρχει η δομή φακέλων και ανοίγει νέο release directory με timestamp.
2. Update: κάνει clone το τελευταίο code από το Git repository σε προσωρινό source directory (ξεχωριστά από το live).
3. Prepare: αντιγράφει/τοποθετεί τα απαραίτητα αρχεία στο νέο release directory.
4. Build: τρέχει composer install για να κατέβουν dependencies.
5. Share: κάνει symlink shared resources (π.χ. uploads/) από το shared/ στο νέο release.
6. Finalize: αλλάζει το current symlink ώστε να δείχνει στο νέο release.

Το κρίσιμο σημείο είναι το Finalize: τη μία στιγμή το current δείχνει στο προηγούμενο release, την επόμενη δείχνει στο καινούριο. Δεν υπάρχει χρονικό διάστημα όπου το filesystem του ενεργού release “χτίζεται” μπροστά στα μάτια των επισκεπτών.

Η βάση δεδομένων είναι ξεχωριστό κεφάλαιο

Το zero downtime που προσφέρει το Trellis αφορά το codebase/filesystem. Οι αλλαγές στο schema της βάσης (migrations) είναι άλλο θέμα. Όπως αναφέρει και το documentation του Trellis, migrations σε νέο schema δεν αποτελούν μέρος του deploy από προεπιλογή: https://roots.io/trellis/docs/deployments/

Αν δουλεύεις με Acorn (το framework των Roots που φέρνει Laravel-like δομή σε WordPress projects), μπορείς να ορίσεις Laravel migrations και να τις εντάξεις στη διαδικασία: https://roots.io/acorn/docs/creating-and-running-laravel-migrations/

Rollback χωρίς δράματα: αλλάζεις symlink και τελείωσες

Σε atomic/immutable deployments, το rollback είναι απλό επειδή τα προηγούμενα releases παραμένουν διαθέσιμα ως πλήρεις, «παγωμένες» εκδόσεις. Το Trellis παρέχει έτοιμη εντολή:

trellis rollback production

trellis rollback production

Αυτό γυρίζει το current symlink στο προηγούμενο release. Από προεπιλογή, το Trellis διατηρεί τα 5 πιο πρόσφατα releases στον server, ώστε να υπάρχει άμεση επιλογή επιστροφής.

Deployment hooks: εκεί που το Trellis γίνεται πραγματικά ευέλικτο

Το Trellis έχει hooks (δηλαδή σημεία επέκτασης μέσα στη ροή του deploy) για να κουμπώσεις δικά σου tasks πριν/μετά από βασικά στάδια. Ενδεικτικά:

• deploy_build_before και deploy_build_after για custom build βήματα.
• deploy_finalize_before και deploy_finalize_after για εργασίες πριν/μετά το “switch”.
• Hooks ανά στάδιο (initialize, update, prepare, build, share, finalize) για πιο λεπτομερή έλεγχο.

Με αυτά μπορείς να υλοποιήσεις πρακτικά patterns που σε WordPress projects συναντάμε συχνά στην παραγωγή: backup πριν το deploy, cache clears μετά το deploy, notifications, ή ακόμα και smoke tests πάνω στο νέο release πριν γίνει το τελικό switch.

Πώς ξεκινάς (χωρίς να αλλάξεις απαραίτητα το local setup σου)

Στο πιο απλό σενάριο, για να αποκτήσεις zero downtime deployments με Trellis, η ροή είναι η εξής:

1. Στήνεις το project με Bedrock για πιο καθαρή δομή WordPress και διαχείριση dependencies: https://roots.io/bedrock/
2. Εγκαθιστάς/ρυθμίζεις Trellis και τα deployment settings: https://roots.io/trellis/
3. Συμπληρώνεις στο wordpress_sites.yml τα στοιχεία του site και το Git repository.
4. Τρέχεις trellis deploy production.

Το πρώτο deploy συνήθως αργεί περισσότερο, γιατί δημιουργείται η δομή και κατεβαίνουν dependencies. Από εκεί και πέρα, το σημαντικότερο κέρδος δεν είναι μόνο η ταχύτητα αλλά η προβλεψιμότητα: κάθε release είναι απομονωμένο, το switch είναι atomic, και το rollback είναι άμεσο.

Σύνοψη

• Το “zero downtime” στο WordPress είναι εφικτό όταν αποφεύγεις updates in-place.
• Το Trellis το πετυχαίνει με atomic deployments και immutable releases (νέος φάκελος ανά deploy + current symlink switch).
• Το rollback γίνεται σε δευτερόλεπτα με αλλαγή symlink (trellis rollback).
• Η βάση δεδομένων/migrations χρειάζεται ξεχωριστό σχεδιασμό (και μπορείς να αξιοποιήσεις Acorn migrations).
• Τα hooks του Trellis σου επιτρέπουν να προσαρμόσεις πλήρως τη ροή του deployment.