CI/CD‑logs og testdokumentation: virkede det eller ej?

Forside · Gennemgået oktober 2026 · Af John Nielsen

Når parterne i en IT-tvist er uenige om, hvorvidt softwaren virkede, er CI/CD-systemet ofte den mest objektive kilde. Byggeserveren registrerer, hvilken version af koden der blev bygget, hvilke tests der blev kørt, hvad resultatet var, og hvornår en version blev udrullet til et miljø. Tidsstemplerne sættes af systemet, ikke af udvikleren. Men logs udløber, tests kan være slået fra, og et grønt flueben betyder kun, at de tests, der fandtes, bestod.

Haster det? Byggelogs og artefakter slettes automatisk, i GitHub Actions som standard efter 90 dage og jobartefakter i GitLab efter 30 dage. Se akut forensisk sikring; hastesager koster ekstra.

Hvad CI/CD-systemet registrerer

Pipeline-kørsler · Hvilket commit der blev bygget, hvornår, af hvilken udløser og med hvilket resultat
Byggelogs · Kompilering, advarsler, fejl og hentede afhængigheder
Testresultater · Antal tests, beståede, fejlede og oversprungne, ofte i et maskinlæsbart format
Dækningsrapporter · Hvor stor en del af koden testene berørte
Artefakter · De filer, pakker eller containerbilleder, kørslen producerede
Deploy-historik · Hvilken version der blev udrullet til hvilket miljø og hvornår
Pipeline-definition · Selve opskriften: hvilke trin der kørtes, og om tests kunne fejle uden at stoppe bygget

Pipeline-definitionen ligger typisk i repositoriet som en fil og har derfor sin egen historik. Den er vigtig, fordi den viser, hvordan “bestået” var defineret på et givet tidspunkt.

Kobling til kildekoden

Hver kørsel refererer til et commit-id. Det gør det muligt at koble et testresultat til en præcis version af koden, og omvendt at se, om en bestemt version nogensinde blev bygget og testet. Fordi commit-id’et er en hashværdi af commit-objektet og dets historik, kan det ikke ændres uden at blive et andet id. Har CI-systemet registreret et id, viser det, at commit’en fandtes i den form, da kørslen fandt sted. Det er nyttigt, hvis historikken senere er omskrevet. Se kildekode og Git som bevis.

Opbevaring

CI/CD-platforme sletter typisk logs og artefakter efter en periode, der afhænger af platform, abonnement og projektets indstillinger. Artefakter slettes ofte hurtigere end selve kørselsoversigten, så man kan se, at et byg fandtes, men ikke hente det. På tidspunktet for gennemgangen (oktober 2026) gemte GitHub Actions som standard logs og artefakter i 90 dage, mens GitLab som standard lod jobartefakter udløbe efter 30 dage, men beholdt jobloggene uden udløb. Begge dele kan ændres i projektets eller organisationens indstillinger. Selvhostede byggeservere kan have rotation af logs og oprydning af gamle byg sat op lokalt.

Er der udsigt til en tvist, bør opbevaringen kontrolleres og eventuelt forlænges med det samme, og de relevante kørsler eksporteres.

Sikring

Eksportér kørselshistorikken for perioden via platformens API eller eksport, med commit-id, tidspunkter, udløser, status og varighed.
Hent byggelogs og testresultater i deres oprindelige format, ikke kun som visning i browseren.
Sikr pipeline-definitionen med historik, typisk som en del af repositoriet.
Sikr deploy-historikken og eventuelle godkendelser af udrulninger.
Hent artefakter, der stadig findes, og notér digest eller hashværdi.
Hash alle eksporter, og registrér værktøj, version og tidspunkt.

Platformens auditlog bør også sikres. Den kan vise, om nogen har slettet kørsler, ændret indstillinger for opbevaring eller genkørt en pipeline. Om auditlogs på kodeplatformene, se auditlogs for kloning, forks og tokens.

Fortolkning af testresultater

Et testresultat er kun så stærkt som testene bag det. Ved vurderingen bør følgende med:

Hvad testene dækker. En pipeline med få tests, der kun tjekker enkle funktioner, siger lidt om, hvorvidt hele løsningen virkede.
Oversprungne og deaktiverede tests. Tests kan være markeret som sprunget over eller slået fra, og det fremgår ikke af et samlet grønt resultat.
Tilladte fejl. Pipeline-definitionen kan tillade, at et trin fejler, uden at kørslen samlet fejler.
Ustabile tests. Tests, der skiftevis består og fejler uden kodeændringer, gør enkeltkørsler usikre. Mønstret over mange kørsler siger mere.
Testmiljøet. Tests kører med testdata og ofte med simulerede eksterne tjenester. At de bestod, viser ikke, at løsningen virkede mod produktionens data og integrationer.

