CI/CD: hvad det er, hvem der kan det, og hvad de tjener

CI/CD-færdighed er evnen til at automatisere vejen fra en kodeændring til en testet og kontrolleret softwareleverance. CI står for continuous integration. CD bruges om continuous delivery eller continuous deployment afhængigt af, hvor langt automatiseringen går.

En person med CI/CD-færdigheder kan bygge pipelines, der reagerer på ændringer i et Git-repository. Pipeline kan eksempelvis hente kildekoden, installere afhængigheder, bygge applikationen, køre tests, kontrollere kodekvalitet og producere et deployerbart artifact.

Continuous integration handler især om at integrere ændringer ofte og kontrollere dem automatisk. Når en udvikler opretter eller opdaterer en pull request eller merge request, kan pipeline kontrollere, om koden bygger, om tests består, og om andre automatiske kvalitetskrav er opfyldt.

Continuous delivery går videre og gør en godkendt version klar til deployment gennem en gentagelig proces. Continuous deployment betyder normalt, at godkendte ændringer kan deployes automatisk uden et manuelt release-trin.

En stærk person med CI/CD-kompetencer kan strukturere pipelines i jobs og stages og styre, hvilke trin der må køre parallelt eller først efter andre trin. Vedkommende forstår dependencies mellem build, test, package og deployment frem for blot at samle kommandoer i én lang pipeline.

Artifacts er en vigtig del af arbejdet. Den version, der bliver testet, bør kunne føres videre til deployment, så produktionsmiljøet ikke får en tilfældigt genbygget version. Personen forstår derfor sammenhængen mellem kildekode, build-output, container-images, packages og releases.

Færdigheden omfatter også environments. Development, test, staging og production kan have forskellige regler, secrets og godkendelser. En erfaren person kan designe flowet, så ændringer bevæger sig kontrolleret mellem miljøerne.

Secrets og credentials kræver særlig opmærksomhed. CI/CD-færdighed indebærer, at adgangsnøgler og passwords ikke lægges direkte i pipelinefiler eller kode. Vedkommende kan bruge platformens secret management og, hvor det passer, kortlivede identiteter som OpenID Connect til adgang til cloud-platforme.

Runners eller agents er også en del af kompetencen. Det er de systemer, som udfører pipeline-jobbene. En person med CI/CD-kompetencer forstår forskellen mellem hostede og self-hosted runners og kan vurdere netværk, sikkerhed, kapacitet og softwarekrav omkring dem.

CI/CD-færdighed omfatter fejlhåndtering. Når en pipeline fejler, skal personen kunne skelne mellem en fejl i applikationen, testen, build-miljøet, credentials, netværket eller selve pipeline-konfigurationen.

På et højere niveau handler CI/CD også om sikker softwareleverance. Pipelines kan indeholde dependency scanning, code scanning, container scanning, policy checks og andre kontroller. Den erfarne person placerer kontrollen dér, hvor den giver mening, uden at gøre leveranceprocessen unødigt langsom eller ustabil.

GitHub Actions, GitLab CI/CD og Azure Pipelines er eksempler på udbredte platforme. Jenkins bruges også mange steder. Den grundlæggende CI/CD-færdighed er dog overførbar. En stærk person forstår principperne og kan lære en ny pipelineplatform uden at begynde helt forfra.

Det vigtigste tegn på CI/CD-færdighed er derfor ikke kendskab til YAML. Det er evnen til at skabe en leveranceproces, hvor software kan bygges, testes, spores og deployes på en forudsigelig måde.

CI/CD-færdigheden er vigtig, når software ændres regelmæssigt og skal leveres uden en stor manuel proces hver gang.

Færdigheden gør en forskel i udviklingsteams, hvor flere personer arbejder på samme kodebase. Automatiske builds og tests gør det lettere at opdage problemer, når ændringen introduceres, frem for senere under en større release.

CI/CD er også vigtigt, når virksomheden vil kunne deploye oftere. Hvis release kræver en lang række manuelle kommandoer og individuelle huskeregler, bliver leverancer langsommere og mere afhængige af bestemte personer.

Ved cloud- og containerløsninger er kompetencen ofte central. Applikationer skal bygges til packages eller container-images og derefter deployes til den relevante platform gennem en kontrolleret proces.

CI/CD gør også en forskel i regulerede eller sikkerhedskritiske miljøer. Her kan pipeline give sporbarhed mellem kodeændring, review, testresultater, artifact og deployment. Manuelle godkendelser kan indgå dér, hvor organisationens proces kræver dem.

Færdigheden er vigtig ved større platformsmiljøer. Et platformteam kan udvikle genbrugelige workflows og templates, så hvert udviklingsteam ikke skal opfinde sin egen build- og deploymentproces.

CI/CD spiller også en rolle ved Infrastructure as Code. Terraform, Bicep eller anden infrastrukturkode kan gennemgå plan, validering og deployment gennem en pipeline på samme måde som applikationskode.

Når produktionen fejler efter en release, er CI/CD-kompetence vigtig for at kunne identificere præcis, hvilken version der blev deployet, hvilke ændringer den indeholdt, og hvordan en sikker rollback eller ny rettelse gennemføres.

