🥇Referencë: si funksionon procesi i Continuous Integration

Sot do të flasim për historinë e termit, do të diskutojmë vështirësitë e implementimit të CI dhe do të japim disa mjete të njohura që do t'ju ndihmojnë në këtë proces.

/ Flickr / Altug Karakoc / CC BY / Фото изменено

Termi

Continuous Integration (integrare e vazhdueshme) është një qasje për zhvillimin e aplikacioneve, e cila parashikon kryerjen të shpeshta të ndërtimeve të projektit dhe testimin e kodit.

Qëllimi është të bëhet procesi i integrimit parashikues dhe të zbulohen defekte dhe gabime potenciale në një fazë të hershme, për të pasur më shumë kohë për t'i korrigjuar ato.

Termi Continuous Integration u shfaq për herë të parë në vitin 1991. Ai u duhet nga krijuesi i gjuhës UML Grady Booch (Grady Booch). Inxhinieri e paraqiti konceptin e CI si pjesë të praktikës së tij të zhvillimit — metoda e Booch. Ai nënkuptonte përmirësimin incremental të arkitekturës gjatë dizenjimit të sistemeve objektor. Grady nuk përshkroi ndonjë kërkesë për integrimin e vazhdueshëm. Por më vonë në librin e tij “Object-Oriented Analysis and Design with Applications” ai tha se detyra e metodikës është të shpejtojë lëshimin e “rilizimeve të brendshme”.

Historia

Në vitin 1996 CI u mor nga krijuesit e metodologjisë programimit ekstrem (XP) — Kent Beck dhe Ron Jeffries. Integrimi i vazhdueshëm u bë një nga dymbëdhjetë parimet thelbësore të qasjes së tyre. Themeluesit e XP saktësuan kërkesat për metodologjinë CI dhe theksuan nevojën për të ndërtuar projektin disa herë në ditë.

Në fillim të viteve 2000, metodologjinë e integrimit të vazhdueshëm e promovoi një nga themeluesit e Agile Alliance Martin Fowler. Eksperimentet e tij me CI çuan në zhvillimin e mjetit të parë softuerik në këtë fushë – CruiseControl. Utilitarin e krijoi kolegu i Martin, Matthew Foemmel.

Cikli i ndërtimit në këtë mjet është realizuar si një demon që kontrollon periodikisht sistemin e menaxhimit të versioneve për ndryshime në bazën e kodit. Zgjidhja mund të shkarkohet edhe sot – ajo distribuohet është nën licencën e ngjashme me BSD.

Me shfaqjen e softit për CI, praktika filloi të përvetësohej nga një numër gjithnjë e më të madh kompanish. Sipas një studimi të Forrester [f.5 raporti] në vitin 2009, 86% e pesëdhjetë kompanive teknologjike të pyetura përdoren ose po implementojnë metodat e CI.

Sot praktika Continuous Integration aplikohet nga organizatat në industri të ndryshme. Në vitin 2018, një ofrues i madh i shërbimeve në cloud realizoi një anketë ndër specialistët e IT-së nga sektorët e shërbimeve, arsimit dhe financave. Nga gjashtë mijë përgjigjës, 58% thanë se përdorin mjete dhe parime CI në punën e tyre.

Si funksionon

Thelbi i integrimit të vazhdueshëm përbëhet nga dy mjete — sistemi i kontrollit të versioneve dhe CI-serveri. Ky i fundit mund të jetë si një pajisje fizike ashtu edhe një makinë virtuale në mjedisin cloud. Zhvilluesit ngarkojnë kod të ri një ose disa herë në ditë. CI-serveri automatikisht kopjon atë me të gjitha varësitë dhe e ndërlikon atë. Më pas, fillon testet integruese dhe testet njësi. Nëse testet kalojnë me sukses, sistemi CI zhvillon kodin.

Diagrami i përgjithshëm i procesit mund të paraqitet si më poshtë:

Metodologjia CI parasheh një sërë kërkesash për zhvilluesit:

Të rregullojnë menjëherë problemet. Ky parim erdhi në CI nga programimi ekstrem. Korrigjimi i defekteve është detyra më e rëndësishme për zhvilluesit.
Të automatizojnë proceset. Zhvilluesit dhe menaxherët duhet të kërkojnë vazhdimisht "ngushticat" në procesin e integrimit dhe t'i eliminojnë ato. Për shembull, shpesh "ngushtica" e integrimit ndodh testimi.
Të kryhen ndërtimet sa më shpesh të jetë e mundur. Një herë në ditë, për të sinkronizuar punën e ekipit.

