Release integrity: da vores udvidelse blev udgivet uden sine egne rettelser

Hvad der skete

Dette er en sand historie fra udviklingen af browser-udvidelsen Clean Copy. Projektet har én kernefil med al logikken (clean_copy_core.js) og seks overflader der bruger den: Chrome-udvidelse, Firefox-udvidelse, CLI-værktøj, bookmarklet, Obsidian-plugin og desktop-app.

Ved en gennemgang opdagede vi noget ubehageligt: Chrome-udvidelsens baggrunds-script indeholdt ikke rettelserne fra de seneste to udgivelser. De lå i kernefilen — og i Firefox-versionen. Men den fil, der faktisk blev pakket i Chrome-zippen, var en ældre kopi.

✅ Tests: grønne

Enheds- og integrationstestene kørte mod kernefilen. Den havde alle rettelser. Alt så perfekt ud.

📦 Artefakt: forkert

Zip-filen indeholdt en manuel kopi af kernen — to udgivelser gammel, uden de nye fixes.

🚫 Brugere: ramt

Alle der downloadede udvidelsen i den periode fik et produkt uden de rettelser, udgivelsesnoterne lovede.

Hvordan sker sådan noget?

Klassisk årsag: samme logik vedligeholdt flere steder. Da projektet var lille, blev kernen kopieret ind i hvert projekt med håndkraft. Kopien i Chrome-mappen blev simpelthen glemt i to iterationer — mens kilden og Firefox-kopien blev opdateret.

Manuelle kopier af kode er tidsbomber. De virker fint, indtil nogen glemmer én. Og der er ingen alarm, når det sker.
Tests tester kun, hvad de indlæser. Vores tests importerede kernefilen direkte. De vidste intet om, hvad der lå i zippen.
Udgivelsespresset forstærker det. Man bygger zips sidst, hurtigt, efter alt er godkendt. Netop dét trin får aldrig den opmærksomhed, det fortjener.

Fiksen: ét sandhedssted + én parity-test

Ingen manuelle kopier. Kernelogikken findes nu kun i én fil. Bygge-scriptet genererer alle kopier — udvidelsernes scripts får kernen splicet ind under bygning, med markerede blokke.
Parity-test før udgivelse. Én test læser den færdige zip, udpakker den, og sammenligner kernesektionen byte-for-byte med kilden. Afviger de, fejler buildet. Ingen udgivelse uden grøn parity-test.
Versionsbump før zips bygges. Regel: indholdsændring ⇒ versionsnummer op, altid, inden artefaktet bygges. Så kan man aldrig forveksle en ny zip med en gammel.
Efterudgivelses-verificering. Efter deploy hentes zip-filen live fra sitet og kontrolleres — samme parity-tjek, men mod det brugerne faktisk downloader.

Tre læringer du kan bruge i morgen

Test artefaktet, ikke bare kilden. Det brugeren modtager er zip-filen, pakken, installeret. Din test-suite skal mindst én gang åbne præcis det.
Sammensatte projekter skal generere, ikke kopiere. Hvis samme funktion findes i to filer, vil de på et tidspunkt være forskellige. Spørgsmålet er ikke om, men hvornår — og om en test opdager det.
Parity-testen er billig og fanger en hel fejlklasse. Den kræver ingen framework: læs to filer, sammenlign, fejlstå hvis ulige. Ti linjer kode der reddede os fra at udgive forkert indhold en tredje gang.

Fejlen kostede os to udgivelser og en del tillid hos os selv. Fiksen kostede en eftermiddag. Det er den bedste investering projektet har lavet.

Prøv Clean Copy gratis → Flere guides

Ofte stillede spørgsmål

Hvad betyder release integrity?

At det du udgiver, er identisk med det du testede. Ikke "bygget fra samme kodebase" eller "for det meste ens" — men bit-for-bit de samme filer, samme versioner, ingen ældre artefakter blandet ind. Integrity fejler typisk ikke i koden, men i pakningen: hvilke filer der havner i artefaktet.

Hvorfor fangede enhedstests ikke fejlen?

Fordi de testede kildefilen. Kernen havde alle rettelserne, og testene mod kernen bestod. Fejlen lå et andet sted: i en kopi af koden, der blev pakket ind i zip-filen, og som ingen test læste. En test kan kun garantere det, den faktisk indlæser.

Hvad er en parity-test?

En test der sammenligner to ting, der burde være ens: fx kildetool.js og den kopier af tool.js, der ligger i udgivelsespakken. Hvis de adskiller sig, fejler buildet — uanset om funktionstests ellers er grønne. Den fanger præcis den klasse af fejl, hvor noget bliver vedligeholdt to steder.

Hvordan undgår jeg det i mit eget projekt?

Tre regler: (1) Generér kopier fra kilden i stedet for at vedligeholde dem manuelt — ét sandhedssted. (2) Lad bygge-scriptet splicse delt kode ind i artefaktet automatisk. (3) Tilføj én parity-test, der verificerer at artefaktets indhold matcher kilden, og lad den køre før hver udgivelse.

Prøv Clean Copy gratis →