Zero downtime-deployar WordPress med Trellis: atomiska releaser, snabb rollback och hooks

Det är lätt att känna igen scenariot: du pushar en uppdatering, en host kör sin ”deploy-plugin” eller du syncar upp filer med rsync – och plötsligt får någon användare en trasig sida eftersom servern råkar servera en blandning av gammalt och nytt. I modern apputveckling är det här ett problem man löser med atomiska deployer (atomic deployments). I WordPress-världen är det fortfarande ovanligt – men Trellis har det inbyggt.

Trellis är Roots server- och deploy-verktyg som (bland annat) kan deploya WordPress-projekt på ett sätt som håller sajten uppe under hela releasen. Och det intressanta är att du inte måste byta hela din lokala workflow för att få nyttan: många kör Trellis enbart för deployment av Bedrock-baserade sajter, även när de utvecklar lokalt i Valet, Lando, DDEV eller liknande.

Vad ”zero downtime” betyder i praktiken

Zero downtime deployments betyder att sajten fortsätter vara fullt fungerande och åtkomlig medan du deployar. Nyckeln är att den nya versionen byggs färdigt helt isolerat, och först när allt är klart växlar servern över – momentant.

Kontrasten mot klassisk WordPress-deploy är tydlig: när du skriver över filer i place (via FTP, en sync, eller ett host-verktyg) finns en period där servern kan läsa in en ny PHP-fil men en gammal dependency, eller en ny template men gamla assets. Det räcker för att skapa intermittent fel som är svåra att reproducera.

Varför traditionella WordPress-deployer ofta strular

• FTP-uppladdning: manuellt, långsamt och serverar ofta en mix av gamla och nya filer under uppladdningen.
• Fil-synk (t.ex. rsync): snabbare än FTP, men grundproblemet kvarstår – du skriver över filer medan sajten är live.
• Plugin-/host-baserad deploy: bekvämt, men uppdaterar ofta filer i place och saknar smidig rollback om något går snett.

Gemensamt för uppläggen ovan är att de gör rollback svårt (eller manuellt) och att användare kan hinna möta fel under deploy-fönstret.

Så gör Trellis: atomiska och immutabla releaser

Trellis använder en atomisk strategi: varje deploy skapar en helt ny release-katalog, och den aktiva versionen pekas ut med en symlink (symbolisk länk). När allt är färdigbyggt uppdateras symlänken – vilket går i praktiken omedelbart. Inget skrivs över i den aktiva releasen.

Det här är även immutabelt i betydelsen att en release, när den väl är deployad, inte modifieras i place. Nästa deploy skapar en ny katalog. Det gör felsökning och rollback betydligt tryggare.

Katalogstrukturen på servern

Efter en deploy med Trellis får du en struktur som brukar se ut ungefär så här:

/srv/www/example.com/
├── current/             # Symlink till aktiv release
├── releases/            # Alla deployade releaser
│   ├── 20250930124530/
│   ├── 20250930083045/
│   └── 20250930141622/  # Senaste
├── shared/              # Delade filer mellan releaser
│   └── uploads/
└── logs/

/srv/www/example.com/
├── current/             # Symlink till aktiv release
├── releases/            # Alla deployade releaser
│   ├── 20250930124530/
│   ├── 20250930083045/
│   └── 20250930141622/  # Senaste
├── shared/              # Delade filer mellan releaser
│   └── uploads/
└── logs/

Webbservern (Nginx/Apache beroende på setup) servar alltid från current/. Eftersom current bara är en symlink kan Trellis byta från en release till en annan utan ett mellanläge där filer blandas.

Vad som händer när du kör en deploy

När du kör trellis deploy production bygger Trellis upp releasen stegvis, separat från den aktiva sajten:

1. Initialize: säkerställer att strukturen finns och skapar en ny release-katalog (ofta tidsstämplad).
2. Update: hämtar senaste koden från ditt Git-repo till en temporär plats (inte live-katalogen).
3. Prepare: kopierar över koden till den nya release-katalogen.
4. Build: kör composer install för att installera PHP-dependencies.
5. Share: symlänkar in delat innehåll (typiskt uploads) från shared/ in i releasen.
6. Finalize: uppdaterar current-symlänken så att den pekar på den nya releasen.

Det är i finalize-steget magin händer: ena ögonblicket pekar current på en äldre release, nästa ögonblick på den nya. Ingen filöverskrivning medan användare laddar sidan.

Databasen är en separat fråga (migreringar)

En viktig brasklapp: Trellis hanterar zero downtime för kod och filer, men databasschemaändringar ingår inte automatiskt i en deploy. Trellis-dokumentationen är tydlig med att databasmigreringar inte är en del av standardflödet.

Om du använder Acorn (Roots ramverk som tar in Laravel-koncept i WordPress) kan du jobba med Laravel migrations och se till att de körs som en del av deploy-processen. Poängen är att du behöver planera migreringar så att de är bakåtkompatibla, eller orkestrera dem med samma försiktighet som i andra system.

Rollback på sekunder tack vare symlänkar

Den praktiska vinsten med atomiska, immutabla releaser är rollback. Eftersom gamla releaser ligger kvar som kompletta kataloger är rollback bara att peka tillbaka current till föregående release:

trellis rollback production

trellis rollback production

Som standard behåller Trellis de fem senaste releaserna på servern, vilket gör att du kan backa snabbt om en deploy råkade ta med en regression.

Deploy hooks: anpassa utan att hacka flödet

Trellis har hooks (tänk ”krokar” i deploy-pipelinen) så att du kan lägga in egna steg före/efter centrala moment. Exempel som nämns i Trellis-flödet är deploy_build_before/deploy_build_after och deploy_finalize_before/deploy_finalize_after, samt hooks för varje större steg (initialize, update, prepare, build, share, finalize).

Det öppnar för mönster som ofta saknas i WordPress-deployer:

• Ta backup på databasen före deploy.
• Rensa cache efter deploy (page cache, object cache, CDN purge beroende på setup).
• Skicka deploy-notiser till teamet (t.ex. Slack via webhook).
• Köra enkla smoke tests mot den nya releasen innan/efter att current pekas om.

Kom igång: Trellis för deploy även om du utvecklar lokalt på annat sätt

Ett smidigt sätt att börja är att använda Trellis som deploy-motor, men behålla din befintliga lokala miljö. Upplägget som Roots rekommenderar är i korthet:

1. Sätt upp projektet med Bedrock för en modernare WordPress-struktur.
2. Installera och konfigurera Trellis för din servermiljö/deploy.
3. Fyll i wordpress_sites.yml med information om ditt Git-repo och relevanta inställningar.
4. Kör trellis deploy production.

En annan detalj som ofta uppskattas är att Trellis kan deploya till servrar du inte provisionerat med Trellis. Det gör det enklare att använda atomiska deployer även på managed hosts, så länge upplägget tillåter den typen av release-struktur och symlänkar.