🥇Viidatud: kuidas toimub Continuous Integration protsess

Täna käsitleme termini ajalugu, arutame CI rakendamise raskusi ning toome välja mõned populaarsed tööriistad, mis aitavad sellega töötamisel.

/ Flickr / Altug Karakoc / Kommertstoodete sünd / Фото изменено

Termin

Continuous Integration (katkematu integreerimine) – lähenemine rakenduste arendusele, mis eeldab projektide sagedast kokkupanekut ja koodi testimist.

Eesmärk on muuta integreerimisprotsess ennustatavaks ning tuvastada potentsiaalsed vead ja tõrked varakult, et oleks rohkem aega nende parandamiseks.

Termin Continuous Integration ilmus esmakordselt 1991. aastal. Selle tutvustas UMLi looja Grady Booch. Insener esitles CI kontseptsiooni osana oma arendustavast – Boochi meetodist.See eeldas arhitektuuri järkjärgulist täpsustamist objektorienteeritud süsteemide projekteerimisel. Grady ei määratlenud mingeid nõudeid katkematule integreerimisele. Kuid hiljem oma raamatus “Object-Oriented Analysis and Design with Applicationsõtles ta, et meetodi eesmärk on kiirendada "sisemiste väljaannete" väljastamist.

Ajalugu

1996. aastal võtsid CI üle ekstreemse programmeerimise (XP) rajajad – Kent Beck ja Ron Jeffries. Katkematu integreerimine sai nende lähenemise üheks kaheksast põhialusest. XP asutajad täpsustasid CI metodoloogia nõudeid ning märkisid, et projekt tuleks kokku panna mitu korda päevas.

2000. aastate alguses hakkas katkematu integreerimise metodoloogiat propageerima üks Agile Alliance'i asutajatest Martin Fowler. Tema eksperiment CI-ga viis selle valdkonna esimese tarkvaratööriista, CruiseControl, loomise juurde. Tööriista lõi Martiniga kolleeg Matthew Foemmel.

Tööriistakeses on kogumise tsükkel rakendatud deemonina, mis kontrollib perioodiliselt versioonihaldussüsteemi koodibaasi muudatuste suhtes. Lahendust on võimalik tänaseni alla laadida – see levitatakse on BSD-laadse litsentsi all.

CI-suudava tarkvara ilmumisega hakkasid üha rohkem ettevõtteid seda praktikat omaks võtma. Forresteri uuringu kohaselt [leht 5 raportist] kasutas 2009. aastal 86% viiest kümnest küsitletud tehnoloogiaettevõttest CI meetodeid või viis neid ellu.

Tänapäeval rakendavad pideva integreerimise praktikat organisatsioonid erinevatest valdkondadest. 2018. aastal viis suur pilveteenuse pakkuja läbi küsitluse IT-spetsialistide seas teenindus-, haridus- ja rahandussektoris. Kuuest tuhande vastajast 58% vastas, et kasutavad oma töös CI tööriistu ja printsiipe.

Kuidas see töötab

Pideva integreerimise aluseks on kaks tööriista — versioneerimissüsteem ja CI-server. Viimane võib olla nii füüsiline seade kui ka virtuaalne masin pilves. Arendajad laadivad uue koodi üles üks või mitu korda päevas. CI-server kopeerib selle koos kõigi sõltuvustega ja käivitab kompileerimise. Pärast seda käivitab see integreerimis- ja ühikute testid. Kui testid läbitakse edukalt, deployib CI-süsteem koodi.

Üldist protsessi saab esitada järgmiselt:

CI metodoloogia esitab arendajatele mitmeid nõudmisi:

Probleeme tuleb kohe lahendada. See põhimõte on tulnud CI-sse ekstreemsest programmeerimisest. Veakorrektuur on arendajate kõige prioriteetseim ülesanne.
Protsessid tuleb automatiseerida. Arendajad ja juhid peavad pidevalt otsima „kitsaskohti” integreerimisprotsessis ja need kõrvaldama. Näiteks on sageli integreerimise "pudelikael" testimine. Koguseid tuleb teha võimalikult tihti.
Üks kord päevas, et meeskonna tööd sünkroonida. Rakendamise raskused