Vështirësitë e zbatimit

Problemi i parë është shpenzimet e larta operative. Edhe nëse kompania përdor mjete CI të hapura (të cilat do t'i diskutojmë më tej), ajo ende do të duhet të shpenzojë para për mbështetje infrastrukturore. Sidoqoftë, teknologjitë në re mund të jenë një zgjidhje.

Ato përmirësojnë ndërtimin e konfiguracioneve të ndryshme kompjuterike. Plus, kompanitë paguajnë vetëm për burimet e përdorura, gjë që ndihmon të kursejnë në infrastrukturë.

Sipas anketimeve [str.14 artikullit], integrimi i vazhdueshëm rrit ngarkesën mbi punonjësit e kompanisë (të paktën fillimisht). Ata duhet të mësojnë mjete të reja, dhe kolegët nuk ndihmojnë gjithmonë me trajnimin. Prandaj, ata duhet të përballen me kornizat dhe shërbimet e reja "në lëvizje".

Sfidës e tretë — problemet me automatizimin. Kjo ndodh me organizatat që kanë një sasi të madhe kodi legacy, i cili nuk është mbuluar me teste automatike. Kjo çon në faktin se kodi thjesht ri-shkruhet para implementimit të plotë të CI.

/ Flickr / theilr / CC BY-SA

Kush e përdor

Një nga të parët që vlerësuan përfitimet e metodologjisë ishin gjigantët e IT-së. Google përdor ka zbatuar integrimin e vazhdueshëm që nga mesit të viteve 2000. CI u implementua për të zgjidhur problemin e vonesave në funksionimin e motorit të kërkimit. Integrimi i vazhdueshëm ndihmoi në zbulimin dhe eliminimin e defekteve me shpejtësi. Tani CI përdoret nga të gjitha degët e gjigantit të IT-së.

Integrimi i vazhdueshëm ndihmon edhe kompanitë e vogla, dhe gjithashtu instrumentet CI përdoren nga organizatat financiare dhe mjekësore. Për shembull, në Morningstar, shërbimet e integrimit të vazhdueshëm ndihmuan në patchimin e vulnerabiliteteve 70% më shpejt. Platforma mjekësore Phillips Healthcare arriti të dyfishojë shpejtësinë e testimit të përditësimeve.

Mjetet

Ja disa nga instrumentet më të njohura për CI:

Jenkins — një prej sistemeve më të njohura CI. Ajo mbështet më shumë se një mijë plugina për integrimin me VCS të ndryshme, platforma në cloud dhe shërbime të tjera. Jenkins është përdorur edhe nga ne në 1cloud: një instrument pjesë e sistemit tonë DevOps. Ai kontrollon rregullisht degën Git që është e destinuar për testim.
Buildbot — një framework Python për të shkruar procese të vazhdueshme integrimi. Konfigurimi fillestar i mjetit është relativisht i komplikuar, megjithatë, kjo kompensohet nga mundësitë e gjera të personalizimit. Përdoruesit veçojnë konsumimin e ulët të burimeve si një avantazh të këtij framework-u.
Concourse CI — një server nga Pivotal që përdor konteinerë Docker. Concourse CI integrohet me çdo mjet dhe sistem kontrolli versioni. Zhvilluesit theksojnë se sistemi është i përshtatshëm për punë në kompani të çdo madhësie.
Gitlab CI — një mjet i integruar në sistemin e kontrollit të versioneve GitLab. Shërbimi punon në re dhe përdor skedarë YAML për konfigurim. Si Concourse, GitLab CI përdor konteinerë Docker, që ndihmojnë në izolimin e proceseve të ndryshme nga njëra-tjetra.
Codeship — një server CI në re që punon me GitHub, GitLab dhe BitBucket. Platforma nuk kërkon një konfigurim të gjatë fillestar — janë të disponueshme proceset standarde CI të parainstaluara në Codeship. Për projekte të vogla (deri në 100 ndërtime në muaj) dhe projekte open source, Codeship është në dispozicion falas.