Amikor eldöntöttük, hogy rálépünk a folyamatos integráció (CI) vonzó, de új, és ezért rengeteg veszélyt rejtő ösvényére valamelyik eszköz mellett le kell tennünk a voksunkat. Ebben a választásban próbál segíteni ez az írás.

Miért tennénk ezt?

A Continuous Integration abból a megfigyelésből indult ki, hogy annál olcsóbb a hiba kijavítás, minél előbb vesszük észre azt, valamint a korrekció költsége az idővel exponenciálisan növekszik. Minél gyakrabban ellenőrzünk, fajlagosan annál olcsóbb lesz a hibák javítása. Ráadásul minél többet automatizálunk, minél többet dolgoztatunk gépeket emberek helyett annál olcsóbb és megbízhatóbb lesz a minőség biztosítása. Szóval, ha szeretnél gyorsan-olcsón-jól minőséget szállítani, akkor - sok száz összetevő mellett - szükséged lesz egy CI szerverre is. 2021-ben az a drámai igazság, hogy ezek az eszközök és módszerek használata olyan elterjedtté vált, hogy bevezetésük elengedhetetlen, ha meg akarja őrizni a piaci pozícióját egy cég.

Kézműves sziáj és az aszinkronitás

Amint fejest ugrunk a CI világába első körben szembejön velünk az az igény, hogy minden egyes push-ra lefussanak bizonyos automatizmusok. A Git verziókezelőben ott vannak a hook-ok, amik segítségével megvalósítható ez az igény. Nosza felgyűrjük az ingujjat és neki is esünk a probléma megoldásának. Első amivel szembesülni fogunk, hogy bármit is teszünk a build futását meg kell várni annak, aki pusholta a kódot. Ha igazán szigorúak, vagy inkább kegyetlenek vagyunk, akkor hibás build esetén nem is engedjük a központi tárolóba be a kódot. Ha nem akarjuk azt, hogy a fejlesztőink a munkaidejük nagy részében a buildekre várjanak, akkor kénytelenek leszünk megoldani, hogy a pushtól elválasszuk a buildet, vagyis szükségünk lesz egy CI szerverre.

Ez a CI szerver azután a háttérbe le tudja futtatni a buildet és az eredményről tájékoztatni fogja a fejlesztőket. Tudom, hogy pl. egy Redis szerverrel “egy óra alatt összerakható” egy ilyen CI szerver akár bash-ban is. Kell egy központi szerver és kellenek workerek/runnerek, amiket ráadásul bárhol futtathatunk a világban. Az alább ismertetett eszközök mindegyike ezt a szétválasztást követi. Óva intek azonban mindenkit, hogy egy ilyen fejlesztésnek neki lásson. A piacon ugyanis léteznek már kész, az előbbihez képest végtelen sok hasznos és egyéb szükséges funkcionalitással rendelkező megoldások.

Miért csak a Jenkins, Gitlab-CI és Github Action?

Számos on premise és SAAS megoldás létezik, de ezeket azért nem tárgyalom, mert nem próbáltam soha azokat, és weboldalukat elnézve nem tudok felsorakoztatni olyan szolgáltatásokat, amiket az alant tárgyalt megoldások ne nyújtanának egyenértékű vagy jobb megoldás keretében.

Konkrétan a Bitbucket pl. azért nem szerepel itt, mert saját runnert csak 2021 szeptemberétől lehet használni és annak is csak linuxos megoldása létezik.

Természetesen én se láttam mindent és biztos vagyok benne, hogy van ok amiért egy cég több ezer dollárt kifizet egy-egy ilyen termékért. Amennyiben van tapasztalatod és tudsz mondani ilyen megoldást az előnyökkel együtt, akkor kérlek ne tartsd magadban, oszd meg velem! Igyekszem majd kiegészíteni a bejegyzést.

Jenkins

Az egyik legismertebb ilyen megoldás a Jenkins/Hudson. Bár a Jenkins az egyik legrégebbi megoldás a piacon. Nincs olyan igény, amire ne kínálna megoldást, kivéve egyet. Ez pedig az, hogy integrálva legyen a verziókezelő rendszerünkbe. Amennyiben a Jenkinst választjuk mindenképpen meg kell oldanunk, hogy a verziókezelőbe érkező kódokról értesüljön a CI szerver.

Az első lehetőségünk a Git plugin használata. Érdekességképpen meg kell említeni, hogy ez a plugin több mint egy évvel előbb jelent meg mint maga a Gitlab és két évvel azelőtt, hogy a Gitlab-CI első, igencsak butácska verziója megjelent. A hátránya ennek a modulnak az, hogy nem a push eseményre indul el, hanem folyamatosan kérdezgeti a verziókezelő szervert.

Ezen javíthatunk, hisz a plugin alkalmas arra, hogy egy webhook segítségével indítsuk el a buildet, de ekkor is minimális konfigurálásra szükségünk lesz.

