Jenkins - Pipeline Version Updater plugin

Nemrég blogoltam a Jenkins Delivery Pipeline használatának előnyeiről és arról, hogy a pipeline verziószáma kiemelt szereppel bír, mivel végig kíséri az összes lépést és benne lesz a létrejött telepítési egységek nevében is. A verziószám generálását többféleképpen el lehet végezni, most csak egy lehetséges megoldást szeretnék bemutatni, ami éppen illeszkedett ahhoz környezethez ahol a kialakított CI rendszert használták.

Az ötletem, aminek a megvalósításához fejlesztettem egy Jenkins plugin-t az volt, hogy a pipeline verziószáma két részből álljon, az első rész a legfrissebb SCM TAG értéke legyen (pl.: v2.0.0) a második rész pedig egy 1-ről induló, buildenként növekvő szám, ami egy új TAG érkezésekor mindig 1 értékre inicializálódik. Azért, hogy az SCM tag értékénél a verziószám pattern-t kötelező legyen betartani, szerver oldali GIT HOOK-ot alkalmaztam, hasonlóan ahhoz mint amit ebben a cikkben írtam.

Az elkészült plugin forráskódját megnyitottam és feltöltöttem a github-ra. A használatához csak be kell pipálni a Pipeline Version Updater checkbox-ot a Build Environments szekció alatt, ahogy az alábbi kép is mutatja.

Most pedig nézzük meg gyakorlatban is a plugin verziózásának működését, az alábbi pipeline részlet alapján. A legfrissebb scm tag a v2.0.0 volt így az első build indításakor a v2.0.0.1 lett a pipeline verziószám. A következő build indításakor sem érkezett újabb scm tag, ezért a pipeline verziószám v2.0.0.2 értéket vette fel.

Ezután a vezető fejlesztő meg-tag-geli a forráskódot a v2.0.1 verziószámmal, ahogy az alábbi kép is mutatja.

A következő buildnél a v2.0.1.1 értéket veszi fel a verziószám, a legfrissebb scm tag és az 1-ről induló build number alapján.

Ez lenne az általam kialakított pipeline verziószámozós rendszer. Ha kérdésed lenne ezzel kapcsolatban, esetleg Ti más utat választottatok a verziózáshoz szívesen veszem az ötleteket.

Stay tuned...!

Robot teknősök - Személyes tapasztalatok

A robot teknősök társasjátékról már írtam korábban a játékos programozás gyerekeknek sorozatban, azonban most szeretném a saját tapasztalataimat is megosztani a játékkal kapcsolatosan. A kisfiam 4 éves születésnapjára kapta tőlem ezt a társasjátékot és azonnal láttam hogy tetszeni fog neki, sok szép színes kártya amiket lehet rakosgatni... 

Megbeszéltük a szabályokat és elkezdtünk vele játszani. A szabályok szerint ő pakolta le a kártyákat, én pedig a lerakott kártyák alapján irányítottam a teknőst, valamint néha szerepet is cseréltünk. Egy nekifutásra 2 játékot tudtunk játszani (kb. 15 perc, utána mással játszottunk mert megunta) de nagy meglepetésemre, így is nagyjából 5 nap alatt végig mentünk az összes pályán (1. kőfal, 2. jégfal+lézer, 3. tolható láda, 4. funkció béka). Nagyon érdekes volt, hogy a függvény hívást - a funkció béka kártya lerakásával egy általunk előre megadott kártyasor lépései hajthatók végre - azonnal megértette és tudta is használni. Persze ennek nagyon örültem, azonban ezzel kijátszottuk a játékot és nincsenek újabb kártya típusok amiket pedig még várt volna...

Megfigyeltem, hogy nem menet közben gondolja ki, hogy melyik lesz a következő kártya amit le fog tenni, hanem miután felépítettem az akadálypályát, még a játék kezdete előtt a kezével végigmutatja, hogy merre fogja majd irányítani a teknőst, azaz előre megtervezi annak az útvonalát (a programsort), aztán csak gyorsan ledobálja a kártyákat én meg tologatom a teknőst és kiadom a kötelező berregő hangokat.

Ez egy ajánlott vétel! .)

dynaTrace - JDBC batch insert

A teljesítménybeli problémák egy része konfigurációs (jvm, pool) hiányosságokra vezethető vissza, azonban a legtöbb esetben mégis maga az alkalmazás kódja vagy az egyes API-k ill. keretrendszerek nem megfelelő használata okozza a legsúlyosabb veszteségeket. Már az egyetemen is mondogatták, hogy nagy mennyiségű adat beszúrását kötegelve végezzük el, mert a DML műveletek (insert, update, delete) egyenként történő végrehajtása, külön-külön adatbázis feldolgozást és magasabb hálózati overhead-et is jelent.

Az alábbi program 20.000 JDBC insert műveletet fog lefuttatni egyenkénti (tehát nem kötegelt) végrehajtással.

Ahogy a dynaTrace PurePath dashleten is láthatjuk, a válaszidő 13.4 másodperc volt, 97%-ban Input-Output művelettel a lekérdezések végrehajtásánál.

Módosítsuk a programot és nézzük meg, hogy mennyi javulást érünk el, ha az insert műveleteket kötegelve hajtjuk végre.

Az alábbi képen látható eredmény magáért beszél, sikerült a válaszidőt 1.8 másodpercre lecsökkenteni minimális forráskód módosítással. 

Érdemes arra odafigyelni, hogy a nagyméretű kötegek esetén időnként (minden x insert után) futtassunk le egy JDBC batch insertet, különben OutOfMemorError keletkezhet amennyiben a heap memória megtelik!