Selvhostede byggeservere

Kører byggeserveren på egen hardware eller en virtuel maskine, ligger historikken i serverens egne filer og database. Her kan det være relevant at sikre hele serveren som en forensisk kopi, fordi logs, arbejdsmapper og konfiguration ligger spredt, og fordi en eksport via brugerfladen sjældent får det hele med. Arbejdsmapper kan indeholde rester af tidligere byg, som ikke længere findes i oversigten.

Byggeagenter, der kører på andre maskiner, har ofte egne logs og cachede afhængigheder. De viser, hvilke versioner af biblioteker der faktisk blev hentet ved et bestemt byg, og kan forklare, hvorfor et senere byg af samme kode opfører sig anderledes.

Når testene er skrevet af den ene part

I mange projekter er det leverandøren, der har skrevet testene, og kunden, der skal godkende leverancen. Testenes indhold er derfor i sig selv et spørgsmål i sagen. En gennemgang kan se på, om testene afspejler kravene, om de tester de forretningskritiske forløb, og om der er tests, der altid består, fordi de ikke kontrollerer noget reelt. Historikken for testfilerne viser, hvornår tests er tilføjet, ændret eller fjernet, fx kort før en milepæl. Det er en faglig vurdering, som bør adskilles fra den rene sikring af data.

Deploy-historik og miljøer

Spørgsmålet “hvad kørte i produktion på dagen?” besvares bedst af deploy-historikken. Den viser, hvilken version der blev udrullet, og ofte hvem der godkendte. Den skal holdes op mod miljøets egne spor, fx versionsnumre i applikationslogs, fordi en udrulning kan være fejlet eller rullet tilbage manuelt uden om pipelinen. Om løsningen faktisk fungerede efter udrulningen, viser overvågningen bedre end pipelinen, se Monitoreringsdata som bevis.

Når leverancens tilstand på et bestemt tidspunkt skal fastholdes, bør CI/CD-data sikres sammen med kode, databaser og miljøer, som beskrevet i leverancens tilstand på overdragelsestidspunktet.

Sammenhæng med tickets og krav

En fejl i en test kan ofte kobles til en ticket, og en ticket til et krav. Kæden krav, ticket, commit, kørsel og deploy er det, der gør det muligt at vise, om et bestemt krav var implementeret og testet på et bestemt tidspunkt. Ticket-systemets ændringshistorik er beskrevet i ticket-systemer: ændringshistorik.

Typiske fejl i fortolkningen

Et grønt resultat tages som bevis for, at softwaren opfyldte kravene.
Kørsler på en udviklergren forveksles med kørsler på den gren, der blev leveret.
Genkørsler overses, så et senere grønt resultat skjuler et tidligere rødt.
Platformens tidsstempler læses i browserens tidszone uden at det noteres.
Manglende kørsler tolkes som, at der ikke blev bygget, selvom de kan være slettet efter opbevaringsperioden.

Hvad CI/CD-data kan og ikke kan bevise

CI/CD-data kan vise, at en bestemt version blev bygget og testet på et bestemt tidspunkt med et bestemt resultat, og at den blev udrullet til et bestemt miljø. De kan ikke alene vise, at softwaren levede op til aftalen, eller at testene var tilstrækkelige. Det kræver en faglig vurdering af testenes indhold og dækning mod kravene. Den side af sagen, hvor manglerne skal dokumenteres i retten, er beskrevet på digital-bevissikring.dk.

Dokumentation

Rapporten bør angive platform og version, den periode, der er sikret, hvilke kørsler der mangler og hvorfor, og hvordan pipeline-definitionen så ud i perioden. Vigtige testresultater bør kunne spores fra rapporten tilbage til den konkrete kørsel og det konkrete commit.

Kilder og versioner

Senest gennemgået: oktober 2026.

Næste skridt

Læs også: Leverancens tilstand på overdragelsestidspunktet: sikring af miljøer og builds · Timeregistrering mod commits og tickets: krydsvalidering

→ Uvildig IT-sagkyndig med forensic-baggrund · For sagkyndige · Tlf. 70 13 63 23 · Digital bevissikring hos Nielco IT

Skrevet af John Nielsen, IT‑sagkyndig og indehaver af Nielco IT. Selvstændig siden 2009 og mere end 30 års erfaring med IT‑sikkerhed. Har været IT‑sagkyndig i danske retskredse og ved Den Fælles Europæiske Patentdomstol (UPC). Om John Nielsen · LinkedIn · Redaktionel politik