Talán ebből is látszik, hogy a Jenkins belépési küszöbe magasabb, mint a többi integrált rendszeré, de egy igazi hozzáértő jóval komplexebb megoldást össze tud vele rakni. Ez utóbbi alatt különböző adatvizualizációs és értesítési megoldásokra kell gondolni.

Fel lehetne sorolni a Jenkis előnyeként még azt is, hogy bármelyik verziókezelő rendszerrel (CVS, SVN, Mercurial) tud működni, de ezt figyelembe véve a mai verziókezelő piacot nem jelent valódi előnyt egy most induló projektnél. Természetesen, ha egy legacy csodát kell CI alá helyezni, aminél a cég ragaszkodik a régi, megszokott verziókezelőhöz, akkor a Jenkis egy jó megoldás lehet.

Gitlab-CI és a Github Actions

Vannak különbségek a két rendszer között de, ha most indulsz, akkor mindegy melyik eszköz mellett teszed le a voksod. Mindkettő git támogatással rendelkezik és a build eredményei az adott merge vagy push request vagy branch mellett megjelenik. Mindkettő képes több stageből álló pipeline-t futtatni, ahol az egyes stage-ek párhuzamosan futtatott job-okból állnak. Mindkettő tud artifactokat kezelni, amik az egyes jobok között megoszthatóak, valamint rendelkezik valamilyen cache megoldással amivel a pipelineok közötti adatmegosztás valósítható meg.

A Gitlab-CI runner többfajta futtató megoldást támogat. A Github Actions megoldása a shell futtatóhoz (executor) van a legközelebb, de ezen túl a Gitlab-CI számos egyéb megoldást támogat még.

Ezzel szemben áll az, hogy a Github Actions rendelkezik egy közösségi megoldás megosztóval (Marketplace), ami segítségével találhatunk a kedvünkre való megoldást, amit könnyen használható a pipeline-unkban.

A Gitlab-CI environment része az ami a Github Action-ben nincs meg. Ez lehetővé teszi, hogy az egyes merge requestekhez kipróbálható teszt környezeteket kapcsoljunk.

Mindkét eszköz tud különböző színes címkéket megjeleníteni az egyes projekteknél és a build logot is elérhetjük mindkettőnél.

Ezek a szolgáltatások automatikusan elérhetőek ezekben a rendszerekben, míg a Jenkinsbe ezeket külön pluginekkel tudjuk csak megvalósítani.

Tapasztalatom szerint a legnagyobb hátrányuk ezeknek az integrált rendszereknek, hogy a különböző fontos információkat historikusan nem, vagy csak nagyon alap formában tudjuk megjeleníteni. A Jenkinsben nem okoz problémát egy codecoverage vagy egyéb a kód minőségére utaló mutató historikus ábrázolása, csak a megfelelő plugint kell telepíteni és a kezdőképernyőre kihelyezni azt. Amennyiben nem tetszik számos beállítás segítségével tudjuk testreszabni és módosítani a diagramot. A grafikonra kattintva eljutunk egy részletező képernyőre, ahol fájlra lebontva láthatjuk a JUnit xml-ből kinyert információkat. Ezzel szemben pl. a Gitlab-CI-ban csak az egy darab össz coverage értéket tudjuk megjeleníteni, melynek historikus ábrázolása sincs nagyon megoldva. Amennyiben részletes információkra vágyunk, úgy külső megoldásra lesz szükségünk.

Összefoglalás

Összefoglalva elmondható, hogy ha nem akarod keretek közé szorítani magad, cserébe elfogadod a magasabb belépési küszöböt, akkor a Jenkinst neked találták ki.

Az integrált megoldások legnagyobb előnye, hogy ha rendelkezel Github vagy Gitlab ingyenes vagy fizetős azonosítóval, akkor már most elkezdheted a használatukat. Amire figyelned kell, hogy az ingyenes csomagok tartalmaznak ugyan a jobok futtatásához szükséges, de korlátozott erőforráskeretet, de ez a kipróbáláson túl nem sokmindenre lesz elég. Cserébe viszont mindkét rendszernél könnyedén megoldható, hogy vagy fizetsz értük, vagy megoldod, hogy a runnerek ne a szolgáltató, hanem a saját gépen vagy szerveren fussanak. Gitlabnál a legegyszerűbb és egyben a legolcsóbb megoldás, amikor minden fejlesztő gépére feltelepíted a Gitlab Runnert így a jobok a háttérben szépen elfutnak miközben a fejlesztő dolgozik. Egy erősebb géppel dolgozó fejlesztő meg se fogja érezni ezt a többlet erőforrás felhasználást. Ráadásul ez a megoldás automatikusan skálázódik is. Bejön a fejlesztő, bekapcsolja a gépét és máris eggyel több runner várja a feladatokat.

Amennyiben úgy döntesz, hogy belevágsz és kell segítség keress meg nyugodtan. Évek óta támogatok csapatokat a CI/CD és a hozzá kapcsolódó modern fejlesztési módszertanok és eszközök bevezetésével.

Arek Socha képe a Pixabay -en.