Hvad er CI/CD? Continuous integration og delivery forklaret enkelt

CI/CD er en måde at udgive software på, hvor hver kodeændring automatisk bygges, testes og — hvis den består — gøres klar til udgivelse eller udgives. CI (continuous integration) betyder, at ændringer flettes ofte ind og tjekkes af automatiske tests hver gang. CD (continuous delivery eller deployment) betyder, at de ændringer, der består, pakkes og sendes mod dine brugere med lidt eller intet manuelt arbejde.

Pointen er enkel: fang fejl minutter efter, de er lavet, ikke uger senere, når en kunde opdager dem.

Hvorfor CI/CD betyder noget, når du bygger med AI

AI-builders laver kodeændringer hurtigt. Én prompt kan røre ti filer. Den hastighed er god, indtil en ændring af checkout-siden stille og roligt ødelægger login-siden, og ingen opdager det, før en bruger skriver til dig.

CI/CD er sikkerhedsnettet netop til dette. I stedet for at stole på, at hver ændring er fin, kører en pipeline de samme tjek hver gang:

• Bygger appen stadig uden fejl?
• Består de automatiske tests stadig?
• Følger koden projektets regler (typer, formatering, sikkerhedstjek)?

Hvis et tjek fejler, stoppes ændringen, før den når brugerne. Jo hurtigere din kode ændres, desto mere værdi har et tjek, der aldrig bliver træt eller springer et trin over.

En hverdagsanalogi

Tænk på et bageri, der sælger brød til butikker hver morgen.

• Uden CI/CD arbejder hver bager på egne opskriftsjusteringer i en uge, og så kombinerer alle dem fredag aften og håber, at brødet stadig hæver. Når det ikke gør, ved ingen, hvis ændring der var skyld i det.
• Med CI bages hver lille opskriftsændring straks ind i et testbrød og tjekkes — smag, vægt, form. En dårlig ændring fanges samme dag, og du ved præcis, hvilken det var.
• Med CD kører brød, der består kontrollen, direkte ud på leveringsvognen, pakket og mærket ens hver gang, i stedet for at nogen pakker kasser i hånden kl. 5.

Kontrollen gør ikke bagerne bedre. Den gør deres fejl billige.

Sådan virker en CI/CD-pipeline

En pipeline er en liste af trin, som en CI/CD-tjeneste kører automatisk, når noget sker — typisk når nogen pusher kode til et repository som GitHub. En typisk pipeline ser sådan ud:

Hvert trin kører på en ren maskine, ikke på nogens laptop, så "det virker på min computer" ikke længere er en undskyldning. Hvis et trin fejler, stopper pipelinen og fortæller den, der lavede ændringen.

Trinene defineres i en konfigurationsfil, der ligger sammen med koden. I GitHub Actions er det for eksempel en YAML-fil i mappen .github/workflows i repositoriet.

Continuous delivery vs. continuous deployment

"CD" er tvetydigt, og folk bruger det begge veje:

Continuous deployment virker kun godt, hvis testene er gode. Hvis dine tests ikke dækker checkout, vil continuous deployment glad udgive en ødelagt checkout.

Et konkret eksempel: en bookingapp med en pipeline

Lad os sige, du har en frisør-bookingapp, og koden ligger i et GitHub-repository. Du beder en AI-builder om at "tilføje 10% rabat til nye kunder".

1. Ændringen pushes til en ny branch, og en pull request åbnes.
2. Pipelinen starter. Den installerer pakker og bygger appen — det består.
3. Den kører testene. Én test, "en kunde, der kommer igen, betaler fuld pris", fejler: rabatten gælder for alle.
4. Pull requesten viser et rødt kryds. Ændringen kan ikke flettes ind.
5. Du beder AI'en rette det. Den pusher en rettelse; pipelinen kører igen, og alt består.
6. Ændringen flettes ind. Pipelinen udruller den til et stagingmiljø, hvor du prøver en testbooking.
7. Du godkender, og den udrulles til produktion.

Uden pipelinen ville trin 3 være sket i dine kunders tegnebøger.

Vigtige begreber

Almindelige misforståelser

• "CI/CD betyder, at min app er testet." En pipeline kører kun de tests, du har. Hvis der ingen tests er, beviser CI kun, at appen bygger — intet mere. Bed din AI om at skrive tests for de flows, der betyder mest.
• "CI/CD er kun for store virksomheder." Hostede værktøjer som GitHub Actions kræver en kort konfigurationsfil at opsætte, og små teams bruger dem hele tiden. Det er testene, ikke værktøjet, der kræver indsats.
• "Automatisk udrulning betyder, at ingen tjekker noget." Gode pipelines tilføjer tjek, de fjerner dem ikke. Mange teams beholder et menneskeligt godkendelsestrin før produktion.
• "Hvis pipelinen er grøn, virker appen." Det betyder, at de automatiske tjek bestod. Du bør stadig selv prøve ændringen, helst i et preview eller på staging.
• "CI/CD erstatter backups." Det gør det ikke. En dårlig databasemigration, der består testene, kan stadig ødelægge rigtige data. Behold backups og en måde at rulle tilbage på.

Hvad du spørger din AI-builder om

• "Skriv automatiske tests for oprettelse af konto, login og checkout, og vis mig, hvordan man kører dem."
• "Opsæt en GitHub Actions-workflow, der installerer afhængigheder, bygger appen og kører testene på hver pull request."
• "Tilføj et typetjek og en linter til pipelinen, og lad den fejle ved fejl."
• "Forklar på almindeligt dansk, hvad hvert trin i pipelinen gør."
• "Hvad sker der, hvis en udrulning fejler halvvejs? Hvordan ruller jeg tilbage?"
• "Tjek, at ingen hemmeligheder er hårdkodet i repositoriet eller skrevet ud i pipeline-logs."

Hvis din app bruger API-nøgler, skal pipelinen også have dem — gemt som krypterede hemmeligheder i CI-værktøjet, aldrig i konfigurationsfilen. Se miljøvariabler og hemmeligheder.

CI/CD og Mythex

Mythex kører ikke en CI-pipeline for dig, men dækker flere af de samme behov på sin egen måde:

• Checkpoints. Efter hver vellykket agent-tur gemmer Mythex et git-checkpoint, og Gå tilbage til dette punkt ruller projektet tilbage, hvis en ændring gik galt. Se Chat.
• App Testing. Skriv /test, og agenten klikker sig gennem dit live-preview som en bruger og rapporterer ødelagte flows — nyttigt før hver udgivelse. Se App Testing.
• Udgivelse er et bevidst trin. Ændringer vises først i det private preview; din offentlige app opdateres først, når du udgiver igen — tættere på continuous delivery end continuous deployment.
• GitHub-synkronisering (Pro). Synkroniser projektet med et GitHub-repository, og du kan tilføje dine egne GitHub Actions-workflows, der kører tests på hver push. Se GitHub og eksport.

Til en tjekliste over, hvad du skal teste i hånden, før du går live, se sådan tester du din app før lancering, og til at arbejde med versionsstyring, sådan bruger du Git med en AI-bygget app.

Spørgsmål