ProHoster > Blogs > Administrācija > Atsauce: kā darbojas Continuous Integration process

Atsauce: kā darbojas Continuous Integration process

Å odien pievērsÄ«simies termina vēsturei, apspriedÄ«sim CI ievieÅ”anas grÅ«tÄ«bas un sniegsim dažus populārus rÄ«kus, kas palÄ«dzēs strādāt ar to.

Atsauce: kā darbojas Continuous Integration process
/ Flickr / Altug Karakoc / CC BY / Š¤Š¾Ń‚Š¾ ŠøŠ·Š¼ŠµŠ½ŠµŠ½Š¾

Termins

Continuous Integration (nepārtraukta integrācija) ir pieeja programmatÅ«ras izstrādē, kas ietver biežas projekta apkopoÅ”anas un koda testÄ“Å”anas veikÅ”anu.

MērÄ·is ir padarÄ«t integrācijas procesu prognozējamu un atklāt potenciālas kļūdas un defektus agrÄ«nā posmā, lai bÅ«tu vairāk laika to laboÅ”ana.

Pirmo reizi termins Continuous Integration parādÄ«jās 1991. gadā. To ieviesa UML valodas radÄ«tājs Grady Booch (Grady Booch). Inženieris prezentēja CI koncepciju kā daļu no savas izstrādes prakses ā€” Booch metode. ViņŔ paredzēja pakāpenisku arhitektÅ«ras precizÄ“Å”anu objektorientētu sistēmu projektÄ“Å”anā. Grady neaprakstÄ«ja konkrētas prasÄ«bas nepārtrauktai integrācijai. Bet vēlāk savā grāmatā "Object-Oriented Analysis and Design with Applications" viņŔ teica, ka metodes uzdevums ir paātrināt "iekŔējo relīžu" izdoÅ”anu.

Vēsture

1996. gadā CI pārņēma ekstremālās programmÄ“Å”anas metodoloÄ£ijas Kents Beks (XP) ā€” Kent Beck (Kent Beck) un Ron Džefrijs (Ron Jeffries). Nepārtraukta integrācija kļuva par vienu no divpadsmit galvenajiem principiem viņu pieejā. XP dibinātāji precizēja prasÄ«bas CI metodoloÄ£ijai un uzsvēra nepiecieÅ”amÄ«bu veikt projekta apkopoÅ”anu vairākas reizes dienā.

AgrÄ«nos 2000. gados CI metodoloÄ£iju sāka popularizēt viens no Agile Alliance dibinātājiem, MārtiņŔ Foulers (Martin Fowler). Viņa eksperimenti ar CI noveda pie pirmā programmatÅ«ras rÄ«ka Å”ajā jomā - CruiseControl. RÄ«ku izveidoja Mārtiņa kolēģis - Mērfijs Foemmels (Matthew Foemmel).

ApkopoÅ”anas cikls rÄ«kā ir ieviests kā demons, kas periodiski pārbauda versiju vadÄ«bas sistēmu par izmaiņām kodē. Risinājumu joprojām var lejupielādēt - tas tiek izplatÄ«ts ir ar BSD lÄ«dzÄ«gu licenci.

Ar CI programmatÅ«ras parādÄ«Å”anos Å”o praksi sāka pārņemt aizvien vairāk uzņēmumu. Saskaņā ar Forrester [lpp.5 ziņojuma] 2009. gadā 86% no piecdesmit aptaujātajām tehnoloÄ£iju kompānijām izmantoja vai ieviesa CI metodes.

Å odien Continuous Integration prakse tiek izmantota organizācijās no visdažādākajām nozarēm. 2018. gadā liels mākoņa pakalpojumu sniedzējs veica aptauju starp IT speciālistiem, kas strādā pakalpojumu, izglÄ«tÄ«bas un finanÅ”u jomā. No seÅ”iem tÅ«kstoÅ”iem respondentu 58% atbildēja, ka izmanto CI rÄ«kus un principus.

Efemerāli vispārējie mākonÄ«Å”i

Nepārtraukta integrÄ“Å”ana pamatojas uz diviem rÄ«kiem ā€“ versiju kontroli un CI serveri. Pēdējais var bÅ«t gan fiziska ierÄ«ce, gan virtuālā maŔīna mākoņa vidē. Izstrādātāji vienu vai vairākas reizes dienā augÅ”upielādē jaunu kodu. CI serveris automātiski to kopē kopā ar visām atkarÄ«bām un veic kompilāciju. Pēc tam tiek palaisti integrācijas un vienÄ«bu testi. Ja testi veiksmÄ«gi iziet, CI sistēma izvērÅ” kodu.

Vispārējo procesu shēmu var attēlot sekojoÅ”i:

Atsauce: kā darbojas Continuous Integration process

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

  • Nekavējoties labot problēmas. Å is princips ir nācis CI no ekstrēmā programmÄ“Å”anas. Kļūdu laboÅ”ana ir visprioritārākā izstrādātāju uzdevumu.
  • Automatizēt procesus. Izstrādātājiem un menedžeriem nepārtraukti jāmeklē "Å”aurās vietas" integrācijas procesā un jānovērÅ” tās. Piemēram, bieži "pudeļu kakls" integrācijā izrādās testÄ“Å”ana.
  • Veikt kompilācijas pēc iespējas biežāk. Reizi dienā, lai sinhronizētu komandas darbu.

