Atsauce: kā darbojas nepārtrauktās integrācijas process

Å odien mēs apskatÄ«sim termina vēsturi, apspriedÄ«sim CI ievieÅ”anas grÅ«tÄ«bas un sniegsim vairākus populārus rÄ«kus, kas palÄ«dzēs ar to strādāt.

Atsauce: kā darbojas nepārtrauktās integrācijas process
/flickr/ Altug Karakoc / CC BY / Foto pārveidots

termiņŔ

Nepārtraukta integrācija ir pieeja lietojumprogrammu izstrādei, kas ietver biežu projektu veidoÅ”anu un koda testÄ“Å”anu.

MērÄ·is ir padarÄ«t integrācijas procesu paredzamu un agrÄ«nā stadijā atklāt iespējamās kļūdas un kļūdas, lai bÅ«tu vairāk laika to laboÅ”anai.

Termins nepārtraukta integrācija pirmo reizi parādÄ«jās 1991. gadā. To ieviesa UML valodas radÄ«tājs Greidijs Butčs (Greidijs BÅ«s). Inženieris iepazÄ«stināja ar KI jēdzienu kā daļu no savas attÄ«stÄ«bas prakses - BÅ«Å”a metode. Tas nozÄ«mēja pakāpenisku arhitektÅ«ras pilnveidoÅ”anu, projektējot objektorientētas sistēmas. Gradi neaprakstÄ«ja nekādas prasÄ«bas nepārtrauktai integrācijai. Bet vēlāk savā grāmatā "Uz objektu orientēta analÄ«ze un dizains ar lietojumprogrammām"ViņŔ teica, ka metodoloÄ£ijas mērÄ·is ir paātrināt "iekŔējo izlaidumu" izlaiÅ”anu.

Stāsts

1996. gadā CI pieņēma metodikas veidotāji ekstrēma programmÄ“Å”ana (XP) - Kents Beks (Kents Beks) un Rons Džefrijs (Rons Džefrijs). Nepārtraukta integrācija kļuva par vienu no divpadsmit galvenajiem viņu pieejas principiem. XP dibinātāji precizēja prasÄ«bas CI metodoloÄ£ijai un atzÄ«mēja nepiecieÅ”amÄ«bu projektu bÅ«vēt vairākas reizes dienā.

2000. gadu sākumā viens no Agile Alliance dibinātājiem sāka veicināt nepārtrauktas integrācijas metodoloÄ£iju. MārtiņŔ Faulers (Mārtins Faulers). Viņa eksperimenti ar CI noveda pie pirmā programmatÅ«ras rÄ«ka Å”ajā jomā - CruiseControl. LietderÄ«bu izveidoja Martina kolēģis MetjÅ« Fommels.

BÅ«vÄ“Å”anas cikls rÄ«kā tiek Ä«stenots kā dēmons, kas periodiski pārbauda versiju kontroles sistēmu, vai nav izmaiņas koda bāzē. Risinājumu var lejupielādēt jau Å”odien ā€“ tas izplata saskaņā ar BSD lÄ«dzÄ«gu licenci.

LÄ«dz ar CI programmatÅ«ras parādÄ«Å”anos arvien vairāk uzņēmumu sāka pieņemt Å”o praksi. Saskaņā ar Forrester pētÄ«jumu [5. lpp Ziņot], 2009. gadā 86% no piecdesmit aptaujātajiem tehnoloÄ£iju uzņēmumiem izmantoja vai ieviesa KI metodes.

MÅ«sdienās nepārtrauktās integrācijas praksi izmanto organizācijas no visdažādākajām nozarēm. 2018. gadā liels mākoņpakalpojumu sniedzējs veica IT speciālistu aptauju no pakalpojumu, izglÄ«tÄ«bas un finanÅ”u nozares uzņēmumiem. No seÅ”iem tÅ«kstoÅ”iem respondentu 58% teica, ka savā darbā izmanto KI rÄ«kus un principus.

Kā tas darbojas

Nepārtrauktās integrācijas pamatā ir divi rÄ«ki: versiju kontroles sistēma un CI serveris. Pēdējā var bÅ«t fiziska ierÄ«ce vai virtuāla maŔīna mākoņa vidē. Izstrādātāji augÅ”upielādē jaunu kodu vienu vai vairākas reizes dienā. CI serveris to automātiski kopē ar visām atkarÄ«bām un izveido. Pēc tam tas palaiž integrācijas un vienÄ«bu testus. Ja testi ir veiksmÄ«gi izturēti, CI sistēma izvieto kodu.

Vispārējo procesa diagrammu var attēlot Ŕādi:

Atsauce: kā darbojas nepārtrauktās integrācijas process

CI metodoloģija izstrādātājiem nosaka vairākas prasības:

  • Nekavējoties izlabojiet problēmas. Å is princips CI radās no ekstrēmas programmÄ“Å”anas. Kļūdu laboÅ”ana ir izstrādātāju augstākā prioritāte.
  • Automatizējiet procesus. Izstrādātājiem un vadÄ«tājiem integrācijas procesā pastāvÄ«gi jāmeklē vājās vietas un tās jānovērÅ”. Piemēram, integrācijā bieži ir vājÅ” kakls izrādās testÄ“Å”ana.
  • Veiciet montāžu pēc iespējas biežāk. Reizi dienā, lai sinhronizētu komandas darbu.

