---
title: "Zero downtime deployments για WordPress με Trellis: atomic releases, rollback και hooks"
url: "https://helloblog.io/el/zero-downtime-deployments-wordpress-me-trellis/"
date: "2025-10-02"
modified: "2026-01-20"
author: "Ελένη Γεωργίου"
language: "el_GR"
categories: ["Οικοσύστημα WordPress"]
tags: ["Bedrock", "Deployments", "DevOps", "Trellis", "WordPress"]
featured_image: "https://helloblog.io/app/uploads/sites/12/2026/01/featured-2-1024x572.png"
excerpt: "Αν κάνεις deploy WordPress «πάνω» στο live site (FTP/rsync/plugins), έχεις δει το κλασικό παράθυρο όπου κάτι σπάει. Με το Trellis μπορείς να περάσεις σε atomic deployments: κάθε release ετοιμάζεται απομονωμένα και γίνεται switch με ένα symlink, χωρίς downtime και με άμεσο rollback."
---

# 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/
```

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

### Τι κάνει το `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/](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/](https://roots.io/acorn/docs/creating-and-running-laravel-migrations/)

#### Πρακτική λεπτομέρεια για πραγματικό “zero downtime”

Αν κάνεις migrations, σχεδίασέ τες με backward compatibility όπου γίνεται (π.χ. additive changes) ώστε η παλιά έκδοση να μπορεί να τρέξει για λίγο πάνω στο νέο schema αν χρειαστεί rollback.

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

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

```
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/](https://roots.io/bedrock/)
2. Εγκαθιστάς/ρυθμίζεις **Trellis** και τα deployment settings: [https://roots.io/trellis/](https://roots.io/trellis/)
3. Συμπληρώνεις στο `wordpress_sites.yml` τα στοιχεία του site και το Git repository.
4. Τρέχεις `trellis deploy production`.

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

#### Σημείωση για hosting

Σύμφωνα με την ανακοίνωση, αρκετοί χρησιμοποιούν το Trellis αποκλειστικά για deployments Bedrock sites προς διάφορους providers (π.χ. Kinsta, RunCloud και άλλους managed hosts), ακόμα κι αν ο server δεν έχει γίνει provision από Trellis.

## Σύνοψη

- Το “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.

## Αναφορές / Πηγές

- [Zero Downtime WordPress Deployments with Trellis](https://roots.io/zero-downtime-wordpress-deployments-with-trellis/)
- [Trellis deployments documentation](https://roots.io/trellis/docs/deployments/)
- [Bedrock](https://roots.io/bedrock/)
- [Trellis](https://roots.io/trellis/)
- [Creating and running Laravel migrations (Acorn)](https://roots.io/acorn/docs/creating-and-running-laravel-migrations/)