Typiske roller er DevOps Engineer, Platform Engineer, Software Engineer, Site Reliability Engineer, Cloud Engineer og Build eller Release Engineer. CI/CD er samtidig en vigtig færdighed for mange udviklere, selv om de ikke har DevOps i jobtitlen.

CI/CD læres bedst ved at tage en lille rigtig applikation og automatisere hele leverancevejen. Start med kildekoden i Git og få en pipeline til automatisk at bygge og teste projektet ved en ændring.

GitHub Actions har officielle guides til continuous integration og continuous deployment. De viser blandt andet workflows, triggers, jobs, runners, tests, environments og deployments. Det er et godt udgangspunkt, hvis projektet ligger på GitHub.

GitLab CI/CD er et andet relevant læringsmiljø. Her defineres pipelines typisk i en .gitlab-ci.yml-fil med jobs, stages, runners, variables, caching og artifacts. GitLabs officielle tutorials kan bruges til at bygge en pipeline fra bunden og forstå, hvordan runneren udfører arbejdet.

Azure Pipelines er relevant i organisationer, der bruger Azure DevOps. Microsofts dokumentation viser, hvordan YAML-pipelines kan struktureres med build, test og deployment til forskellige environments.

Efter den første fungerende pipeline bør man bevidst få den til at fejle. Lav en testfejl. Brug en manglende secret. Bryd en dependency. Fjern adgang til et deployment-miljø. Undersøg logs og find den egentlige årsag. Fejlfinding er en stor del af professionelt CI/CD-arbejde.

Derefter bør man arbejde med artifacts. Byg én version, gem den og deploy den samme version gennem miljøerne. Det træner forståelsen af reproducerbare releases og gør det tydeligt, hvorfor build og deployment ikke bør blandes sammen uden omtanke.

Træn også deployment-regler. Beskyt produktionsmiljøet. Tilføj relevante godkendelser. Undersøg, hvordan rollback fungerer. Målet er ikke at tilføje flest mulige gates, men at forstå hvor kontrol faktisk reducerer risiko.

Secrets bør trænes tidligt. Flyt credentials ud af kode og pipelinefiler. Brug platformens secrets og undersøg workload identity eller OpenID Connect, når cloud-platformen understøtter det.

Når grundprincipperne fungerer, kan man arbejde med genbrugelige workflows eller pipeline-templates. Det er vigtigt i større miljøer, hvor mange repositories skal følge de samme grundlæggende standarder.

Det er også nyttigt at arbejde med performance. Langsomme pipelines bliver ofte omgået. Lær derfor caching, parallelisering og opdeling af tests, men optimér først når pipeline er korrekt og forståelig.

Et kort kursus kan lære syntax og platformens funktioner. Professionel CI/CD-færdighed kommer gennem rigtige builds, fejlede releases, credentials, ustabile tests, runner-problemer og situationer, hvor en produktionsændring skal gennemføres eller rulles tilbage sikkert.

Bed personen tegne eller forklare en pipeline fra commit til produktion. En erfaren kandidat kan beskrive triggers, build, tests, artifacts, environments, deployment og håndtering af fejl som én sammenhængende leveranceproces.

Spørg hvad forskellen er på continuous delivery og continuous deployment. En stærk kandidat kan forklare forskellen uden at gøre den afhængig af et bestemt produktnavn.

Giv kandidaten et scenarie, hvor en pipeline virker lokalt hos udvikleren, men fejler på runneren. Personen bør undersøge forskelle i runtime, dependencies, environment variables, permissions, netværk og build-miljø frem for straks at ændre pipeline tilfældigt.

Spørg hvordan secrets håndteres. En erfaren person vil undgå langtidscredentials direkte i kode eller YAML og kan forklare secret stores, adgangsbegrænsning og kortlivede identiteter, når platformen understøtter det.

Bed kandidaten forklare, hvorfor artifacts er vigtige. Personen bør forstå værdien af at deploye den samme testede build frem for at bygge en ny version ved hvert miljøskift.

Et godt spørgsmål er, hvad kandidaten gør, hvis deployment lykkes teknisk, men applikationen ikke virker korrekt bagefter. En stærk profil vil tænke på health checks, logs, metrics, smoke tests, rollback og den konkrete brugeroplevelse frem for kun pipeline-status.

Spørg også hvordan en pipeline kan gøres sikker uden at blive så langsom, at udviklerne forsøger at omgå den. Det viser, om kandidaten forstår trade-offs mellem kontrol, feedbackhastighed og udvikleroplevelse.

Ved seniorprofiler bør man spørge, hvordan CI/CD standardiseres på tværs af mange teams. Et godt svar kan handle om templates, reusable workflows, fælles security controls, platform services og klare grænser for, hvad teams selv kan ændre.

Se efter praktisk erfaring med fejl. En kandidat, der reelt har drevet CI/CD, kan normalt fortælle om en build, der var ustabil, en credential der udløb, en runner der opførte sig anderledes end forventet eller en release der måtte rulles tilbage.

Det stærkeste tegn på CI/CD-færdighed er, at personen kan gøre softwareleverancer kedeligt forudsigelige. Koden bliver bygget, kontrolleret, pakket og deployet gennem en proces, som teamet forstår, kan fejlfinde og kan stole på.