Zero downtime WordPress-deployments med Trellis: sådan virker atomic releases i praksis

I moderne app-udvikling er zero downtime deployments efterhånden baseline: nye versioner bliver gjort klar ved siden af den kørende version, og der skiftes over i ét hug. I WordPress-verdenen ser jeg stadig masser af deploy-flows, der reelt er “kopiér filer op og kryds fingre”. Roots’ Trellis kommer med en atomic deployment-strategi ud af boksen, og den er en af de mest undervurderede opgraderinger, du kan give dit WordPress-driftssetup.

Det interessante er, at du ikke behøver at adoptere Trellis til hele din udviklingsworkflow for at få værdien. Mange bruger Trellis primært som deploy-værktøj til Bedrock-baserede projekter, mens de fortsætter lokalt med fx Valet, Lando eller DDEV – og deployer til alt fra managed hosts til mere klassiske Linux-servere.

Hvad “zero downtime” egentlig betyder i WordPress-kontekst

Når vi taler zero downtime, handler det ikke om, at der aldrig kan opstå en fejl i en release. Pointen er, at selve deploy-processen ikke efterlader sitet i en halv-opdateret tilstand, hvor brugere rammer fatale errors, manglende filer eller en blanding af gammel og ny kode.

Den klassiske WordPress-deploy er ofte “in-place”: filer overskrives direkte i den mappe, webserveren serverer fra. Det kan være hurtigt, men det er også den perfekte opskrift på transient fejl, når en request rammer midt i en upload.

Hvorfor traditionelle WordPress-deploys går galt

De fleste WordPress-sites ender i én af de her tre deploy-kategorier:

• FTP/SFTP-uploads: Man uploader ændringer manuelt og overskriver eksisterende filer. Undervejs serverer sitet en blanding af gammelt og nyt.
• Synkronisering med fx rsync: Typisk hurtigere end FTP, men det er stadig “overskriv live filer”, så problemet er det samme.
• Plugin-baseret deployment på managed hosts: Ofte super nemt i UI’et, men mange løsninger opdaterer stadig filer in-place og uden en reel rollback-mekanisme.

Fællesnævneren er, at du kan få mærkelige fejl under deploy-vinduet, og at rollback typisk er en manuel øvelse (eller i praksis “deploy igen og håb”).

Trellis’ løsning: atomic og immutable deployments

Trellis deployer ikke ved at overskrive den kørende release. I stedet arbejder den med atomic deployments (skift i ét hug) og et immutable release-princip (en release ændres ikke efter den er lagt ud).

Det betyder i praksis, at hver deploy skaber en helt ny release-mappe, gør den klar i isolation og skifter derefter webserverens “pegepind” til den nye release. Ingen mellemfaser, hvor brugere ser en halvt opdateret kodebase.

Mappestrukturen: “current”, “releases” og “shared”

Når Trellis deployer til en server, etablerer den en struktur, der er designet til netop atomic releases:

/srv/www/example.com/
├── current/             # Symlink til aktiv release
├── releases/            # Alle deployede releases
│   ├── 20250930124530/
│   ├── 20250930083045/
│   └── 20250930141622/  # Nyeste
├── shared/              # Delte filer på tværs af releases
│   └── uploads/
└── logs/

/srv/www/example.com/
├── current/             # Symlink til aktiv release
├── releases/            # Alle deployede releases
│   ├── 20250930124530/
│   ├── 20250930083045/
│   └── 20250930141622/  # Nyeste
├── shared/              # Delte filer på tværs af releases
│   └── uploads/
└── logs/

Nøglen er current, som ikke er en “rigtig” mappe, men et symlink (symbolsk link). Webserveren peger altid på current, og Trellis kan derfor skifte aktiv release ved blot at opdatere symlinket.

Hvad der sker, når du kører en deploy

Når du kører trellis deploy production, gennemfører Trellis en serie trin, hvor den nye release bygges op adskilt fra den live kode:

1. Initialize: Struktur sikres, og en ny release-mappe oprettes (typisk timestamp-baseret).
2. Update: Nyeste kode hentes fra dit Git-repository til et separat område, ikke direkte ind i live path.
3. Prepare: Koden kopieres over i release-mappen.
4. Build: Dependencies installeres (fx via composer install).
5. Share: Delte paths (typisk uploads) linkes ind fra shared til den nye release.
6. Finalize: current-symlinket opdateres til at pege på den nye release.

Overgangen bliver dermed et øjebliksskift: det ene sekund serverer sitet fra en gammel release-mappe, og det næste sekund serverer det fra den nye.

Database: zero downtime for kode er ikke det samme som schema-ændringer

Atomic deployments løser fil- og kodeproblemet, men databasen er en separat udfordring. Trellis’ deploy inkluderer ikke database-migrations som en automatisk del af processen, hvilket også er tydeligt nævnt i Trellis-dokumentationen.

Hvis du arbejder med Acorn, kan du bruge Laravel migrations (migrations = versionsstyrede schema-ændringer) til WordPress-sites og sørge for, at de bliver kørt i forbindelse med deployment. Pointen er, at du stadig skal tænke i backwards compatible schema-ændringer, hvis du vil holde en “ingen nedetid”-oplevelse hele vejen igennem.

Rollback på sekunder: den praktiske gevinst ved immutable releases

Når hver release ligger i sin egen mappe og aldrig modificeres efter deploy, bliver rollback pludselig trivielt: du peger bare current tilbage på den forrige release.

trellis rollback production

trellis rollback production

Trellis beholder som standard flere af de seneste releases på serveren, så rollback ikke kræver en ny build eller re-upload. Det er i praksis en af de største forbedringer i driftssikkerhed, du kan få for WordPress.

Deploy hooks: gør deployment til et kontrolleret flow

Trellis har et sæt hooks (hooks = indstikspunkter i processen), så du kan koble egne tasks på før/efter bestemte deploy-trin. Blandt andet findes der hooks til build- og finalize-faserne, og derudover hooks omkring de større deploy steps (initialize, update, prepare, build, share, finalize).

I praksis betyder det, at du kan standardisere ting, der ellers ofte ligger som manuelle tjeklister:

• Tage database-backup lige inden der skiftes release
• Rydde caches efter deploy (page cache, object cache osv.)
• Sende en deployment-notifikation til teamet
• Køre simple smoke tests mod den nye release

Kom i gang: minimal opskrift til zero downtime deploys

Hvis du vil i gang uden at vende hele din udviklingsstack på hovedet, er den korte vej typisk:

1. Brug Bedrock for en mere robust projektstruktur og dependency management.
2. Installér Trellis og konfigurér dine deployment-indstillinger.
3. Udfyld wordpress_sites.yml med dit Git-repository (og relevante deploy-settings).
4. Kør trellis deploy production.

Første deploy tager typisk længst tid, fordi serverens struktur og dependencies skal etableres. Derefter handler det primært om, at hver release bygges isoleret og aktiveres atomisk.