Zero-Downtime-Deployments für WordPress mit Trellis: Atomic Releases, Rollbacks und Hooks

Zero-Downtime-Deployments sind in vielen App-Stacks Standard – im WordPress-Alltag dagegen erstaunlich selten. Dabei ist das Grundproblem immer dasselbe: Während eines Deployments überschreibst du Dateien in einem laufenden System, und für ein paar Sekunden (oder Minuten) läuft die Seite mit einem Mischzustand aus „alt“ und „neu“. Trellis (aus dem Roots-Ökosystem) bringt dafür einen bewährten Ansatz mit: atomare Deployments (atomic deployments), bei denen ein Release komplett vorbereitet wird und erst dann per Symlink in einem Schritt live geht.

Wichtig in der Praxis: Du musst Trellis nicht zwangsläufig als vollständiges Provisioning- und Development-Framework einsetzen, um von diesem Deployment-Modus zu profitieren. Viele Teams nutzen Trellis gezielt fürs Ausrollen von Bedrock-basierten Projekten – auch auf Managed Hosts – und bleiben lokal bei ihrem bevorzugten Setup (z. B. Valet, Lando, DDEV).

Was „Zero Downtime“ bei WordPress Deployments konkret heißt

„Zero Downtime“ bedeutet hier nicht „jede denkbare Änderung ist ohne Risiko“, sondern sehr konkret: Während des Deployments bleibt die Website durchgehend erreichbar und funktionsfähig, weil es keinen Zeitraum gibt, in dem Besucher:innen eine Mischung aus alten und neuen Dateien serviert bekommen. Der Wechsel auf die neue Version passiert „instant“, also als atomarer Umschaltpunkt.

Das klassische WordPress-Deployment-Problem

Viele WordPress-Deployments laufen (je nach Team und Hosting) immer noch über Muster, die sich technisch ähnlich verhalten: Sie aktualisieren Dateien direkt im Live-Verzeichnis. Typische Varianten:

• FTP-Uploads: Änderungen werden manuell hochgeladen und überschreiben bestehende Dateien. Währenddessen entstehen Mischzustände, die zu PHP-Errors, fehlenden Assets oder kaputten Templates führen können.
• Sync via rsync o. Ä.: Schneller als FTP, aber im Kern dasselbe Problem: Dateien werden im laufenden Betrieb ersetzt.
• Plugin-basierte Deployments bei Managed Hosts: Bequem, aber häufig ebenfalls „in place“ – und oft ohne wirklich sauberen Rollback-Mechanismus auf Dateiebene.

Gemeinsame Nebenwirkungen: Deployments sind fehleranfällig, ein schneller Rücksprung ist schwer, und im schlimmsten Fall sehen Nutzer:innen genau im falschen Moment einen kaputten Zustand.

Wie Trellis das löst: Atomic + Immutable Deployments

Trellis setzt auf eine Strategie, die du aus modernen Deployment-Setups kennst: Ein Release wird vollständig in einem eigenen Verzeichnis aufgebaut und erst danach wird die aktive Version umgeschaltet. Zusätzlich ist das Ganze immutable (unveränderlich): Ein deployed Release wird nicht nachträglich im selben Ordner „weiterbearbeitet“, sondern bleibt genau so bestehen, wie es ausgerollt wurde.

Die Verzeichnisstruktur: Releases + current-Symlink

Auf dem Server arbeitet Trellis mit einer klaren Struktur aus Releases, einem shared-Bereich und einem current-Symlink. Der Webserver zeigt immer auf current – und current zeigt auf genau ein Release.

/srv/www/example.com/
├── current/             # Symlink auf das aktive Release
├── releases/            # Alle deployten Releases
│   ├── 20250930124530/
│   ├── 20250930083045/
│   └── 20250930141622/  # Neueste Version
├── shared/              # Geteilte Dateien/Ordner über Releases hinweg
│   └── uploads/
└── logs/

/srv/www/example.com/
├── current/             # Symlink auf das aktive Release
├── releases/            # Alle deployten Releases
│   ├── 20250930124530/
│   ├── 20250930083045/
│   └── 20250930141622/  # Neueste Version
├── shared/              # Geteilte Dateien/Ordner über Releases hinweg
│   └── uploads/
└── logs/

Der entscheidende Punkt ist der Symlink-Wechsel: Statt Dateien im Live-Verzeichnis zu überschreiben, wird current in einem Schritt auf das neue Release umgebogen.

Was bei trellis deploy production passiert

Beim Deployment baut Trellis die neue Version komplett getrennt vom aktuell laufenden Release auf. Grob läuft das in Phasen ab:

