Kontinuerlig integration ( CI , eng. Continuous Integration ) er en softwareudviklingspraksis , der består i konstant at flette arbejdskopier ind i en fælles hovedudviklingsgren (op til flere gange om dagen) og udføre hyppige automatiserede projektopbygninger for hurtigt at identificere potentielle defekter og løse integration problemer. I et typisk projekt, hvor udviklere arbejder uafhængigt på forskellige dele af systemet, er integrationsfasen det sidste. Det kan uforudsigeligt forsinke færdiggørelsen af arbejdet. Overgangen til kontinuerlig integration giver dig mulighed for at reducere kompleksiteten af integration og gøre den mere forudsigelig på grund af den tidligste opdagelse og eliminering af fejl og uoverensstemmelser, men den største fordel er at reducere omkostningerne ved at rette en defekt på grund af dens tidlige opdagelse.
Først konceptualiseret og foreslået af Grady Booch i 1991 [1] . Det er et af hovedelementerne i ekstrem programmeringspraksis .
For at anvende praksis er det nødvendigt at opfylde en række grundlæggende krav til udviklingsprojektet. Især skal kildekoden og alt hvad der er nødvendigt for at bygge og teste projektet gemmes i versionskontrolsystemets lager , og operationerne med at kopiere fra lageret, bygge og teste hele projektet skal automatiseres og nemt kaldes eksternt. programmer.
For at organisere processen med kontinuerlig integration på en dedikeret server lanceres en tjeneste, hvis opgaver omfatter:
En lokal build kan udføres af en ekstern anmodning, efter tidsplan, ved kendsgerning af en lageropdatering og efter andre kriterier.
Planlagte byggerier ( eng. daily build - daily build ) afholdes som udgangspunkt efter arbejdstid, om natten ( eng. nightly build ), er planlagt på en sådan måde, at testresultater er klar ved begyndelsen af næste arbejdsdag. For at skelne er der desuden indført et samlingsnummereringssystem - normalt er hver samling nummereret med et naturligt nummer, som stiger med hver ny samling. Kildetekster og andre kildedata, når de tages fra repository (repository) i versionskontrolsystemet, er markeret med et build-nummer. Takket være dette kan nøjagtig den samme samling gengives nøjagtigt i fremtiden - tag blot kildedataene til den ønskede etiket og start processen igen. Dette gør det muligt at genudgive selv meget gamle versioner af programmet med mindre rettelser.
Fordelene ved kontinuerlig integration omfatter:
Samtidig er praksis ikke uden ulemper, især:
Derudover afskrækker den umiddelbare effekt af ufuldstændig eller ikke-fungerende kode udviklere fra at udføre periodiske sikkerhedskopier af kode i depotet, men i tilfælde af brug af et kildekodeversionskontrolsystem med forgreningsunderstøttelse kan dette problem løses ved at oprette en separat "branch" ( eng. branch ) af projektet til at foretage større ændringer (kode, hvis udvikling til en brugbar version vil tage flere dage, men hyppigere lagring af resultatet til depotet er ønskeligt). Efter udvikling og individuel test af en sådan gren er afsluttet, kan den flettes ( flettes ) med projektets hovedkode eller "stamme" ( stamme ).