A folyamatos integráció ( CI , eng. Continuous Integration ) egy olyan szoftverfejlesztési gyakorlat , amely a munkapéldányok folyamatos összevonásából áll egy közös fő fejlesztési ágba (maximum naponta többször), és gyakori automatizált projektépítések végrehajtásából a lehetséges hibák gyors azonosítása és az integráció megoldása érdekében . problémákat. Egy tipikus projektben, ahol a fejlesztők egymástól függetlenül dolgoznak a rendszer különböző részein, az integrációs szakasz az utolsó. Előreláthatatlanul késleltetheti a munka befejezését. A folyamatos integrációra való áttérés lehetővé teszi az integráció bonyolultságának csökkentését és kiszámíthatóbbá tételét a hibák, inkonzisztenciák legkorábbi észlelése és kiküszöbölése miatt, de a fő előnye, hogy a hiba korai felismerése miatt csökken a javítási költség.
Először Grady Booch alkotta meg és javasolta 1991-ben [1] . Ez az extrém programozási gyakorlat egyik fő eleme .
A gyakorlat alkalmazásához a fejlesztési projekthez számos alapvető követelmény teljesítése szükséges. Különösen a forráskódot és mindent, ami a projekt felépítéséhez és teszteléséhez szükséges, a verziókezelő rendszer lerakatában kell tárolni , és a repository-ból történő másolást, a teljes projekt felépítését és tesztelését automatizálni kell, és egyszerűen külsőről hívni kell. programokat.
A folyamatos integráció folyamatának egy dedikált szerveren való megszervezésére egy szolgáltatás indul, melynek feladatai a következők:
A helyi build végrehajtható külső kéréssel, ütemezéssel, lerakatfrissítés tényével és egyéb feltételekkel.
Az ütemezett összeállítások ( eng. daily build - daily build ) általában órák után, éjszaka ( eng. nightly build ) vannak megtervezve, hogy a teszteredmények a következő munkanap elejére elkészüljenek. A megkülönböztetés érdekében egy szerelvényszámozási rendszert is bevezetnek - általában minden összeállítás egy természetes számmal van számozva, amely minden egyes új szerelvénnyel növekszik. A forrásszövegeket és egyéb forrásadatokat, ha a verziókezelő rendszer lerakatából (repository) veszik át, buildszámmal jelölik. Ennek köszönhetően pontosan ugyanaz az összeállítás pontosan reprodukálható a jövőben - csak vegye ki a kívánt címke forrásadatait, és indítsa újra a folyamatot. Ez lehetővé teszi a program nagyon régi verzióinak újrakiadását kisebb javításokkal.
A folyamatos integráció előnyei a következők:
Ugyanakkor a gyakorlat nem mentes a hátrányoktól, különösen:
Ezen túlmenően a hiányos vagy nem működő kód azonnali hatása elriasztja a fejlesztőket attól, hogy rendszeres biztonsági mentéseket hajtsanak végre a kódról a tárolóba, de elágazási támogatással rendelkező forráskód-verzióvezérlő rendszer használata esetén ez a probléma egy különálló kód létrehozásával megoldható. a projekt „ága” ( eng. branch ) a nagyobb változtatások elvégzéséhez (kód, melynek működőképes verzióra való fejlesztése több napot vesz igénybe, de az eredmény gyakrabban történő mentése a repositoryba kívánatos). Miután egy ilyen ág fejlesztése és egyedi tesztelése befejeződött, összevonható ( mere ) a projekt fő kódjával vagy „törzsével” ( trunk ).