🥇Referenca: si funksionon procesi i Integrimit të Vazhdueshëm

Sot në historinë e termit, do të diskutojmë vështirësitë e implementimit të CI dhe do të japim disa mjete të njohura që ndihmojnë në punën me të.

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

Termi

Continuous Integration (integrimi i vazhdueshëm) është një qasje për zhvillimin e aplikacioneve që përfshin zhvillimin e shpeshtë të ndërtimeve të projektit dhe testimin e kodit.

Qëllimi është të bëhet procesi i integrimit parashikueshëm dhe të zbulojnë potencialet gabime dhe defekte në një fazë të hershme, në mënyrë që të ketë më shumë kohë për t'i korrigjuar ato.

Për herë të parë, termi Continuous Integration u shfaq në vitin 1991. Ai u fut në përdorim nga krijuesi i gjuhës UML. Grady Booch (Grady Booch). Inxhinieri prezantoi konceptin e CI si pjesë e praktikës së tij të zhvillimit - metodës së Buch.Ai nënkuptonte përmirësimin incrementale të arkitekturës gjatë projektimit të sistemeve të orientuara nga objektet. 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 qëllimi i metodikës është të përshpejtojë lëshimin e "publikimeve të brendshme".

Historia

Në vitin 1996, CI u mor nga krijuesit e metodologjisë programimit ekstrem (XP) - Kent Beck (Kent Beck) dhe Ron Jeffries (Ron Jeffries). Integrimi i vazhdueshëm u bë një nga dymbëdhjetë parimet kyçe të qasjes së tyre. Themeluesit e XP saktësuan kërkesat për metodologjinë CI dhe vunë në dukje 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 (Martin Fowler). Eksperimentet e tij me CI çuan në shfaqjen e mjetit të parë programor në këtë fushë - CruiseControl. Utilitarin e krijoi kolegu i Martinit - Matthew Foemmel.

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

Me shfaqjen e softuerit për CI, praktikën filluan ta merrnin gjithnjë e më shumë kompani. Sipas një studimi nga Forrester [f.5 raporti] në vitin 2009, 86% nga pesëdhjetë kompanitë teknologjike të anketuara përdornin ose po implementonin metodat CI.

Sot që nga sot, praktika e Continuous Integration po zbatohet nga organizata të industrive të ndryshme. Në vitin 2018, një ofrues i madh të shërbimeve cloud zhvilloi një anketë midis profesionistëve IT nga sektori i shërbimeve, edukimit dhe financave. Nga gjashtë mijë respondentë, 58% thanë se përdorin në punën e tyre mjete dhe parime të CI.

Si funksionon kjo

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

Skema e përgjithshme e procesit mund të paraqitet si më poshtë:

Metodologjia CI ka disa kërkesa për zhvilluesit:

Të riparojnë menjëherë problemet. Ky parim erdhi në CI nga programimi ekstrem. Rregullimi i defekteve është detyra më prioritare për zhvilluesit.
Të automatizojnë proceset. Zhvilluesit dhe menaxherët duhet të kërkojnë vazhdimisht «vështirësitë» në procesin e integrimit dhe t'i eliminojnë ato. Për shembull, shpesh një «qafë gize» e integrimit rrethanat tregojnë testimi.
Të realizojnë ndërtimet sa më shpesh që të jetë e mundur. Një herë në ditë, për të sinkronizuar punën e ekipit.

Vështirësitë në zbatimin e CI

Problemi i parë është kostoja e lartë operative. Edhe nëse një kompani përdor mjete të hapura CI (për të cilat do të flasim më vonë), ajo ende duhet të shpenzojë para për mbështetje të infrastrukturës. Megjithatë, teknologjitë cloud mund të ofrojnë një zgjidhje.

Ato e thjeshtojnë ndërtimin e konfiguracioneve kompjuterike në shkallë të ndryshme. Po ashtu, kompanitë paguhen paguajnë vetëm për burimet e përdorura, gjë që ndihmon për të kursyer në infrastrukturë.

Sipas anketave [str.14 artikulli], integrimi i vazhdueshëm rrit ngarkesën mbi punonjësit e kompanisë (të paktën në fillim). Atëherë ata duhet të mësojnë mjete të reja, dhe kolegët nuk ndihmojnë gjithmonë në trajnimin. Prandaj, ata duhet të mësojnë për frameworkët dhe shërbimet e reja «në lëvizje».

Sfidha e tretë është problemet me automatizimin. Këto hasen në organizatat me një volum të madh të kodit legacy që nuk mbulohet nga testet automatizuar. Kjo çon në faktin që kodi thjesht ridizajnohet para implementimit të plotë të CI.

/ Flickr / theilr / CC BY-SA

Kush përdor

Një nga herët e para që përfitimet e metodologjisë i vlerësuan gjigandet e IT-së. Google përdor implementoi integrimin e vazhdueshëm që nga mesi i viteve 2000. CI u fut për të zgjidhur problemin e vonesave në punën e sistemit të kërkimit. Integrimi i vazhdueshëm ndihmoi në identifikimin dhe zgjidhjen e defekteve në kohë. Tani CI përdoret nga të gjitha njësitë e gjigandit të TI-së.

Integrimi i vazhdueshëm ndihmon edhe kompanitë e vogla, ndërsa mjetet 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 dobësive 70% më shpejt. Ndërsa platforma mjekësore Philips Healthcare arriti të dyfishojë shpejtësinë e testimit të azhurnimeve.

Mjetet

Ja disa nga mjetet e njohura për CI:

Jenkins — një nga sistemet CI më të njohura. Ajo mbështet më shumë se një mijë pozita për integrim me VCS të ndryshëm, platforma cloud dhe shërbime të tjera. Jenkins e përdorim edhe ne në 1cloud: mjeti këtu bëhet pjesë e sistemit tonë DevOps. Ai kontrollon rregullisht degën Git, të destinuar për testim.
Buildbot — një framework python për shkruarjen e proceseve të veta të integrimit të vazhdueshëm. Cilësimi fillestar i mjetit është mjaft i komplikuar, megjithatë kjo kompensohet me mundësi të gjera për personalizim. Mes përfitimeve të framework-ut, përdoruesit veçojnë konsumimin e ulët të burimeve.
Concourse CI — një server nga Pivotal, i cili përdor kontejnerë Docker. Concourse CI integrohet me çdo mjet dhe sistem të kontrollit të versioneve. Zhvilluesit theksojnë se sistemi është i përshtatshëm për punë në kompani të çdo përmasash.
Gitlab CI — një mjet i integruar në sistemin e kontrollit të versioneve GitLab. Shërbimi punon në re dhe përdor skedarët YAML për konfigurim. Si Concourse, Gitlab CI aplikon kontejnerë Docker, të cilët ndihmojnë në izolimin e proceseve të ndryshme nga njëri-tjetri.
Codeship — një server CI në re, që punon me GitHub, GitLab dhe BitBucket. Platforma nuk kërkon një konfigurim fillestar të gjatë — në Codeship janë të disponueshme proceset standarde të paracaktuara CI. Për projektet e vogla (deri në 100 ndërtime në muaj) dhe projektet open source, Codeship është i disponueshëm falas.