IevieŔanas grūtības

Pirmais problēmas avots ir augstas operatīvās izmaksas. Pat ja uzņēmums izmanto atvērtos CI rīkus (par kuriem mēs runāsim tālāk), tam joprojām būs jātērē nauda infrastruktūras atbalstam. Tomēr risinājums var būt mākoņa tehnoloģijas.

Tās vienkārÅ”o dažādu mērogu datoru konfigurāciju izveidi. Turklāt uzņēmumi maksā tikai par izmantotajiem resursiem, kas palÄ«dz ietaupÄ«t uz infrastruktÅ«ru.

Saskaņā ar aptaujām [lpp.14 raksti], nepārtraukta integrācija palielina uzņēmuma darbinieku slodzi (vismaz sākotnējā periodā). Viņiem jāapgÅ«st jauni rÄ«ki, un kolēģi ne vienmēr palÄ«dz mācÄ«bās. Tāpēc ir jācÄ«nās ar jauniem ietvariem un pakalpojumiem ā€žuz vietasā€.

TreŔā grÅ«tÄ«ba - automatizācijas problēmas. Ar to saskaras organizācijas, kurām ir liels apjoms vecā koda, kas nav pārklāts ar automatizētajiem testiem. Tas noved pie tā, ka kodu vienkārÅ”i pārraksta pirms pilnÄ«gas CI ievieÅ”anas.

Atsauce: kā darbojas Continuous Integration process
/ Flickr / theilr / CC BY-SA

Kas izmanto

Kā viens no pirmajiem metodikas ieguvumiem novērtēja IT giganti. Google izmanto ieviesa nepārtrauktu integrāciju kopÅ” 2000. gadu vidus. CI tika ieviesta, lai atrisinātu izvērÅ”anas kavÄ“Å”anās problēmu meklētājā. Nepārtrauktā integrācija palÄ«dzēja ātri identificēt un novērst trÅ«kumus. Tagad CI izmanto visas IT giganta struktÅ«rvienÄ«bas.

Nepārtrauktā integrācija palÄ«dz arÄ« mazām kompānijām, un CI rÄ«kus izmanto finanÅ”u un medicÄ«nas organizācijas. Piemēram, Morningstar nepārtrauktās integrācijas pakalpojumi palÄ«dzēja novērst ievainojamÄ«bas par 70% ātrāk. Savukārt medicÄ«nas platforma Philips Healthcare spēja divreiz paātrināt jauninājumu testÄ“Å”anu.

RÄ«ki

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

  • Jenkins ā€” viena no populārākajām CI sistēmām. Tā atbalsta vairāk nekā tÅ«kstoÅ” spraudņu integrācijai ar dažādiem VCS, mākoņplatformām un citiem pakalpojumiem. Jenkins ir arÄ« mÅ«su rÄ«ks 1cloud: tas iekļaujas mÅ«su DevOps sistēmā. Tas regulāri pārbauda Git filiāli, kas paredzēta testÄ“Å”anai.
  • Buildbot ā€” Python ietvars, lai rakstÄ«tu savus nepārtrauktās integrācijas procesus. Sākotnējā rÄ«ka konfigurācija ir diezgan sarežģīta, tomēr to kompensē plaŔās pielāgoÅ”anas iespējas. Starp ietvara priekÅ”rocÄ«bām lietotāji izceļ tā zemo resursu patēriņu.
  • Concourse CI ā€” Pivotal serveris, kas izmanto Docker konteinerus. Concourse CI integrējas ar jebkādiem rÄ«kiem un versiju kontroles sistēmām. Izstrādātāji norāda, ka sistēma ir piemērota darbam kompanijās ar jebkādu izmēru.
  • Gitlab CI ā€” rÄ«ks, kas ir iebÅ«vēts GitLab versiju kontrolē. Pakalpojums darbojas mākoņī un izmanto YAML failus konfigurācijai. Tāpat kā Concourse, GitLab CI is used Docker konteineri, kas palÄ«dz izolēt dažādus procesus citam no cita.
  • Codeship ā€” mākoņu CI serveris, kas darbojas ar GitHub, GitLab un BitBucket. Platforma neprasa ilgu sākotnēju konfigurāciju ā€” Codeship piedāvā standarta iepriekÅ” iestatÄ«tas CI procesus. Mazām (lÄ«dz 100 bÅ«vēm mēnesÄ«) un open source projektiem Codeship ir pieejams bez maksas.

Materiāli no mūsu korporatīvā bloga:

Avots: habr.com

Iegādājieties uzticamu tÄ«mekļa hostingu ar DDoS aizsardzÄ«bu, VPS VDS serveriem šŸ”„ Iegādājieties uzticamu tÄ«mekļa hostingu ar DDoS aizsardzÄ«bu, VPS VDS serveriem | ProHoster