dynaTrace Certified Associate

Ma délelőtt sikeresen leraktam a Dynatrace Application Monitoring 6.2 Associate Certification vizsgát az Examity vizsgarendszeren keresztül. Hasonlóan más gyártókhoz, a dynaTrace is 3 szintet határozott meg a tanúsítványoknál: Associate, Professional, Master. Szóval itt is maradtak az APM rövidítésnél... :)

A vizsgán 73 kérdésre kellett válaszolni 73 perc alatt, amiből a végén csak 45 másodpercem maradt, szóval igyekeznem kellett. A nehézségi szintet elég jól belőtték, voltak benne lexikális tudásra építő, a dynaTrace belső működésének ismeretét feltételező és "hogyan oldanád meg" típusú kérdések is. Így utólag azt mondanám, hogy aki részt vett már egy Telvice-es core dynaTrace tréningen és legalább fél éve aktívan használja a dynaTrace-t, annak már érdemes megpróbálkozni vele. A vizsga ára 200 USD. Ha esetleg több infó is érdekelne a vizsgával kapcsolatban, ne kíméljetek...

Jenkins - Delivery Pipeline, Build Pipeline

Pár éve már írtam a Jenkins-ről és a folyamatos integráció (CI = Continuous integration) lényegéről, most pedig a KEKKH-s CI bevezetési projektem kapcsán ennek a "tovább fejlesztéséről" szeretnék pár gondolatot megosztani. 

Kisebb projekteknél talán még elfogadható lehet, ha minden részfeladatot egy Jenkins job-ba sűrítünk, azonban hamar a következő igények merülhetnek fel:

• Vizuálisan is szeretnénk lekövetni, hogy éppen melyik lépés futtatásánál tart a folyamat
• Sebesség optimalizálás céljából, szeretnénk beazonosítani a lassú lépéseket
• Vannak olyan lépések amelyeket párhuzamosan is lehetne futtatni
• Párhuzamos lépések esetén csak akkor akarunk tovább haladni ha minden párhuzamosan indított lépés sikeres volt (join)
• Egy adott lépéstől kezdve szeretnénk indítani a pipeline-t. (pl. a terheléses teszteléstől)

Ezen igények megvalósítására két Jenkins plugint is bevethetünk: Build Pipeline és a Delivery Pipeline. Én az utóbbit választottam, mert a build pipeline a párhuzamosan join-olt jobokat nem jeleníti meg jól.

Az alábbi képernyőképen az NLR alkalmazáshoz kialakított CI Pipeline látható. A dobozkák magukért beszélnek, így csak röviden írnám le mi is történik az egyes lépéseknél. A Build lépés során a forráskód lefordul és létrejönnek a telepíthető modulok, alkalmazások. A Unit Test lépésnél kiderül, hogy vajon funkcionálisan is minden jól működik. A Static Code Analysis lépésnél elindul egy SonarQube alapú kódellenőrzés, amivel párhuzamosan Cobertura alapú kódlefedettség (Code Coverage) és JBoss Tattletale alapú könyvtár függőség elemzés (JAR Analysis) is történik. Amikor ezen lépések mindegyike sikeresen befejeződött a modulokat ki kell tenni (Deploy) az alkalmazás szervere, majd egy gyors Smoke tesztet futtatni a telepítés sikerességének ellenőrzéséhez. Ezután következhet a dynaTrace-szel integrált JMeter alapú teljesítmény tesztek futtatása (Performance Test), majd a dynaTrace-szel integrált Selenium alapú UI tesztek (Browser Test) futtatása. Amennyiben minden lépés sikeres volt, akkor az utolsó, Store Artifact lépésnél a telepített modulok bekerülnek a Nexus repositoryba.

A pipeline verziószáma - esetünkben a v1.0.0.3 - végig kíséri az összes lépést, benne lesz a buildelt telepítési modulok nevében, a SonarQube analizálásnál, a performancia és böngésző tesztek során létrejött dynaTrace-es session-ök nevében és  persze a Nexus repositoryban eltárolt moduloknál is.