ÄŖstenoÅ”anas grÅ«tÄ«bas

Pirmā problēma ir augstās ekspluatācijas izmaksas. Pat ja uzņēmums izmanto atvērtos CI rīkus (par ko mēs runāsim vēlāk), tam joprojām būs jātērē nauda infrastruktūras atbalstam. Tomēr risinājums var būt mākoņtehnoloģijas.

Tie vienkārÅ”o dažāda mēroga datoru konfigurāciju montāžu. Plus no uzņēmuma tiek apmaksāti tikai par izmantotajiem resursiem, kas palÄ«dz ietaupÄ«t uz infrastruktÅ«ru.

Pēc aptaujām [14.lpp Raksts], nepārtraukta integrācija palielina uzņēmuma darbinieku slodzi (vismaz sākumā). Viņiem ir jāapgūst jauni rīki, un kolēģi ne vienmēr palīdz apmācībā. Tāpēc jums ir jātiek galā ar jaunām sistēmām un pakalpojumiem, atrodoties ceļā.

TreŔā grÅ«tÄ«ba ir problēmas ar automatizāciju. Ar Å”o problēmu saskaras organizācijas ar lielu daudzumu mantotā koda, uz kuru neattiecas automatizētie testi. Tas noved pie tā, ka kods tiek vienkārÅ”i pārrakstÄ«ts pirms pilnÄ«gas CI ievieÅ”anas.

Atsauce: kā darbojas nepārtrauktās integrācijas process
/flickr/ theilr / CC BY-SA

Kas lieto

IT giganti bija vieni no pirmajiem, kas novērtēja metodoloÄ£ijas priekÅ”rocÄ«bas. Google izmanto nepārtraukta integrācija kopÅ” 2000. gadu vidus. CI tika ieviests, lai atrisinātu meklētājprogrammas kavÄ“Å”anās problēmu. Nepārtraukta integrācija palÄ«dzēja ātri atklāt un atrisināt problēmas. Tagad CI izmanto visas IT giganta nodaļas.

Nepārtraukta integrācija palÄ«dz arÄ« maziem uzņēmumiem, un KI rÄ«kus izmanto arÄ« finanÅ”u un veselÄ«bas aprÅ«pes organizācijas. Piemēram, Morningstar nepārtrauktas integrācijas pakalpojumi palÄ«dzēja par 70% ātrāk novērst ievainojamÄ«bas. Un Philips Healthcare medicÄ«nas platforma spēja dubultot atjauninājumu testÄ“Å”anas ātrumu.

Darbarīki

Šeit ir daži populāri CI rīki:

  • Jenkins ir viena no populārākajām CI sistēmām. Tas atbalsta vairāk nekā tÅ«kstoti spraudņu integrācijai ar dažādiem VCS, mākoņa platformām un citiem pakalpojumiem. Mēs izmantojam arÄ« Jenkins rÄ«kā 1cloud: iekļauts mÅ«su DevOps sistēmā. ViņŔ regulāri pārbauda testÄ“Å”anai paredzēto Git filiāli.
  • Buildbot ā€” Python ietvars savu nepārtraukto integrācijas procesu rakstÄ«Å”anai. RÄ«ka sākotnējā iestatÄ«Å”ana ir diezgan sarežģīta, taču to kompensē plaŔās pielāgoÅ”anas iespējas. Starp sistēmas priekÅ”rocÄ«bām lietotāji izceļ tā zemo resursu intensitāti.
  • Konkurss CI ir Pivotal serveris, kas izmanto Docker konteinerus. Concourse CI integrējas ar jebkuriem rÄ«kiem un versiju kontroles sistēmām. Izstrādātāji atzÄ«mē, ka sistēma ir piemērota darbam jebkura lieluma uzņēmumos.
  • Gitlab CI ir GitLab versiju kontroles sistēmā iebÅ«vēts rÄ«ks. Pakalpojums darbojas mākonÄ« un konfigurÄ“Å”anai izmanto YAML failus. Tāpat kā Concourse, Gitlab CI attiecas Docker konteineri, kas palÄ«dz izolēt dažādus procesus vienu no otra.
  • KodÄ“Å”ana ir mākoņa CI serveris, kas darbojas ar GitHub, GitLab un BitBucket. Platformai nav nepiecieÅ”ama ilga sākotnējā iestatÄ«Å”ana ā€” Codeship ir pieejami standarta iepriekÅ” instalētie CI procesi. Maziem (lÄ«dz 100 bÅ«vēm mēnesÄ«) un atvērtā pirmkoda projektiem Codeship ir pieejams bez maksas.

Materiāli no mūsu korporatīvā emuāra:

Avots: www.habr.com

Pievieno komentāru