Quick Answer
En CI/CD- pipeline är en automatiserad kedja av steg som tar kod från en utvecklares maskin till produktion på ett upprepningsbart sätt. CI står för kontinuerlig integration och handlar om att bygga, testa och kvalitetssäkra varje kodändring. CD står för kontinuerlig leverans eller kontinuerlig driftsättning och hanterar paketering, godkännanden och utrullning till olika miljöer. Definition Kontinuerlig integration innebär att utvecklare regelbundet integrerar kod i en gemensam huvudgren, ofta flera gånger per dag, och att varje integration verifieras av en automatiserad bygg- och testcykel. Målet är att upptäcka integrationsfel tidigt och hålla huvudgrenen i ett släppbart skick. Kontinuerlig leverans ( Continuous Delivery ) betyder att varje godkänd ändring automatiskt görs redo att driftsättas, men att själva produktionsutrullningen kräver ett manuellt godkännande. Kontinuerlig driftsättning (Continuous Deployment) går ett steg längre och rullar ut till produktion utan manuellt steg, så snart alla automatiska kontroller är gröna.
En CI/CD-pipeline är en automatiserad kedja av steg som tar kod från en utvecklares maskin till produktion på ett upprepningsbart sätt. CI står för kontinuerlig integration och handlar om att bygga, testa och kvalitetssäkra varje kodändring. CD står för kontinuerlig leverans eller kontinuerlig driftsättning och hanterar paketering, godkännanden och utrullning till olika miljöer.
Definition
Kontinuerlig integration innebär att utvecklare regelbundet integrerar kod i en gemensam huvudgren, ofta flera gånger per dag, och att varje integration verifieras av en automatiserad bygg- och testcykel. Målet är att upptäcka integrationsfel tidigt och hålla huvudgrenen i ett släppbart skick.
Kontinuerlig leverans (Continuous Delivery) betyder att varje godkänd ändring automatiskt görs redo att driftsättas, men att själva produktionsutrullningen kräver ett manuellt godkännande. Kontinuerlig driftsättning (Continuous Deployment) går ett steg längre och rullar ut till produktion utan manuellt steg, så snart alla automatiska kontroller är gröna.
Typiska steg i en pipeline
| Steg | Syfte | Exempel på verktyg |
|---|---|---|
| Källa | Trigger vid commit eller pull request | GitHub, GitLab, Bitbucket |
| Bygg | Kompilera, lösa beroenden, skapa artefakter | Maven, Gradle, npm, Docker |
| Test | Enhetstester, integrationstester, kontraktstester | JUnit, pytest, Playwright |
| Säkerhetsskanning | SAST, beroendeskanning, container-skanning | Snyk, Trivy, SonarQube |
| Artefakt | Versionera och lagra byggresultat | Artifactory, GHCR, ECR |
| Driftsättning | Rulla ut till test, staging och produktion | Argo CD, Octopus, Spinnaker |
| Verifiering | Smoke-tester, hälsokontroller, observability | Prometheus, Datadog, k6 |
Behöver ni hjälp med cloud?
Boka ett kostnadsfritt 30-minuters möte med en av våra specialister inom cloud. Vi analyserar ert behov och ger konkreta rekommendationer — helt utan förpliktelse.
Bästa praxis
Bygg artefakten en gång och flytta samma artefakt genom alla miljöer. Det eliminerar risken att test- och produktionsversionen skiljer sig åt på grund av nya beroenden eller olika byggparametrar. Använd miljöspecifik konfiguration som injiceras vid driftsättning.
Inför kvalitetsgrindar som stoppar pipelinen om kodtäckning, sårbarheter eller licensproblem överstiger tröskelvärden. Grindarna ska vara objektiva och dokumenterade så att utvecklare vet vad som krävs för att gå vidare. Mät ledtid och felfrekvens enligt DORA-måtten för att se om pipelinen faktiskt accelererar leveransen.
Tänk på rollback från start. Blue-green, kanariefördelning och feature flags ger möjlighet att backa ut snabbt om något går fel i produktion utan att hela utrullningen behöver återkallas. Hantera hemligheter med en vault, aldrig i klartext i repot eller pipelinevariabler.
Vanliga fallgropar
För långa pipelines som tar 45 minuter eller mer dödar feedback-loopen. Parallellisera tester och cacha beroenden för att hålla tiden under 15 minuter för det vanliga fallet. Sköra tester som ibland misslyckas av slumpmässiga skäl undergräver förtroendet, åtgärda dem omedelbart eller karantänsätt dem.
Manuella godkännandesteg som alltid får ja blir snabbt en formalitet. Antingen automatisera bort dem eller gör godkännandet meningsfullt med tydlig information om vad som ändrats och vilken risk det innebär.
Så hjälper Opsio
Opsio designar, implementerar och driver CI/CD-plattformar för team som vill leverera oftare med högre kvalitet. Vi arbetar med GitHub Actions, GitLab, Azure DevOps och Jenkins, och integrerar säkerhetsskanning, IaC-validering och GitOps-driftsättning. Läs mer om våra DevOps-tjänster, eller hur vi kommer igång med CI/CD, eller kontakta oss för en mognadsanalys.
Vanliga frågor
Vad är skillnaden mellan Continuous Delivery och Continuous Deployment?
Continuous Delivery innebär att koden alltid är redo att driftsättas, men ett manuellt steg krävs för att rulla ut till produktion. Continuous Deployment automatiserar även det sista steget, så att varje godkänd ändring rullas ut direkt. Valet beror på regulatoriska krav, riskaptit och teamets mognad.
Behöver vi en pipeline för varje tjänst?
Vanligtvis ja. Varje tjänst eller mikrotjänst får en egen pipeline så att utrullningar är oberoende och felisolerade. Återanvänd däremot pipeline-mallar och delade bibliotek så att teamen inte uppfinner hjulet på nytt för varje repo.
Hur passar säkerhet in i pipelinen?
Shift left genom att köra SAST, beroendeanalys och hemlighetsskanning vid varje pull request, och DAST eller container-skanning i staging-steget. Resultaten ska vara åtgärdsbara, inte bara rapporterande. Se även cloud security, SOC, MDR och penetrationstester.
Vilken roll spelar GitOps i CI/CD?
GitOps hanterar typiskt CD-delen, alltså driftsättning. CI bygger artefakten och uppdaterar en deklarativ manifestfil i Git, sedan reconcilerar en GitOps-controller som Argo CD eller Flux klustret mot manifest. Läs mer om hur GitOps fungerar.
Hur mäter vi om vår pipeline är bra?
De fyra DORA-måtten är en bra start: leveransfrekvens, ledtid från commit till produktion, andel misslyckade ändringar och tid till återställning. Komplettera med pipeline-tid, andel skakiga tester och mean time to detect för att få en helhetsbild.
Written By
Innovationschef
Jacob leder innovationen på Opsio och är specialiserad på digital transformation, AI, IoT och molndrivna lösningar som omvandlar komplex teknik till mätbart affärsvärde. Med nästan 15 års erfarenhet arbetar han nära kunder för att utforma skalbara AI- och IoT-lösningar, effektivisera leveransprocesser och skapa teknikstrategier som driver hållbar tillväxt och långsiktig affärsnytta.
Editorial standards: Denna artikel är skriven av molnpraktiker och granskad av vårt ingenjörsteam. Vi uppdaterar innehållet kvartalsvis. Opsio upprätthåller redaktionellt oberoende.