• Initialize: Sicherstellen, dass die Struktur existiert; Anlegen eines neuen Release-Ordners (Timestamp).
• Update: Code aus dem Git-Repository in eine temporäre Source-Directory holen – getrennt vom Live-System.
• Prepare: Dateien aus der Source in das neue Release kopieren.
• Build: Abhängigkeiten installieren, typischerweise via composer install.
• Share: Gemeinsame Verzeichnisse/Dateien (z. B. Media Uploads) aus shared einhängen (symlinken).
• Finalize: current wird auf das neue Release umgeschaltet.

Damit gibt es keinen „Zwischenzustand“. Gerade bei WordPress – wo Themes, Plugin-Code und Autoloading schnell voneinander abhängen – ist das der Unterschied zwischen „Deployments als Routine“ und „Deployments als Nervenkitzel“.

Wichtige Abgrenzung: Datenbankänderungen sind ein eigenes Thema

Atomic Deployments lösen das Problem auf Dateiebene. Datenbank-Migrationen (Schema-Änderungen) sind davon getrennt. Laut Trellis-Doku sind DB-Migrationen nicht automatisch Teil eines Trellis-Deployments. Das ist wichtig, weil du sonst zwar „saubere“ Code-Releases hast, aber trotzdem eine Breaking Change in der DB einführen könntest.

Wenn du Acorn nutzt, kannst du dich an Laravel-Migrations orientieren und diese gezielt in den Deployment-Prozess integrieren. Der entscheidende Gedanke dabei: DB-Änderungen müssen so geplant werden, dass sie mit Rollbacks und paralleler Kompatibilität umgehen können.

Rollback in Sekunden: einer der größten Gewinne

Atomic + immutable hat einen extrem praktischen Nebeneffekt: Rollback ist kein „Restore aus Backup“, sondern ein Symlink-Switch. Wenn ein Release Probleme macht, zeigt current einfach wieder auf das vorherige Release.

trellis rollback production

trellis rollback production

Standardmäßig hält Trellis mehrere Releases auf dem Server (laut Quelle: fünf). Das reicht in vielen Teams, um typische „Oops“-Deployments sofort abzufangen, ohne erst Artefakte neu bauen zu müssen.

Deploy Hooks: der Weg zu „Production-ready“ Automatisierung

In der Realität endet ein gutes Deployment nicht beim Kopieren von Dateien. Trellis bringt dafür Hooks (Anknüpfungspunkte) mit, über die du Aufgaben vor/nach bestimmten Phasen einhängen kannst – etwa deploy_build_before, deploy_build_after, deploy_finalize_before und deploy_finalize_after sowie Hooks pro Hauptschritt.

Damit lassen sich gängige Patterns sauber abbilden, z. B.:

• Datenbank-Backups vor dem Umschalten erstellen
• Caches nach dem Deploy leeren (Object Cache, Page Cache, CDN Purge – je nach Setup)
• Benachrichtigungen an das Team senden (z. B. via Webhook)
• Smoke-Tests gegen das frisch gebaute Release ausführen

Ein pragmatischer Einstieg: Trellis nur fürs Deployment nutzen

Wenn du vor allem die Deployments verbessern willst, kannst du Trellis als „Deployment-Engine“ einsetzen, ohne dein lokales Setup zu ersetzen. Ein typischer Weg (wie im Roots-Stack häufig empfohlen) ist:

1. Projektstruktur mit Bedrock aufsetzen (sauberere Trennung, Composer-basierte Abhängigkeiten).
2. Trellis installieren und Deployment-Ziele konfigurieren.
3. wordpress_sites.yml so konfigurieren, dass Trellis dein Git-Repository als Quelle nutzen kann.
4. Deployment anstoßen: trellis deploy production.

Der erste Lauf dauert typischerweise länger, weil die Struktur angelegt und Dependencies installiert werden. Danach profitierst du vom Release-Ansatz – und vor allem vom Wegfall des „in place“-Überschreibens.

Kurzfazit

• Trellis setzt bei WordPress auf atomare, unveränderliche Releases statt Live-Überschreiben von Dateien.
• Der Wechsel passiert per current-Symlink und ist damit praktisch sofort – keine Mischzustände.
• Rollbacks sind dadurch schnell und unkompliziert (trellis rollback).
• Datenbank-Migrationen musst du separat planen; mit Acorn sind Laravel-artige Migrations möglich.
• Hooks machen aus dem Standard-Deploy einen anpassbaren Prozess (Backups, Cache Purge, Smoke Tests etc.).