Kontinuerlig integrasjon

I denne artikkelen vil vi utforske Kontinuerlig integrasjon og alle dens implikasjoner. Fra dens innvirkning på samfunnet til dens innflytelse på menneskers daglige liv, er Kontinuerlig integrasjon et tema som fortjener å bli analysert og diskutert i dybden. Langs disse linjene vil vi oppdage de forskjellige perspektivene som finnes på Kontinuerlig integrasjon, samt mulige løsninger eller tilnærminger for å løse dette problemet. Det spiller ingen rolle om du er en ekspert på området eller om det er første gang du hører om Kontinuerlig integrasjon, denne artikkelen er designet for å tilby en komplett og berikende visjon om det. Gjør deg klar til å fordype deg i den fascinerende verdenen til Kontinuerlig integrasjon!

Skisse av flytdiagram for kontinuerlig integrasjon

Kontinuerlig integrasjon[1] (engelsk: continuous integration, CI) er en tilnærming til programvareutvikling hvor man slår sammen alle utviklerne sine arbeidskopier til en delt hovedgren flere ganger i løpet av dagen.[2]

Historie

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]

Motivasjon

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]

Se også

Referanser

  1. ^ «På vei mot mer utvikling». Statens vegvesen. Besøkt 4. august 2022. 
  2. ^ a b Fowler, Martin. «Continuous Integration». Besøkt 9. januar 2014. 
  3. ^ Booch, Grady. Object Oriented Design: With Applications. Benjamin Cummings. s. 209. ISBN 9780805300918. Besøkt 18. august 2014. 
  4. ^ Booch, Grady (desember 1998). Object-Oriented Analysis and Design with applications (PDF) (2nd utg.). Arkivert fra originalen (PDF) 19. august 2019. Besøkt 2. desember 2014. 
  5. ^ . ISBN 9783540643036 https://books.google.com/books?id=YBC5xD08NREC&q=%22Extreme+Programming%3A+A+Humanistic+Discipline+of+Software+Development%22&pg=PA4. 
  6. ^ Beck, Kent. Extreme Programming Explained. Addison-Wesley Professional. s. 97. ISBN 978-0-201-61641-5. 
  7. ^ Beck, K. (1999). «Embracing change with extreme programming». Computer. 32 (10): 70–77. doi:10.1109/2.796139. 
  8. ^ «A Brief History of DevOps, Part III: Automated Testing and Continuous Integration». CircleCI. 1. februar 2018. Besøkt 19. mai 2018. 
  9. ^ Duvall, Paul M. Continuous Integration. Improving Software Quality and Reducing Risk. Addison-Wesley. ISBN 978-0-321-33638-5. 
  10. ^ Cunningham, Ward. «Integration Hell». Besøkt 19. september 2009. 
  11. ^ «What is Continuous Integration?».