Ha valamelyik lépés hibára futna (pl. volt 1 hibás unit tesztünk), akkor az adott doboz piros színnel jelenik meg és a következő lépések már nem futnak le, hibásnak jelölve ezzel a teljes pipeline-t. A hiba fogalmát a SonarQube és a dynaTrace-es Jenkins build breaker funkcionalitással mi magunk határozhatjuk meg. Ha például volt legalább 1 blocker prioritású SonarQube hiba, vagy ha volt olyan JDBC lekérdezés a perf. teszt során ami 8 másodpercnél tovább futott, hibásnak jelölve az adott lépést, megállíthatjuk a pipeline lépéseinek további futását.

Szóval, jó dolgokat lehet ezekkel a pluginokkal csinálni, használjátok és ha van kérdésetek, ne tartsátok magatokban...

GIT Update Hook - Commit Message Restriction

A GIT Hook-ok lehetőséget adnak arra, hogy egy saját szkriptet futtassunk le, bizonyos GIT-es események bekövetkezésekor. A GIT művelet típusától függően választhatunk a kliens oldali ill. szerver oldali hook-ok közül.

Amit el szerettem volna elérni az az volt, hogy csak abban az esetben lehessen feltölteni a módosításokat a GIT szerverre, hogyha a kommit üzenetek megfelelnek egy általunk definiált formátumnak, esetünkben a "RED-123 kommit-üzenet" mintának, ahol is a RED-123 annak a redmine issue-nak az azonosítója amin a fejlesztő éppen dolgozik.

Itt megjegyezném, hogy az Eclipse-hez léteznek mylyn issue tracking connector-ok (JIRA, Mantis, Bugzilla, Trac) amelyek lehetővé teszik, hogy a fejlesztő magához vegyen egy taszkot és a kommittoláskor az issue azonosítójával automatikusan kitöltik a kommit üzenetet, így azt már nem kell kézzel beírogatni. Ezen konnektorok használata mindenféleképpen javasolt, amennyiben létezik ilyen plugin az általunk használt fejlesztő eszközhöz ill. ticketing rendszerhez.

A GIT (esetemben RhodeCode) szerveren, a repository hooks könyvtárában létrehoztam egy update futtatható fájlt az alábbi tartalommal, ami meghívódik minden egyes git push művelet esetén és csak a megfelelő kommit üzenet formátum esetén engedélyezi a kód feltöltését.

#!/bin/sh

refname="$1"
oldrev="$2"
newrev="$3"

for rev in `git rev-list $oldrev..$newrev`
do
    comment=`git log --format=%B -n 1 $rev`
    echo "Your commit message is: "$comment
    str=$(grep ^RED-[0-9]\\+[[:space:]][a-zA-Z0-9]* <<< $comment)
    if [ "$str" == "" ];then
       echo "[POLICY] Your message is not formatted 
             correctly! Use the 'RED-123 message' pattern, please"
       exit 1
    fi
done
echo "Thank you for your valid GIT commit message format!"
exit 0

Amennyiben javítani szeretnénk egy véletlenül elrontott kommit message-en, az Eclipse git staging view/ commit message/ Amend/ edit previous commit funkcióval tehetjük meg. 

dynaTrace Redmine Action Plugin

Már pár hónapja a KEKKH-ban tevékenykedek CI, dynaTrace illetve GWT-s tesztelés témákban, ahol is a feladataim között volt a dynaTrace és a Redmine issue kezelő integrálása. Az elkészített plugin lényege, hogy amikor egy dynaTrace-es riasztás történik (pl. egy webservice túl lassan válaszol) akkor a dynaTrace egy új issue-t vesz fel a Redmine-ba, kitöltve az issue-t a hiba körülményeihez tartozó releváns információkkal (system profile, prioritás, riasztás oka). Amennyiben a probléma folyamatosan jelen van természetesen nem szemeteli teli az issue kezelőt ugyanazzal a problémával.

Az elkészült plugin és a konfigurációs dokumentációja szabadon elérhető ezen a linken. A plugin tesztelve lett Redmine 2.x és 3.x-es verziókkal is. Eredményes monitorozást mindenkinek!