{"id":127,"date":"2025-10-02T00:00:00","date_gmt":"2025-10-01T22:00:00","guid":{"rendered":"https:\/\/helloblog.io\/da\/zero-downtime-wordpress-deployments-med-trellis\/"},"modified":"2026-01-20T06:33:20","modified_gmt":"2026-01-20T05:33:20","slug":"zero-downtime-wordpress-deployments-med-trellis","status":"publish","type":"post","link":"https:\/\/helloblog.io\/da\/zero-downtime-wordpress-deployments-med-trellis\/","title":{"rendered":"Zero downtime WordPress-deployments med Trellis: s\u00e5dan virker atomic releases i praksis"},"content":{"rendered":"\n

I moderne app-udvikling er zero downtime deployments<\/em> efterh\u00e5nden baseline: nye versioner bliver gjort klar ved siden af den k\u00f8rende version, og der skiftes over i \u00e9t hug. I WordPress-verdenen ser jeg stadig masser af deploy-flows, der reelt er \u201ckopi\u00e9r filer op og kryds fingre\u201d. Roots\u2019 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.<\/p>\n\n\n\n

Det interessante er, at du ikke beh\u00f8ver at adoptere Trellis til hele din udviklingsworkflow for at f\u00e5 v\u00e6rdien. Mange bruger Trellis prim\u00e6rt som deploy-v\u00e6rkt\u00f8j til Bedrock-baserede projekter, mens de forts\u00e6tter lokalt med fx Valet, Lando eller DDEV \u2013 og deployer til alt fra managed hosts til mere klassiske Linux-servere.<\/p>\n\n\n\n

Hvad \u201czero downtime\u201d egentlig betyder i WordPress-kontekst<\/h2>\n\n\n\n

N\u00e5r vi taler zero downtime<\/em>, handler det ikke om, at der aldrig kan opst\u00e5 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.<\/p>\n\n\n\n

Den klassiske WordPress-deploy er ofte \u201cin-place\u201d: filer overskrives direkte i den mappe, webserveren serverer fra. Det kan v\u00e6re hurtigt, men det er ogs\u00e5 den perfekte opskrift p\u00e5 transient fejl, n\u00e5r en request rammer midt i en upload.<\/p>\n\n\n\n

Hvorfor traditionelle WordPress-deploys g\u00e5r galt<\/h2>\n\n\n\n

De fleste WordPress-sites ender i \u00e9n af de her tre deploy-kategorier:<\/p>\n\n\n\n

    \n\n
  • FTP\/SFTP-uploads:<\/strong> Man uploader \u00e6ndringer manuelt og overskriver eksisterende filer. Undervejs serverer sitet en blanding af gammelt og nyt.<\/li>\n\n\n
  • Synkronisering med fx rsync<\/code>:<\/strong> Typisk hurtigere end FTP, men det er stadig \u201coverskriv live filer\u201d, s\u00e5 problemet er det samme.<\/li>\n\n\n
  • Plugin-baseret deployment p\u00e5 managed hosts:<\/strong> Ofte super nemt i UI\u2019et, men mange l\u00f8sninger opdaterer stadig filer in-place og uden en reel rollback-mekanisme.<\/li>\n\n<\/ul>\n\n\n\n

    F\u00e6llesn\u00e6vneren er, at du kan f\u00e5 m\u00e6rkelige fejl under deploy-vinduet, og at rollback typisk er en manuel \u00f8velse (eller i praksis \u201cdeploy igen og h\u00e5b\u201d).<\/p>\n\n\n\n

    Trellis\u2019 l\u00f8sning: atomic og immutable deployments<\/h2>\n\n\n\n

    Trellis deployer ikke ved at overskrive den k\u00f8rende release. I stedet arbejder den med atomic deployments<\/em> (skift i \u00e9t hug) og et immutable<\/em> release-princip (en release \u00e6ndres ikke efter den er lagt ud).<\/p>\n\n\n\n

    Det betyder i praksis, at hver deploy skaber en helt ny release-mappe, g\u00f8r den klar i isolation og skifter derefter webserverens \u201cpegepind\u201d til den nye release. Ingen mellemfaser, hvor brugere ser en halvt opdateret kodebase.<\/p>\n\n\n\n

    Mappestrukturen: \u201ccurrent\u201d, \u201creleases\u201d og \u201cshared\u201d<\/h3>\n\n\n\n

    N\u00e5r Trellis deployer til en server, etablerer den en struktur, der er designet til netop atomic releases:<\/p>\n\n\n\n

    <\/circle><\/circle><\/circle><\/g><\/svg><\/span>