CI/CD-pipeline från scratch – steg för steg

Vi blir ofta inkopplade när ett svenskt team har en pipeline som "typ fungerar" — den bygger, den testar, men den tar 25 minuter, misslyckas slumpmässigt en gång i veckan av oklar anledning, och ingen litar riktigt på den grönt tecken den ger. Att bygga en CI/CD-pipeline från scratch är inte svårt tekniskt sett — GitHub Actions, GitLab CI och Gitea Actions är alla mogna 2026 — men det kräver att man tänker igenom stegen i rätt ordning och sätter gränser för vad varje steg faktiskt ska ansvara för.

Den här guiden går igenom hur vi bygger pipelines från grunden: struktur och steg, testautomation, container-byggen med cache, säkerhetsscanning, och deploymentstrategier för flera miljöer.

Pipelinestruktur — vad ska köras var

En bra pipeline har tydligt separerade faser: lint och statisk analys (snabbast, kör alltid först och avbryt tidigt vid fel), enhetstester, bygg av artefakter (container-image eller paket), säkerhetsscanning, integrationstester mot en riktig miljö, och till sist deploy. Kör faser parallellt där det går — lint och enhetstester har normalt ingen beroenderelation och kan köras samtidigt, vilket kan halvera pipelinens totala körtid.

Ett vanligt misstag är att bygga en enda lång pipeline som gör allt sekventiellt för varje commit, inklusive tunga integrationstester mot en delad testmiljö. Separera istället "snabb feedback" (lint, enhetstester, bygg — under 5 minuter, körs på varje push) från "djup validering" (integrationstester, säkerhetsscan, prestandatester — kan ta 15-20 minuter, körs på pull request mot huvudgren eller nattligen). Det håller utvecklarloopen snabb utan att kompromissa med kvalitetskontrollen innan merge.

Testautomation — vilken nivå betalar sig

Testpyramiden är fortfarande relevant 2026, men vi ser många team som investerar fel — en handfull ytliga end-to-end-tester som är sköra och tar tio minuter att köra, men få eller inga enhetstester på affärslogiken. Riktvärdet vi rekommenderar: 70 procent enhetstester (snabba, isolerade, testar en funktion eller klass), 20 procent integrationstester (testar samspelet mellan komponenter, t.ex. API mot databas), och 10 procent end-to-end (testar hela flödet genom UI eller extern API, med Playwright eller Cypress).

Sätt en täckningsgräns som en kvalitetsgrind i pipelinen — men var försiktig med att jaga 100 procent täckning, det leder ofta till meningslösa tester som bara finns för att öka en siffra. 75-85 procent täckning på affärskritisk kod med fokus på faktisk risk är ett bättre mål än ett godtyckligt högt tal överallt. Kör flaky-testdetektion (upprepa misstänkta tester 3-5 gånger innan de får fälla pipelinen) — vi har sett team tappa förtroendet för hela CI-systemet på grund av ett enda instabilt test som ingen orkat fixa.

Container-byggen som inte tar 15 minuter

Om ni bygger container-images är byggtiden ofta den enskilt största tidstjuven i pipelinen. Multi-stage Dockerfiles minskar slutstorleken och separerar byggberoenden från runtime, men den stora vinsten kommer från lagercache. Använd BuildKit med registry-cache (--cache-from/--cache-to) så att oförändrade lager (typiskt npm ci eller pip install-steget) återanvänds mellan körningar istället för att byggas om varje gång.

Ordna Dockerfile-instruktioner så att det som ändras minst (beroendeinstallation) kommer före det som ändras mest (applikationskod). Vi har sett byggtider gå från 12 minuter till under 90 sekunder enbart genom rätt lagerordning och registry-cache. För monorepos, bygg bara det som faktiskt ändrats — verktyg som Nx, Turborepo eller egna path-filter i CI sparar enorm tid när bara en av tio tjänster i repot faktiskt behöver byggas om.

Säkerhetsscanning — inte bara en grön bock

2026 förväntar sig de flesta kunder och revisorer att pipelinen innehåller automatiserad säkerhetsscanning, men vi ser fortfarande gott om "dekorativa grindar" — Trivy eller Snyk körs, men pipelinen är konfigurerad att aldrig faktiskt fälla bygget oavsett resultat. Konfigurera scanning i minst tre lager: SAST på källkoden (Semgrep, CodeQL), beroende-scanning (Dependabot, Snyk, eller npm audit i CI), och image-scanning på den färdiga container-imagen (Trivy eller Grype).

Sätt en tydlig policy för vad som faktiskt fäller bygget — kritiska och höga sårbarheter med tillgänglig fix bör blockera merge till huvudgren, medan lägre allvarlighetsgrad kan flaggas utan att stoppa flödet. Granska regelbundet att grinden faktiskt fungerar genom att medvetet introducera en känd sårbarhet i en testgren och verifiera att pipelinen fäller den. Läs mer om hur vi jobbar med säkerhet i CI/CD under cybersäkerhet.

Deployment-strategier för flera miljöer

Sista steget är att faktiskt leverera koden säkert. Rolling deploy är standard och räcker för de flesta interna verktyg, men för kundvända tjänster med krav på hög tillgänglighet rekommenderar vi blue-green eller canary-deploy. Canary-deploy — där en ny version rullas ut till en liten andel trafik (5-10 procent) innan full utrullning — ger er tidig varning om en regression innan alla användare drabbas, kombinerat med automatiska metrics-baserade rollback-triggers.

Koppla ihop deploy med observability: om felfrekvensen eller svarstiden försämras signifikant efter en deploy ska pipelinen (eller en separat kontroller som Argo Rollouts) rulla tillbaka automatiskt utan mänsklig inblandning. Vi går igenom hur man sätter upp den kopplingen i vår artikel om observability i praktiken, och hur pipelinen kan trigga deploy till en Kubernetes-plattform byggd enligt vår guide om Terraform och Kubernetes.

Vår rekommendation

Bygg pipelinen i den ordning vi beskrivit ovan — lint och test först för snabb feedback, sedan bygg, säkerhetsscan och deploy som separata, tydligt avgränsade steg. Mät pipelinens egen prestanda (byggtid, flaky-testfrekvens, tid till produktion) lika noggrant som ni mäter applikationens — en pipeline som tar 25 minuter och misslyckas slumpmässigt kostar er mer utvecklartid per år än de flesta funktionsprojekt. För team som bygger sin första pipeline från grunden rekommenderar vi att börja enkelt (lint, test, bygg, deploy till en miljö) och lägga till säkerhetsscanning och canary-deploy när grunden är stabil, snarare än att försöka bygga allt på en gång.

Vi hjälper svenska team bygga och modernisera CI/CD-pipelines, från grundstruktur till avancerad deploymentstrategi — läs mer om våra tjänster eller boka ett samtal.