CI/CD Pipelines (GitHub Actions / GitLab CI)

Hvad bruges CI/CD Pipelines (GitHub Actions / GitLab CI) til? CI/CD-pipelines automatiserer vejen fra en kodeændring til testet og eventuelt udrullet software. GitHub Actions og GitLab CI/CD er to udbredte platforme til at bygge den automatisering direkte omkring virksomhedens kode.

CI står for continuous integration. Når en udvikler ændrer kode, kan pipelinen automatisk bygge programmet og køre de aftalte kontroller. Det kan være kodekontrol, unit tests, integrationstests og sikkerhedsscanninger. Fejler en vigtig kontrol, kan ændringen stoppes, før den bliver flettet eller udrullet.

CD handler om den efterfølgende levering eller udrulning. En godkendt version kan eksempelvis pakkes som en applikation eller et container-image og sendes videre til et test-, staging- eller produktionsmiljø. Virksomheden vælger selv, om produktion skal ske automatisk eller først efter en manuel godkendelse.

GitHub Actions beskriver automatiseringen som workflows i YAML-filer i kodearkivet. Jobbene kan køre på GitHub-hostede maskiner eller virksomhedens egne runners. GitLab CI/CD bruger normalt filen .gitlab-ci.yml, hvor jobs og stages beskriver eksempelvis build, test og deployment. Jobbene udføres af GitLab Runners.

En pipeline kan derfor erstatte mange manuelle trin. Udvikleren behøver ikke huske en bestemt række kommandoer hver gang. Samme proces køres på samme måde, og resultatet kan ses sammen med kodeændringen.

I moderne cloudmiljøer bruges CI/CD også til container-builds, Kubernetes-deployments, Infrastructure as Code, pakkeudgivelser og ændringer i cloudinfrastruktur. Pipelines bliver dermed en vigtig del af både softwareudvikling og drift.

GitHub Actions og GitLab CI/CD har desuden funktioner til deployment-miljøer, secrets, adgangskontrol og genbrugelige pipelinekomponenter. Det gør det muligt at standardisere, hvordan forskellige udviklingsteams bygger og udruller software.

Hvem bruger CI/CD Pipelines (GitHub Actions / GitLab CI)? CI/CD-pipelines bruges især af softwareudviklere, DevOps Engineers, Platform Engineers, Site Reliability Engineers, Cloud Engineers og Release Engineers. QA- og testautomatiseringsspecialister arbejder også ofte direkte i pipelines, fordi automatiske tests skal indgå i samme proces som build og deployment.

DevSecOps- og sikkerhedsfolk bruger pipelines til at placere sikkerhedskontroller tidligere i udviklingsprocessen. Det kan være scanning af kildekode, dependencies, container-images eller andre softwareartefakter før en release.

I danske virksomheder ses GitHub Actions og GitLab CI/CD blandt andet omkring cloudplatforme, containerbaserede applikationer, Kubernetes, websystemer og interne forretningssystemer. Værktøjerne bruges både af produktvirksomheder, SaaS-virksomheder, konsulenthuse og større organisationer med egne udviklingsteams.

GitHub Actions er naturligt tæt integreret med repositories, pull requests og andre GitHub-funktioner. GitLab CI/CD er tilsvarende tæt integreret med GitLabs merge requests, environments, runners og øvrige DevSecOps-funktioner.

Små udviklingsteams kan have få simple workflows. Større organisationer har ofte fælles pipeline-skabeloner, selv-hostede runners, centrale sikkerhedspolitikker og mange miljøer. Her bliver CI/CD en platformopgave snarere end blot nogle få scripts i hvert kodeprojekt.

Typiske opgaver for en specialist i CI/CD Pipelines (GitHub Actions / GitLab CI) En klassisk specialistopgave er at erstatte en manuel build- og releaseproces med en reproducerbar pipeline. Specialisten kortlægger først de trin, udviklerne udfører manuelt. Derefter automatiseres build, test, pakning og deployment i GitHub Actions eller GitLab CI/CD.

Fejlsøgning er en anden stor opgave. En pipeline kan fejle på grund af forkerte YAML-regler, manglende rettigheder, ændrede dependencies, runner-problemer, netværksadgang, secrets eller forskelle mellem udviklerens maskine og pipeline-miljøet. Specialisten bruger joblogs og pipelinehistorik til at isolere fejlen.

Langsomme pipelines bliver også optimeret. Det kan ske ved at cache dependencies, genbruge build-artefakter, køre uafhængige jobs parallelt og undgå unødvendige builds. I GitLab kan jobafhængigheder og mere avancerede pipelinearkitekturer bruges til at undgå unødvendig sekventiel behandling. GitHub Actions understøtter blandt andet caching, matrices og genbrugelige workflows.