Esimene probleem on kõrged toimimis- ja hoolduskulud. Isegi kui ettevõte kasutab avatud CI tööriistu (millest me räägime hiljem), peab ta ikkagi investeerima infrastruktuuri hooldusse. Kuid lahendusena võivad olla pilvetehnoloogiad.

Need lihtsustavad erineva suurusega arvutikonfiguratsioonide kokkupanekut. Pluss ettevõtted

maksavad ainult kasutatud ressursside eest, mis aitab infrastruktuuri pealt kokku hoida. Küsimuste kohaselt [lk.14

], suurendab pidev integreerimine töötajatele koormust (vähemalt esialgu). Neil tuleb omandada uusi tööriistu ning kolleegid ei aita alati koolitamisega. Seetõttu tuleb uutega nagu raamistikud ja teenused „liikvel“ olles aru saada. artikleid], pidev integreerimine suurendab ettevõtte töötajate koormust (vähemalt esialgu). Neil tuleb omandada uusi tööriistu, kuid kolleegid ei aita alati koolitusega. Seetõttu tuleb uusi raamistikke ja teenuseid "liikvel olles" tundma õppida.

Kolmas raskusaste on automatiseerimise probleemid. Sellega seisavad silmitsi organisatsioonid, kellel on suur kogus pärandkoodi, mis ei ole automaatsete testidega kaetud. See viib selleni, et koodi kirjutatakse enne CI-täielikku rakendamist lihtsalt ümber.

/ Flickr / theilr / CC BY-SA

Kes kasutab

Üks esimesi, kes hindas meetodi eeliseid, olid IT-hiiglased. Google kasutab tutvustas pidevat integreerimist 2000. aastate keskpaiku. CI rakendati, et lahendada otsingumootori töö viivituste probleem. Pidev integreerimine aitas kiiresti tuvastada ja kõrvaldada tõrkeid. Praegu kasutavad CI-d kõik IT-hiiglase osakonnad.

Pidev integreerimine aitab ka väikestel ettevõtetel, ning CI tööriistu kasutavad ka finants- ja meditsiiniasutused. Näiteks aitasid Morningstar'i pideva integreerimise teenused 70% kiiremini turvaprobleeme parandada. Meditsiiniplatvorm Philips Healthcare suutis uuenduste testimist kahekordistada.

Tööriistad

Siin on mõned populaarsed CI tööriistad:

Jenkinsile — üks populaarsemaid CI-süsteeme. See toetab üle tuhande pistiku erinevate VCS-ide, pilveplatvormide ja muude teenustega integreerimiseks. Jenkinsit kasutame ka meie 1cloud'is: see tööriist on osa meie DevOps-süsteemist. See kontrollib regulaarselt Git haru, mis on ette nähtud testimiseks.
Buildbot — Python-raamistik, et kirjutada oma pideva integreerimise protsesse. Tööriista esialgne seadistamine on üsna keeruline, kuid seda kompenseerivad laiad kohandamisvõimalused. Raamistu eeliste seas toovad kasutajad esile selle madala ressursikasutuse.
Concourse CI — server Pivotalilt, mis kasutab Docker konteinerid. Concourse CI integreerub mis tahes tööriistade ja versioonihaldussüsteemidega. Arendajad märgivad, et süsteem sobib tööks igas suuruses ettevõtetes.
Gitlab CI — tööriist, mis on integreeritud versioonihaldussüsteemi GitLab. Teenus töötab pilves ja kasutab konfiguratsiooniks YAML-faile. Nagu Concourse, rakendab Docker konteinerid, mis aitavad erinevaid protsesse üksteisest eraldada.
Codeship — pilve CI-server, mis töötab GitHub'i, GitLab'i ja BitBucket'iga. Platvorm ei vaja pikaajalist esialgset seadistamist — Codeship'is on saadaval standardsed eelnevalt seadistatud CI-protsessid. Väikeste (kuni 100 kogumist kuus) ja avatud lähtekoodiga projektide jaoks on Codeship tasuta.