CI/CD
CI/CD pipelines og deploy-strategi
Vi bygger CI/CD pipelines der gør det normalt at deploye flere gange om dagen. Tests kører på hver pull request, deploys er forudsigelige, rollbacks tager minutter — ikke et helt møde.
Den vigtigste investering
Det en god pipeline gør for jer
- Hurtige checks på hver pull request
- <5 min
- Preview-environment med database og flags
- Pr. PR
- Rollback er at pege på en tidligere build
- Immutable
- Hvem deployede hvad og hvornår
- Auditerbar
Sådan vi bygger CI/CD
Pipelines der gør det normalt at deploye.
En god CI/CD pipeline er den vigtigste enkeltinvestering et udviklingsteam kan lave. Den siger "vi deployer 6 gange om dagen, og det er kedeligt" i stedet for "vi deployer fredag morgen, og alle holder vejret". Vi har bygget pipelines for små teams (3 udviklere, ét produkt) og store (50 udviklere, 12 services), og mønstrene er forbavsende ens: hurtige tests på hver PR, automatiske deploys til staging, manuelle deploys til produktion med ét klik, og en rollback der virker.
Vi sætter pipelinen op i den platform I allerede bruger — typisk GitHub Actions, men også GitLab CI, CircleCI eller Buildkite. Vi gør tests hurtige (parallel-kørsel, caching, kun det der er ændret), gør deploys forudsigelige (immutable artifacts, ingen "works on my machine"), og gør rollbacks trivielle (genskab den forrige immutable artifact i stedet for at "revert" en commit i panik).
Vi tager også hånd om de skarpe kanter: secrets management uden at kopiere .env til Slack, preview-environments pr. PR uden at sprænge cloud-budgettet, branch-strategi der passer til jeres team-størrelse, og release-noter der genereres automatisk i stedet for at en stakkels udvikler skriver dem fredag eftermiddag.
Hvad I får leveret
Pipelinen og kulturen omkring den.
Hurtige checks, preview-environments, immutable deploys og rollbacks der virker.
Pipeline-design og opsætning
Vi designer pipelinen ud fra hvad I bygger og hvor stort jeres team er. Workflows pr. branch, kvalitetstjek (typecheck, lint, tests), build-cache, secrets management og deploy-jobs sat op i GitHub Actions, GitLab eller Buildkite.
Preview-environments
Hver pull request får sit eget kørende environment — på Vercel, AWS, eller egen infrastruktur — så reviewere kan klikke rundt i ændringerne i stedet for at læse diff. Med database-seed, feature-flags og automatisk teardown.
Test-strategi
Hurtige unit-tests på hver PR (typisk Vitest eller Jest), integration-tests mod en kørende test-database, end-to-end-tests på de vigtigste flows (Playwright). Vi kører tests parallelt og fail-fast, så feedback-loopet er minutter — ikke en time.
Deploy- og rollback-strategi
Blue/green eller canary-deploys hvor det giver mening. Immutable artifacts (Docker images, Vercel deployments) så rollback er at pege på en tidligere version — ikke at "revert"e en commit. Med deploy-historik der kan auditeres.
Secrets og konfiguration
Secrets ligger i GitHub Actions Secrets, Doppler, AWS Secrets Manager eller HashiCorp Vault — afhængigt af hvad der passer til jer. Aldrig committed til repo, aldrig delt i Slack, og roteret efter en plan I kan stå inde for.
Notifications og release-noter
Slack/Teams-besked når deploys lykkes eller fejler, automatiske release-noter genereret fra Conventional Commits eller PR-titler, og en kort "deploy of the week"-rapport hvis I vil have et overblik.
Inden vi går i gang
Det her bør I overveje først.
Hvor stort skal det være?
En CI/CD-opsætning til et 3-personers team behøver ikke være den samme som en til et 30-personers team. Vi starter med det enkleste der virker — ofte er det en single workflow der bygger, tester og deployer — og udvider når I har et reelt problem at løse. For meget pipeline-kompleksitet for tidligt er en almindelig fejl.
Hastighed kontra grundighed
Tests skal være hurtige nok til at kunne køre på hver PR uden at folk klager. Hvis det tager 25 minutter at se om noget passerer, så går teamet udenom processen. Vi designer pipelinen så hurtige checks (typecheck, lint, unit-tests) returnerer på under 5 minutter og tunge tests (E2E, performance) kører i parallel eller på en cadence du kan stole på.
Cost på preview-environments
Preview-environments er fantastiske, men de kan være dyre — særligt hvis hver PR spinner en database og en kø op. Vi designer dem så de er billige (delt ressource hvor det giver mening, automatisk teardown efter 48 timer, mindre instans-størrelser) eller helt slukker når PR'en lukkes.
Hvem ejer pipelinen efter handover
Vi bygger ikke en pipeline kun jeres devops-konsulent forstår. Workflows er commit'et i jeres repo, dokumentation følger med, og vi kører en handover-session med jeres team. Hvis I vil have os til at vedligeholde og udvide pipelinen løbende, kan vi det også — men det er jeres valg, ikke en lock-in.
FAQ
Det folk plejer at spørge om.
Vi bruger allerede GitHub Actions — kan I bare strømline det?
Ja. Vi laver typisk en pipeline-audit som første skridt: vi gennemgår jeres workflows, ser hvor tiden bruges (test-køretid, build-cache, queue-tid), tjekker secrets-håndtering og deploy-strategien. Du får en prioriteret rapport med konkrete forbedringer og estimater på tidsbesparelse pr. ændring. Vi kan implementere dem for jer eller lade jeres team gøre det.
Hvilken CI-platform bør vi vælge?
GitHub Actions er typisk det rette svar hvis jeres kode ligger på GitHub — det er gratis op til en hvis grænse, ekstremt fleksibelt og har et stort marketplace af actions. GitLab CI er bedre hvis I bruger GitLab end-to-end. Buildkite eller CircleCI giver mening for store teams med specifikke krav til parallel-eksekvering eller egne build-runners. Vi vælger ud fra hvad I allerede bruger og hvor I gerne vil hen.
Hvor lang tid tager det at sætte op?
En grundig CI/CD opsætning fra bunden til et SaaS-produkt af normal størrelse tager typisk 3–6 uger. Det inkluderer pipeline-design, tests-opsætning, preview-environments, deploy-strategi, secrets-håndtering og en handover-session med jeres team. Hvis I allerede har en pipeline der bare skal optimeres, kan vi gøre det på 1–2 uger.
Kan I sætte preview-environments op for vores Next.js-app?
Ja, og det er typisk en af de højest værdsatte ændringer vi laver. Hvis I er på Vercel, er det få timers arbejde at få det rigtigt med database-seed og feature-flags. Hvis I hoster selv (AWS, Cloudflare), bygger vi det med Pulumi eller Terraform så hver PR får sit eget environment med automatisk teardown. Vi designer det så det ikke sprænger jeres cloud-regning.
Hvad med deploys til regulerede miljøer (finans, sundhed)?
Vi har bygget pipelines med strikse change-control-krav: manuel godkendelse fra Change Manager, audit-log på hvem der deployede hvad hvornår, automatiske deploy-vinduer der følger jeres change-policy, og dokumenterede rollback-procedurer. Det er stadig CI/CD — bare med mere ceremoni på de steder hvor compliance kræver det.
Klar til at starte?
Lad os tage en uforpligtende snak.
Vi vender tilbage indenfor en arbejdsdag med konkret input — ikke et standardtilbud.