GitLab CI ali Jenkins: hitrejši cevovod lahko zahteva več vzdrževanja

Če ekipa že uporablja GitLab in potrebuje običajno gradnjo, testiranje ter namestitev, je GitLab CI/CD preprostejše izhodišče. Opravila, njihove faze, izvajalno sliko in predpomnilnik opredeli v datoteki .gitlab-ci.yml, kot določa GitLabova konfiguracija CI/CD. Jenkins je lahko primernejši, kadar obstoječi cevovodi temeljijo na posebnih integracijah in jih ekipa že zna upravljati.

Hitrejša izvedba opravila še ne pomeni manj dela za platformno ekipo. Jenkinsov vodnik za Pipeline opisuje cevovod kot zbirko vtičnikov, ki podpira deklarativni in skriptni zapis; Jenkinsfile je mogoče hraniti v repozitoriju. Pri izbiri je zato treba ločiti čas od začetka gradnje do konca namestitve od časa za upravljanje krmilnika, agentov, vtičnikov in morebitne selitve.

Nastavitev ni izbira med kodo in klikanjem

Obe orodji omogočata, da ekipa definicijo cevovoda pregleda skupaj s spremembami aplikacije. Pri GitLabu je .gitlab-ci.yml del projekta in uporablja istega ponudnika za repozitorij ter CI/CD. Jenkinsfile lahko prav tako živi ob kodi, vendar Jenkins za izvedbo potrebuje povezavo do repozitorija, primerne agente in ustrezne vtičnike. Prednost integracije je največja tam, kjer ekipa GitLab že uporablja tudi za pregled sprememb in upravljanje projekta.

Integrirana nastavitev ne odstrani potrebe po izvajalnih virih. Opravilo GitLab CI/CD mora dobiti razpoložljivega izvajalca, ustrezno okolje in dostop do odvisnosti; ekipa z lastnimi izvajalci skrbi tudi zanje. Pri Jenkinsu je podobno pomembno, kje opravilo dejansko teče: krmilnik usklajuje potek, agent pa zagotavlja okolje za ukaze. Primerjava zahtevnosti mora zato zajeti konkretno postavitev ekipe, ne samo dolžine konfiguracijske datoteke.

Vtičniki razširijo Jenkins in povečajo obseg upravljanja

Jenkinsovi vtičniki lahko dodajo povezavo z gradbenim orodjem, ponudnikom infrastrukture ali načinom poročanja, ki ga obstoječi potek že uporablja. Jenkinsova navodila za vtičnike opisujejo njihove odvisnosti, nameščene različice, posodobitve in odstranjevanje; pri nekaterih spremembah je potreben ponovni zagon krmilnika. To je upravljavsko delo, ki ga ura posamezne gradnje ne zajame.

Koristen popis se začne pri vtičnikih, ki jih opravila res potrebujejo, ne pri vseh, ki so nameščeni. Pri vsakem je pomembno vedeti, katera opravila ga kličejo, kdo spremlja njegove posodobitve in ali je odvisen od drugega dodatka. V popis sodijo še skupne knjižnice, poverilnice in orodja na agentih: tudi če Jenkinsfile ostane enak, lahko sprememba katerega od teh delov zahteva poseg v cevovod. Enako pošteno je v strošek GitLaba vključiti vzdrževanje lastnih izvajalcev, kadar jih ekipa uporablja.

Kaj je v resnici izmerila primerjava hitrosti

V objavljeni študiji spletne aplikacije Basu Dairy Farm so v treh različnih preizkusih izmerili povprečni čas gradnje in namestitve 17,33 sekunde za Jenkinsovo postavitev ter 26,66 sekunde za postavitev GitLab CI/CD. Čas so šteli od začetka gradnje do konca namestitve, ne od trenutka, ko razvijalec odda spremembo. Preizkusi so obravnavali spremembe iste monolitne aplikacije, niso pa bili ponovitve povsem enakega opravila.

