Hva er CI/CD? Kontinuerlig integrasjon og levering forklart enkelt

CI/CD er en måte å levere programvare på der hver kodeendring automatisk bygges, testes og – hvis den består – gjøres klar for utgivelse eller slippes ut. CI (kontinuerlig integrasjon) betyr at endringer slås sammen ofte og sjekkes av automatiske tester hver gang. CD (kontinuerlig levering eller distribusjon) betyr at endringene som består pakkes og sendes mot brukerne dine med lite eller ingen manuelt arbeid.

Poenget er enkelt: fang feil minutter etter at de er gjort, ikke uker senere når en kunde finner dem.

Hvorfor CI/CD betyr noe når du bygger med KI

KI-appbyggere gjør kodeendringer raskt. En enkelt prompt kan berøre ti filer. Den farten er flott helt til en endring på utsjekkingssiden stille ødelegger innloggingssiden, og ingen merker det før en bruker sender deg en e-post.

CI/CD er sikkerhetsnettet for nettopp dette. I stedet for å stole på at hver endring er grei, kjører en pipeline de samme sjekkene hver gang:

• Bygger appen fortsatt uten feil?
• Består de automatiske testene fortsatt?
• Følger koden prosjektets regler (typer, formatering, sikkerhetssjekker)?

Hvis en sjekk feiler, stoppes endringen før den når brukerne. Jo raskere koden din endres, desto mer verdifull er en sjekk som aldri blir lei eller hopper over et steg.

En hverdagslig analogi

Tenk deg et bakeri som selger brød til butikker hver morgen.

• Uten CI/CD jobber hver baker med egne oppskriftsjusteringer i en uke, så slår alle sammen endringene fredag kveld og håper brødet fortsatt hever seg. Når det ikke gjør det, vet ingen hvilken endring som var årsaken.
• Med CI bakes hver lille oppskriftsendring rett inn i en testbrød og sjekkes – smak, vekt, form. En dårlig endring fanges samme dag, og du vet nøyaktig hvilken det var.
• Med CD går brød som består kontrollen rett på leveransebilen, pakket og merket likt hver gang, i stedet for at noen pakker esker for hånd klokken fem om morgenen.

Kontrollen gjør ikke bakerne bedre. Den gjør feilene deres billige.

Slik fungerer en CI/CD-pipeline

En pipeline er en liste med steg som en CI/CD-tjeneste kjører automatisk når noe skjer – vanligvis når noen pusher kode til et repositorium som GitHub. En typisk pipeline ser slik ut:

Hvert steg kjører på en ren maskin, ikke på noens laptop, så «det fungerer på min maskin» slutter å være en unnskyldning. Hvis et steg feiler, stopper pipelinen og forteller den som gjorde endringen.

Stegene er definert i en konfigurasjonsfil som ligger sammen med koden. I GitHub Actions er det for eksempel en YAML-fil i mappen .github/workflows i repositoriet.

Kontinuerlig levering vs kontinuerlig distribusjon

«CD» er tvetydig, og folk bruker det på begge måter:

Kontinuerlig distribusjon fungerer bare godt hvis testene er gode. Hvis testene dine ikke dekker utsjekking, vil kontinuerlig distribusjon med glede sende ut en ødelagt utsjekking.

Et praktisk eksempel: en bookingapp med en pipeline

Si at du har en bookingapp for en frisørsalong, og koden ligger i et GitHub-repositorium. Du ber en KI-appbygger om å «legge til 10 % rabatt for førstegangskunder».

1. Endringen pushes til en ny gren, og en pull request åpnes.
2. Pipelinen starter. Den installerer pakker og bygger appen – dette består.
3. Den kjører testene. En test, «en tilbakevendende kunde betaler full pris», feiler: rabatten gis til alle.
4. Pull requesten viser et rødt kryss. Endringen kan ikke slås sammen.
5. Du ber KI-en fikse det. Den pusher en rettelse; pipelinen kjører på nytt, og alt består.
6. Endringen slås sammen. Pipelinen distribuerer den til et staging-miljø, der du prøver en testbooking.
7. Du godkjenner, og den distribueres til produksjon.

Uten pipelinen ville steg 3 ha skjedd i kundenes lommebøker.

Nøkkelbegreper

Vanlige misforståelser

• «CI/CD betyr at appen min er testet.» En pipeline kjører bare de testene du har. Hvis det ikke finnes tester, beviser CI bare at appen bygger – ikke mer. Be KI-en skrive tester for de flytene som betyr mest.
• «CI/CD er bare for store selskaper.» Hostede verktøy som GitHub Actions krever en kort konfigurasjonsfil for å settes opp, og små team bruker dem hele tiden. Det er testene, ikke verktøyet, som krever innsats.
• «Automatisk distribusjon betyr at ingen kontrollerer noe.» Gode pipelines legger til sjekker, de fjerner dem ikke. Mange team beholder et menneskelig godkjenningssteg før produksjon.
• «Hvis pipelinen er grønn, fungerer appen.» Det betyr at de automatiske sjekkene besto. Du bør fortsatt prøve endringen selv, helst i en forhåndsvisning eller på staging.
• «CI/CD erstatter sikkerhetskopier.» Det gjør det ikke. En dårlig databasemigrering som består testene kan fortsatt skade ekte data. Behold sikkerhetskopier og en måte å rulle tilbake på.

Hva du bør spørre KI-appbyggeren din om

• «Skriv automatiske tester for registrering, innlogging og utsjekking, og vis meg hvordan jeg kjører dem.»
• «Sett opp en GitHub Actions-arbeidsflyt som installerer avhengigheter, bygger appen og kjører testene på hver pull request.»
• «Legg til en typesjekk og en linter i pipelinen, og gjør at den feiler ved feil.»
• «Forklar med enkle ord hva hvert steg i pipelinen gjør.»
• «Hva skjer hvis en distribusjon feiler halvveis? Hvordan ruller jeg tilbake?»
• «Sjekk at ingen hemmeligheter er hardkodet i repositoriet eller skrevet ut i pipeline-loggene.»

Hvis appen din bruker API-nøkler, trenger pipelinen dem også – lagret som krypterte hemmeligheter i CI-verktøyet, aldri i konfigurasjonsfilen. Se miljøvariabler og hemmeligheter.

CI/CD og Mythex

Mythex kjører ikke en CI-pipeline for deg, men dekker flere av de samme behovene på sin egen måte:

• Sjekkpunkter. Etter hver vellykket agenttur lagrer Mythex et git-sjekkpunkt, og Gå tilbake til dette punktet ruller prosjektet tilbake hvis en endring gikk galt. Se Chat.
• App-testing. Skriv /test, så klikker agenten seg gjennom den levende forhåndsvisningen din som en bruker og rapporterer ødelagte flyter – nyttig før hver publisering. Se App-testing.
• Publisering er et bevisst steg. Endringer vises først i den private forhåndsvisningen; den offentlige appen din oppdateres bare når du publiserer på nytt – nærmere kontinuerlig levering enn kontinuerlig distribusjon.
• GitHub-synkronisering (Pro). Synkroniser prosjektet til et GitHub-repositorium, så kan du legge til egne GitHub Actions-arbeidsflyter som kjører tester ved hver push. Se GitHub og eksport.

For en sjekkliste over hva du bør teste manuelt før lansering, se hvordan du tester appen din før lansering, og for arbeid med versjonskontroll, hvordan du bruker Git med en KI-bygd app.

Spørsmål