Kontinuerlig integrasjon

I 1991 foreslo Grady Booch begrepet continuous integration i det som har blitt kjent som Booch-metoden,^[3][4] men foreslo da å ikke å integrere flere ganger om dagen.

I 1997 tok ekstrem programmering (XP) i bruk det samme begrepet,^[2][5][6] og foreslo å integrere mer enn en gang per dag, og kanskje så mye som et titalls ganger per dag.^[7]

I 2001 ble CruiseControl utgitt som et av de første CI-verktøyene med åpen kildekode.^[8]

Når en utvikler tar fatt på en endring vil vedkommende ta en kopi av den aktuelle kodebasen og arbeide på denne. Etterhvert som andre utviklere sender inn sine kodeendringer til kodelageret vil utvikleren sin kopi gradvis slutte å gjenspeile kodelageret. I tillegg til at den eksisterende kodebasen endres kan det legges til ny kode, nye biblioteker og andre ressurser som skaper avhengigheter og potensielle konflikter.

Dess lengre utviklingen fortsetter på en forgrening uten at man slår sammen tilbake til en hovedgren, desto større er risikoen for flere integrasjonskonflikter^[9] og feil når utviklingsgrenen til slutt flettes tillbake. Når utviklere sender inn kode til kodelageret må de først oppdatere koden for å gjenspeile endringene i kodelageret siden de tok kopien. Jo flere endringer kodelageret inneholder, jo mer arbeid må utviklerne gjøre før de sender inn sine egne endringer.

Til slutt kan kodelageret bli så forskjellig fra utviklernes kodebase at det blir så vanskelig å integrere endringene at tiden det tar overstiger tiden det tok å gjøre de opprinnelige endringene.^[10][11]

• CI/CD, den kombinerte tilnærmingen med kontinuerlig integrasjon og kontinuerlig leveranse (mer vanlig), eller kontinuerlig integrasjon og kontinuerlig utrulling (mindre vanlig)
• Rask applikasjonsutvikling
• Byggesystem
• Testdrevet utvikling