Obe orodji sta bili nameščeni na navideznih strežnikih z enako navedeno specifikacijo, vendar opravili nista tekli v enakih izvajalnih okoljih. Jenkins je uporabljal vgrajenega agenta z 8 GiB pomnilnika in že nameščenim vtičnikom NodeJS. GitLabovo opravilo je teklo v vsebniku Docker z navedenimi 7,704 GiB pomnilnika in sliko node:16. Razlika v pripravi okolja in razpoložljivem pomnilniku lahko vpliva na trajanje, zato izmerjene prednosti ni mogoče pripisati samo izbiri orodja CI/CD.

Rezultat pove nekaj uporabnega o teh dveh postavitvah: pri opisani gradnji in namestitvi je bila Jenkinsova pot hitrejša. Ne meri pa čakanja pred začetkom gradnje, časa skrbnikov za posodobitve ali zahtevnosti prenosa cevovodov. Ker so bile spremembe med preizkusi različne in je bilo meritev malo, številki nista splošna napoved za drugo aplikacijo. Prav tu nastane možna cena hitrejšega cevovoda: prednost pri izvajanju lahko spremlja dodatno delo z okoljem, ki to prednost omogoča.

Primerljiva meritev potrebuje enake pogoje

Za odločitev v lastnem projektu naj ekipa ohrani iste ukaze za gradnjo, teste in namestitev ter enake različice potrebnih orodij. Agent in izvajalec naj imata primerljivo procesorsko ter pomnilniško zmogljivost in dostopata do istega ciljnega okolja. Če ena pot uporablja že pripravljen Node.js, druga pa mora najprej pridobiti izvajalno sliko, je treba ta čas prikazati posebej. Sicer primerjava združi vpliv orodja z vplivom priprave okolja.

Enako velja za predpomnilnik. Izvedba, ki mora odvisnosti prenesti na novo, odgovarja na drugo vprašanje kot ponovitev s pripravljenimi odvisnostmi; obe stanji sta za ekipo lahko pomembni. Smiselno je ločeno zapisati čakanje v vrsti, pripravo okolja, trajanje ukazov in prenos artefaktov. Pri več sočasnih opravilih naj bo primerljivo tudi število razpoložljivih agentov oziroma izvajalcev, saj hitro opravilo ne skrajša celotnega cevovoda, če mora dolgo čakati na prost vir.

Selitev je strošek vsake odvisnosti, ne samo datoteke

Pri prehodu z Jenkinsa na GitLab CI/CD je treba poleg pravil v Jenkinsfile pregledati še vtičnike, orodja na agentih, skupne knjižnice, poverilnice in dostop do drugih projektov. Te odvisnosti našteva GitLabov vodič za selitev, ki opisuje tudi JenkinsFile Wrapper: ta lahko znotraj opravila GitLab CI/CD zažene obstoječi Jenkins z vtičniki, vendar ni del GitLabovega paketa in ni v obsegu njegove podpore.

Wrapper omogoča postopnejši prenos, ne odpravi pa upravljanja Jenkinsa, dokler opravila še uporabljajo njegovo instanco. Obseg selitve je zato bolje oceniti po posameznem cevovodu: katero sprožilno pravilo je treba prenesti, kam se shranijo artefakti, kako opravilo dobi skrivnosti in katera funkcija vtičnika zahteva nadomestitev. Če je vtičnik le ovoj za ukaz gradbenega orodja, je prenos lahko manj zahteven kot pri integraciji, na katero so vezana druga opravila.

Odločitev je najjasnejša, ko ekipa za obe možnosti zapiše trajanje primerljivo opremljenega cevovoda, delo za redno vzdrževanje in obseg selitve. GitLab CI/CD je razumna izbira za ekipo, ki že dela v GitLabu in lahko zahtevani potek sestavi z njegovimi funkcijami. Jenkins ohrani vrednost tam, kjer njegove obstoječe prilagoditve rešujejo konkretne zahteve in je skrb zanje sprejemljiva. Izmerjen prihranek sekund ima težo šele skupaj s stroškom okolja, ki ga zagotavlja.

Preberite tudi:

• Hugging Face ali Replicate: mirovanje modela lahko stane več kot izvajanje
• OBS ali Streamlabs: lažja nastavitev lahko porabi do 28 % več procesorja
• Claude Code ali Gemini CLI: brezplačnih 1.000 zahtev ne zagotovi hitrejše naloge