Integrarea continuă ( CI , English Continuous Integration ) este o practică de dezvoltare de software care constă în îmbinarea constantă a copiilor de lucru într-o ramură principală comună de dezvoltare (de până la mai multe ori pe zi) și realizarea frecventă a construirii automate a proiectelor pentru a identifica potențialele defecte cât mai curând posibil.și rezolvarea problemelor de integrare. Într-un proiect tipic, în care dezvoltatorii lucrează independent pe diferite părți ale sistemului, etapa de integrare este cea finală. Poate întârzia în mod imprevizibil finalizarea lucrărilor. Trecerea la integrarea continuă vă permite să reduceți complexitatea integrării și să o faceți mai previzibilă datorită detectării cât mai timpurii și eliminării erorilor și inconsecvențelor, dar principalul avantaj este reducerea costului remedierii unui defect datorită detectării sale timpurii.
Prima dată conceptualizată și propusă de Grady Booch în 1991 [1] . Este unul dintre elementele principale ale practicii de programare extremă .
Pentru a aplica practica, este necesar să îndepliniți o serie de cerințe de bază pentru proiectul de dezvoltare. În special, codul sursă și tot ceea ce este necesar pentru construirea și testarea proiectului ar trebui să fie stocate în depozitul sistemului de control al versiunilor , iar operațiunile de copiere din depozit, construirea și testarea întregului proiect ar trebui să fie automatizate și apelate cu ușurință din exterior. programe.
Pentru a organiza procesul de integrare continuă pe un server dedicat, este lansat un serviciu, ale cărui sarcini includ:
O construcție locală poate fi realizată printr-o solicitare externă, prin program, prin actualizarea unui depozit și prin alte criterii.
Build-urile programate ( ing. daily build - daily build ), de regulă, au loc după ore, noaptea ( ing. nightly build ), sunt planificate astfel încât rezultatele testelor să fie gata până la începutul următoarei zile lucrătoare. Pentru a distinge, este introdus suplimentar un sistem de numerotare a ansamblurilor - de obicei, fiecare ansamblu este numerotat cu un număr natural, care crește cu fiecare ansamblu nou. Textele sursă și alte date sursă, atunci când sunt preluate din depozitul (depozitul) al sistemului de control al versiunilor, sunt marcate cu un număr de build. Datorită acestui lucru, exact același ansamblu poate fi reprodus cu exactitate în viitor - trebuie doar să luați datele sursă pentru eticheta dorită și să începeți din nou procesul. Acest lucru face posibilă relansarea chiar și a versiunilor foarte vechi ale programului cu remedieri minore.
Beneficiile integrării continue includ:
În același timp, practica nu este lipsită de dezavantaje, în special:
În plus, efectul imediat al codului incomplet sau care nu funcționează descurajează dezvoltatorii să efectueze copii de siguranță periodice ale codului în depozit, dar în cazul utilizării unui sistem de control al versiunii codului sursă cu suport de ramificare, această problemă poate fi rezolvată prin crearea unui sistem separat. „ramură” ( ing. ramură ) a proiectului pentru a face modificări majore (codul, a cărui dezvoltare la o versiune funcțională va dura câteva zile, dar este de dorit salvarea mai frecventă a rezultatului în depozit). După ce dezvoltarea și testarea individuală a unei astfel de ramuri este finalizată, aceasta poate fi fuzionată ( imbinare ) cu codul principal sau „trunk” ( trunk ) al proiectului.