Kontinuerlig integration ( CI , eng. Continuous Integration ) är en praxis för mjukvaruutveckling som består i att ständigt slå samman arbetskopior till en gemensam huvudutvecklingsgren (upp till flera gånger om dagen) och utföra frekventa automatiserade projektbyggen för att snabbt identifiera potentiella defekter och lösa integrationen problem. I ett typiskt projekt, där utvecklare arbetar självständigt på olika delar av systemet, är integrationsstadiet det sista. Det kan oförutsägbart försena slutförandet av arbetet. Övergången till kontinuerlig integration gör att du kan minska komplexiteten i integrationen och göra den mer förutsägbar på grund av den tidigaste upptäckten och eliminering av fel och inkonsekvenser, men den största fördelen är att minska kostnaden för att åtgärda en defekt på grund av dess tidig upptäckt.
Konceptualiserades och föreslogs först av Grady Booch 1991 [1] . Det är en av huvuddelarna i extrem programmering .
För att tillämpa praxis är det nödvändigt att uppfylla ett antal grundläggande krav för utvecklingsprojektet. Framför allt bör källkoden och allt som behövs för att bygga och testa projektet lagras i versionskontrollsystemets arkiv , och operationerna med att kopiera från arkivet, bygga och testa hela projektet bör automatiseras och enkelt anropas från externa program.
För att organisera processen med kontinuerlig integration på en dedikerad server lanseras en tjänst, vars uppgifter inkluderar:
En lokal konstruktion kan utföras av en extern begäran, enligt schema, genom att en repositoryuppdatering och andra kriterier.
Schemalagda byggnationer ( eng. daily build - daily build ), hålls i regel efter arbetstid, på natten ( eng. nightly build ), planeras på ett sådant sätt att testresultaten är klara i början av nästa arbetsdag. För att särskilja, introduceras dessutom ett samlingsnumreringssystem - vanligtvis numreras varje sammansättning med ett naturligt nummer, som ökar med varje ny sammansättning. Källtexter och andra källdata, när de hämtas från arkivet (repository) i versionskontrollsystemet, är markerade med ett build-nummer. Tack vare detta kan exakt samma sammansättning reproduceras korrekt i framtiden - ta bara källdata för den önskade etiketten och starta processen igen. Detta gör det möjligt att återsläppa även mycket gamla versioner av programmet med mindre korrigeringar.
Fördelarna med kontinuerlig integration inkluderar:
Samtidigt är praktiken inte utan nackdelar, särskilt:
Dessutom avskräcker den omedelbara effekten av ofullständig eller icke-fungerande kod utvecklare från att göra periodiska säkerhetskopieringar av kod till förvaret, men i fallet med användning av ett källkodsversionskontrollsystem med förgreningsstöd kan detta problem lösas genom att skapa en separat "branch" ( eng. branch ) av projektet för att göra stora förändringar (kod, vars utveckling till en fungerande version kommer att ta flera dagar, men mer frekvent lagring av resultatet till förvaret är önskvärt). Efter att utveckling och individuell testning av en sådan gren är klar kan den slås samman ( sammanfoga ) med huvudkoden eller "trunken" ( trunk ) för projektet.