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...