DevOps & proces
Når vi sætter CI/CD op for et projekt, er preview-deploys næsten altid det første vi konfigurerer — før tests, før linting, før noget andet. Det lyder måske bagvendt, men en klikbar URL på hver pull request ændrer dynamikken i code review mere end nogen test-suite.
Det her handler ikke om at imponere med DevOps-jargon. Det handler om at reducere den tid I bruger på at finde fejl der kunne være fanget tidligere — og om at give ikke-tekniske stakeholders en måde at validere ændringer uden at installere noget lokalt.
TL;DR
De vigtigste pointer
- Preview-deploys på hver PR giver en unik URL hvor ændringen kan testes i en produktionslignende miljø — uden at røre produktion.
- Visuelt review fanger UI-fejl, layout-brud og regressions som unit tests sjældent opdager.
- Stakeholders kan godkende ændringer før merge — det reducerer rework efter deploy.
- Vercel, Netlify og Cloudflare Pages giver preview-deploys out-of-the-box for Next.js og statiske sites.
- En god pipeline kører også lint, type-check og tests — preview-deploys erstatter dem ikke, de supplerer.
Hvad der går galt uden preview-deploys
Uden preview-deploys ser code review typisk sådan ud: udvikleren åbner en PR, reviewer læser diff'en, måske checker de ud lokalt hvis de har tid og det rigtige setup, og merger. Fejl i layout, styling, edge cases i data og integrationer med tredjepartstjenester opdages først i produktion — eller i bedste fald i staging, hvis I har et dedikeret staging-miljø I faktisk bruger.
Problemet forstærkes når teamet vokser eller når stakeholders uden for udvikling skal godkende ændringer. En marketingchef kan ikke reviewe en CSS-ændring i en diff. En product owner kan ikke validere en ny feature uden at køre projektet lokalt. Resultatet er enten blind trust eller langsomme feedback-loops.
Preview-deploys løser begge dele: hver PR får en unik URL, ændringen kan ses og testes med det samme, og feedback kommer inden merge — ikke efter deploy.
Sådan ser en pipeline med preview-deploys ud
Når en udvikler pusher til en feature-branch og åbner en pull request, trigger CI/CD-pipeline automatisk: lint og type-check kører først — det tager typisk under et minut. Hvis det fejler, stopper pipelinen og PR'en kan ikke merges.
Derefter bygger platformen projektet og deployer det til en unik preview-URL — typisk noget i stil med `feature-xyz-projekt.vercel.app`. URL'en postes automatisk som en kommentar på PR'en, så reviewer og stakeholders kan klikke direkte.
Når PR'en merges til main, deployer produktion automatisk. Preview-URL'en kan beholdes i en periode eller slettes — afhængigt af platform og konfiguration. Pointen er: produktion opdateres kun via main, og hver ændring er testet i isolation først.
Preview-deploys vs. traditionelt staging
Dedikeret staging-miljø
Ét fælles miljø hvor alle ændringer testes sekventielt.
- Kendt og velkendt opsætning
- Kan spejle produktion tæt — samme database, samme config
- Kun én version ad gangen — seneste merge overskriver
- Kræver koordination: hvem tester hvornår?
- Ofte forældet eller out-of-sync med produktion
- Manuel deploy eller separat pipeline til staging
Preview-deploys per PR
Unik URL for hver pull request — parallelle miljøer.
- Hver ændring testes i isolation — ingen konflikter
- Automatisk — ingen manuel deploy
- Stakeholders kan reviewe samtidigt uden at vente
- Miljøet oprettes og destrueres automatisk
- Database og secrets kræver ekstra opsætning for fuld paritet
- Platform-afhængig — Vercel, Netlify, Cloudflare Pages
Det I bør have på plads
En minimal CI/CD-pipeline med preview-deploys kræver ikke meget — men disse ting skal være på plads.
- Git-hosting med pull requests (GitHub, GitLab, Bitbucket)
- Deployment-platform med preview-support (Vercel, Netlify, Cloudflare Pages)
- Lint og type-check i CI — fejl blokerer merge
- Miljøvariabler konfigureret for preview-miljøer (API-nøgler, database-URLs)
- Branch protection: main kan kun merges via PR med grøn CI
- Automatisk kommentar på PR med preview-URL (platformen gør det typisk selv)
- Dokumentation så teamet ved at preview-URL'en er der og skal bruges
Database og secrets i preview-miljøer
Den klassiske udfordring med preview-deploys er data: hvis jeres app læser fra en produktionsdatabase, vil preview-deploys enten ramme produktion (farligt) eller fejle (hvis adgang er blokeret). Løsningen afhænger af projektet.
For statiske sites og marketing-sites er det sjældent et problem — der er ingen database. For apps med backend anbefaler vi typisk en dedikeret preview-database med seed-data, eller at preview-deploys peger på en read-only kopi af staging-data. Det kræver ekstra opsætning, men det er det værd.
Secrets håndteres via platformens miljøvariabel-system: produktion-secrets og preview-secrets er adskilt, så en preview-deploy aldrig bruger produktions-API-nøgler til skrivning.
Spørgsmål vi får igen og igen
Hvilken platform anbefaler I til preview-deploys?
For Next.js og statiske sites er Vercel, Netlify og Cloudflare Pages alle gode valg — de giver preview-deploys out-of-the-box med minimal konfiguration. Valget afhænger af jeres eksisterende stack, budget og om I har brug for edge functions, serverless eller dedikeret backend. Vi starter typisk med det I allerede bruger eller det der matcher jeres hosting.
Koster preview-deploys ekstra?
De fleste platforme inkluderer et antal preview-deploys i deres gratis eller basis-planer. Ved mange PR'er og et stort team kan det kræve en betalt plan — men omkostningen er typisk langt lavere end tiden I sparer på at finde fejl i produktion.
Kan vi bruge preview-deploys med vores egen server?
Ja, men det kræver mere opsætning. Docker-baserede løsninger som GitHub Actions med deploy til en container-platform kan give preview-miljøer, men det er ikke out-of-the-box som Vercel eller Netlify. For teams der allerede kører egen infrastruktur kan det give mening — ellers er en managed platform ofte den hurtigere vej.
Hvad med E2E-tests — skal de køre mod preview-URL'en?
Det kan de, og det er en god idé for kritiske flows. Playwright og Cypress kan køre mod preview-URL'en i CI og fange regressions automatisk. Det tilføjer tid til pipelinen, så vi anbefaler det typisk for checkout, login og andre flows hvor fejl er dyre — ikke for hver kosmetisk ændring.
Hvor lang tid tager det at sætte op?
For et Next.js-projekt på Vercel er preview-deploys typisk aktivt indenfor en arbejdsdag — connect repo, konfigurer miljøvariabler, sæt branch protection op. Mere komplekse setups med database-seeding, E2E-tests og custom domains til previews tager længere, men grundlaget er hurtigt at få på plads.
Hvis I vil have CI/CD sat op rigtigt
Vi tager gerne en snak om jeres nuværende pipeline.
Skriv et par linjer om hvad I kører i dag — hosting, git-flow, hvor fejl typisk opdages — så vender vi tilbage med en konkret vurdering af hvad der giver mest værdi at ændre først.