Migrering forekommer typisk, når en virksomhed vil væk fra eksempelvis Jenkins, CircleCI, Azure DevOps eller en anden ældre CI/CD-løsning. Opgaven er ikke blot at oversætte konfigurationsfiler. Credentials, runners, artefakter, miljøer, approvals, integrationspunkter og releaseprocesser skal også flyttes eller redesignes.

En specialist kan etablere deployment til Azure, AWS, Google Cloud, Kubernetes eller virksomhedens egne servere. Arbejdet omfatter ofte miljøadskillelse, godkendelser, rollback-strategier og håndtering af de credentials, som pipelinen behøver.

Sikkerhed i pipelines er et selvstændigt specialistområde. GitHub anbefaler blandt andet mindst mulige rettigheder til workflow-tokens og mulighed for OpenID Connect, så cloudadgang kan etableres uden langlivede cloudcredentials. GitHub anbefaler også at fastlåse tredjeparts-actions til en fuld commit-SHA, når man vil have en uforanderlig version.

GitLab anbefaler, at følsomme oplysninger ikke lægges direkte i .gitlab-ci.yml. GitLab understøtter blandt andet beskyttede og maskerede CI/CD-variabler, eksterne secrets-systemer og OIDC-baserede ID tokens til adgang til eksterne tjenester.

Større virksomheder hyrer også CI/CD-specialister til standardisering. I stedet for at hvert team opfinder sin egen pipeline, etableres genbrugelige GitHub-workflows eller GitLab CI/CD-komponenter og templates. Det kan gøre sikkerhed, deployment og kvalitetstjek mere ensartede på tværs af mange repositories.

Self-hosted runners kræver særlig kompetence. Her skal virksomheden selv forholde sig til kapacitet, netværk, software, isolation, patching og sikker adgang til interne systemer. Runner-arkitekturen bliver især vigtig, når pipelines skal nå ressourcer, der ikke er tilgængelige fra offentlige cloud-runners.

Komplekse GitLab-miljøer kan desuden bruge parent-child pipelines og multi-project pipelines. Det er relevant, når en løsning består af mange komponenter eller ligger i et monorepo. Specialisten designer her afhængighederne, så kun de nødvendige dele bygges og testes.

Hvordan lærer man CI/CD Pipelines (GitHub Actions / GitLab CI)? Den bedste start er praktisk erfaring med Git, YAML og almindelige build- og testkommandoer. En pipeline automatiserer eksisterende udviklingsarbejde. Det er derfor svært at designe en god pipeline uden at forstå, hvordan applikationen bygges, testes og køres uden for CI/CD-systemet.

GitHub Actions Documentation er den primære officielle reference til GitHub Actions. Quickstarts og dokumentationen om continuous integration gennemgår workflows, events, jobs, steps og runners. Herefter er deployment, reusable workflows, environments, caching og sikkerhed naturlige næste områder.

Microsoft Learn har den officielle læringssti Automate your workflow with GitHub Actions. Den kombinerer forklaring med praktiske øvelser i workflows, continuous integration, deployment og GitHub-automatisering.

GitHub Actions Certification er GitHubs officielle certificering for området. Den retter sig mod personer, der arbejder med workflow-opbygning, fejlsøgning, actions, enterprise-administration samt sikker og effektiv automatisering. Certificeringen er relevant som dokumentation af produktkendskab, men praktisk pipelineerfaring er stadig afgørende.

For GitLab er Get started with GitLab CI/CD og den officielle CI/CD YAML reference de centrale kilder. En god praktisk øvelse er at opbygge en pipeline med build, automatiske tests og deployment og derefter arbejde videre med artifacts, cache, rules, environments og runners.

GitLab tilbyder også GitLab CI/CD Training og GitLab Advanced CI/CD Training gennem GitLab Education Services. GitLab University har desuden selvstyret undervisningsmateriale.

GitLab Certified CI/CD Associate er GitLabs officielle certificering målrettet pipelineforståelse og praktisk CI/CD-arbejde. Den dækker blandt andet de centrale komponenter i en pipeline og opbygning af test-, build-, review- og deploymentflows.

Der findes ikke én universel CI/CD-certificering, som erstatter erfaring med de konkrete platforme. Den stærkeste læringsvej er normalt at bygge rigtige pipelines, fejlfinde dem og arbejde med deployment, runners, secrets og sikkerhed i et realistisk projekt.