Zero-downtime deploys voor WordPress met Trellis: zo werkt ‘atomic’ in de praktijk

In moderne app-teams is het bijna vanzelfsprekend: je deployt zonder downtime en als er iets misgaat rol je binnen seconden terug. In de WordPress-wereld zie ik nog vaak het tegenovergestelde: bestanden “over” de oude versie heen kopiëren terwijl de site live is. Trellis (van Roots) brengt een volwassen deployment-aanpak naar WordPress met atomic deployments (atomische uitrol: in één klap omschakelen) en immutable releases (onveranderlijke releases: eenmaal gedeployed wordt er niet meer in die map geschreven).

Het mooie is: je hoeft Trellis niet per se voor je hele workflow te gebruiken. Veel teams draaien lokaal gewoon op Valet, Lando of DDEV, en gebruiken Trellis puur als deployment-tool voor Bedrock-projecten naar allerlei hosts (ook managed hosting).

Wat ‘zero downtime’ hier echt betekent (en wat niet)

Zero-downtime deployments betekenen dat je site tijdens de uitrol volledig bereikbaar en functioneel blijft. Geen moment waarop bezoekers een mix van oude en nieuwe PHP-bestanden, templates of assets voorgeschoteld krijgen.

Belangrijk nuancepunt: Trellis regelt dit voor je code en bestandsstructuur. Alles wat schema-wijzigingen in de database betreft (migrations) is een aparte verantwoordelijkheid. Je kunt dat wel integreren in je proces, maar het is niet “magisch” onderdeel van een standaard deploy.

Waarom traditionele WordPress-deploys zo vaak pijn doen

De klassieke methodes hebben allemaal hetzelfde fundamentele probleem: je wijzigt live bestanden terwijl je webserver ze tegelijk moet serveren.

• FTP-upload: je overschrijft bestanden één voor één. Tijdens het uploaden serveer je letterlijk een tussenstatus; dat is vragen om errors.
• Synchronisatie via tools zoals rsync: sneller, maar nog steeds ‘in-place’ overschrijven terwijl de site live is.
• Plugin-based deploys op managed hosts: handig, maar vaak nog steeds een in-place update zonder echt rollback-mechanisme op bestandsniveau.

Het gevolg: sporadische fatals, ontbrekende classes (Composer), assets die niet matchen met templates, en stress als je snel terug moet.

De kern van Trellis: atomic + immutable deployments

Trellis leent een aanpak uit de wereld van moderne applicatie-deployments: elke deploy maakt een complete nieuwe release aan in een eigen directory. Pas als alles klaarstaat, switcht de webserver in één handeling naar die release.

Die switch gebeurt via een symlink: je webserver wijst altijd naar current/, en current/ wijst op zijn beurt naar één specifieke release-map. Daardoor bestaat er geen “half geüpdatete” toestand.

De directory-structuur op de server

/srv/www/example.com/
├── current/             # Symlink naar actieve release
├── releases/            # Alle gedeployde releases
│   ├── 20250930124530/
│   ├── 20250930083045/
│   └── 20250930141622/  # Meest recente
├── shared/              # Gedeelde data over releases heen
│   └── uploads/
└── logs/

/srv/www/example.com/
├── current/             # Symlink naar actieve release
├── releases/            # Alle gedeployde releases
│   ├── 20250930124530/
│   ├── 20250930083045/
│   └── 20250930141622/  # Meest recente
├── shared/              # Gedeelde data over releases heen
│   └── uploads/
└── logs/

Alles wat “persistent” is (denk aan uploads) leeft in shared/ en wordt per release ingelinkt. Daarmee voorkom je dat media per ongeluk mee-versioned wordt of dat je per release een nieuwe uploads-map krijgt.

Wat er gebeurt bij trellis deploy production

Een deploy is grofweg een pipeline van stappen die Trellis achter de schermen uitvoert:

1. Initialize: Trellis controleert/maakt de directory-structuur aan en creëert een nieuwe release-map met timestamp.
2. Update: de laatste code wordt uit je Git-repository opgehaald naar een tijdelijke locatie, los van je live site.
3. Prepare: de broncode wordt klaargezet in de nieuwe release-directory.
4. Build: Trellis draait composer install om dependencies binnen te halen.
5. Share: gedeelde paden (zoals uploads) worden gesymlinked vanuit shared/ naar de nieuwe release.
6. Finalize: Trellis zet de current-symlink om naar de nieuwe release.

Dat laatste punt is de ‘atomic switch’. Het ene moment serveer je releases/20250930124530, het volgende moment releases/20250930141622. Geen overlap, geen mix, geen downtime.

Database: migrations zijn je eigen verantwoordelijkheid

Trellis documenteert expliciet dat database migrations naar een nieuw schema niet automatisch onderdeel zijn van een Trellis-deploy. Dat is logisch: schema-changes kunnen wél downtime veroorzaken als je ze niet backwards compatible uitvoert.

Werk je met Acorn (Roots’ Laravel-achtige frameworklaag voor WordPress), dan kun je Laravel migrations gebruiken en ze in je deployproces laten meelopen. De kunst blijft: ontwerp migrations en code zo dat je tijdelijk twee versies naast elkaar kunt verdragen (bijvoorbeeld additieve kolommen, pas later opruimen).

Rollback zonder drama: symlink terugzetten

Atomic en immutable deployments maken rollback bijna saai. Omdat elke release als complete snapshot op de server staat en niet “aangeraakt” wordt na deploy, is terugrollen simpelweg de symlink terugzetten naar de vorige release:

trellis rollback production

trellis rollback production

Standaard bewaart Trellis meerdere releases op de server (volgens de aankondiging: de vijf meest recente). Daardoor kun je snel terug naar een bekende goede toestand zonder opnieuw te builden of bestanden terug te kopiëren.

Deployment hooks: integreren met jouw standaard DevOps-routine

In de praktijk wil je bijna altijd net wat extra’s rondom een deploy: cache flushen, een backup maken, een notification sturen, een simpele smoke test draaien. Trellis heeft daarvoor deployment hooks (hooks = ingestoken haakjes in het proces) waarmee je stappen vóór/na fases kunt uitvoeren.

• Hooks rond build: deploy_build_before en deploy_build_after
• Hooks rond finalization: deploy_finalize_before en deploy_finalize_after
• Hooks per hoofd-stap: initialize, update, prepare, build, share en finalize

Dat maakt Trellis interessant als je een nette, herhaalbare deploystraat wilt, zonder dat je zelf een compleet systeem van symlinks, releases en cleanup hoeft te bouwen.

Praktisch starten: Trellis gebruiken (ook als je lokaal iets anders draait)

Volgens de aanpak van Roots is de meest logische basis een Bedrock-project (opgeruimde WordPress-structuur met Composer als first-class citizen). Daarna voeg je Trellis toe voor provisioning/deployments, maar je kunt Trellis ook vooral inzetten voor deployen naar een omgeving die je niet per se met Trellis hebt opgezet.

1. Zet je project op met Bedrock voor een betere projectstructuur.
2. Installeer en configureer Trellis voor je deployment settings.
3. Vul je wordpress_sites.yml met de Git-repo informatie.
4. Run: trellis deploy production.

Samengevat

• Zero-downtime in Trellis komt door een atomic switch via de current-symlink.
• Elke deploy is een nieuwe, immutable release-directory; geen live overschrijven meer.
• Rollback is snel omdat terugrollen neerkomt op het terugzetten van die symlink.
• Database-migrations vallen buiten de standaard deploy en vragen een bewust (backwards compatible) plan.
• Hooks maken het makkelijk om backups, cache clears en checks te integreren.