HOUG 2017 - Jenkins 2 pipeline és maven release

Előadóként részt vettem a március 27-én megrendezett HOUG 2017-es Oracle konferencián, ahol is a Jenkins 2 pipeline és a maven alapú verziózás integrálásáról tartottam egy rövid prezentációt ill. egy élő bemutatót.

"Az előadás során a gyakorlatban is megsimerhetjük a Jenkins pipeline működését és egy megoldás is bemutatásra kerül amivel a maven relese-eléssel összhangba hozható a Jenkins build szám, végigvezetve a teljes pipeline folyamaton."

Az előadás prezentációja letölthető innen, és akit bővebben is érdekel a téma ezen az oldalon olvashat az általam kialakított megoldásról.

Jenkins 2 pipeline maven alapú verziózással

Felhasznált technológiák: Jenkins 2, Maven 3.3.9, Nexus 2.14, SonarQube 6.3

Az alábbi cikkben egy általam összerakott egyedi megoldást szeretnék bemutatni, ami lehetővé teszi a Jenkins build szám és a maven verziószámok egységes használatát. Remélem mindenki számára hasznos információkat tartalmaz majd ez a bejegyzés. :)

Az erőforrásaimat mostanság eléggé lekötik az ALM és DevOps szemlélet gyakorlatba való átültetésének lehetőségei, ezért a blogolásra kicsit kevesebb időm jutott, de ami késik nem múlik :) Az elmúlt időszakban több Continuous Integration projekt is sikeresen záródott, így kellő tapasztalat halmozódott fel az újabb irányok és igények implementálásához is. A mostani cikkemben arról fogok írni, hogy a Jenkins 2 pipeline-t miként integráltam össze a maven verzió kezelésével, de előtte egy kis visszatekintéssel kezdjünk. 

Jenkins 1 esetén amikor egy pipeline-t akartunk definiálni, akkor a Build Pipeline vagy a Delivery Pipeline pluginra támaszkodhattunk és a pipeline minden lépését egy-egy külön job-ban tudtuk meghatározni és triggerekkel összekötve építettük fel a láncot. Nem beszélve arról, hogy minden lépéshez egy külön job-ot kellett létrehozni, sok helyen könnyen elrontható volt a pipeline és időigényes is volt az összerakása. Egyszóval valóban megérett egy újragondolásra.

Ezekből a tapasztalatokból született meg a Jenkins 2, ami beépítve támogatja a groovy szkripttel létrehozható pipeline mechanizmust, azaz 1 job-on belül a teljes pipeline-t megírhatjuk, ami a gyakorlatban nagyon hatékony implementációt teszt lehetővé. A Blue Ocen UI plugin segítségével pedig egy modern felületet varázsolhatunk a pipeline köré. Létrehoztam egy pipeline-t ami a következő lépéseket tartalmazza: Build, Unit Test, Store Artifact, Code Coverage, Static Code Check, Deploy és Performance Test.

A maven verziózásnál 2 típust különböztetünk meg, a SNAPSHOT (fejlesztés alatti) és a RELEASE (kiadható) állapotokat. Ezért a pipeline indításakor is kiválaszthatjuk, hogy snapshot vagy release pipeline-t kívánunk indítani, továbbá release választása esetén opcionálisan megadhatjuk azt is, hogy mi legyen a következő snapshot verziószám, amennyiben el akarnánk térni az alapértelmezettől.

A build gombra kattinva elindul a pipleline, természetesen a folyamat indítható ütemezetten (pl. minden nap éjfélkor) vagy fejlesztő kommit hatására is, azáltal hogy a Jenkins poll-ozza az SCM-et.

A Build fázisban Maven segítségével buildelődik a forráskód és létrejönnek a telepíthető build termékek (ear, war, jar), majd a Unit Test fázisban lefutnak a JUnit alapú tesztek. Ezután elérkezünk a Store Artifact fázishoz, ahol is egy artifact repositoryban, esetünkben Nexus-ban eltárolódnak a build termékek

Amennyiben a pipeline indításakor a snapshot-ot választottuk ki, a build termékek a snapshot repositoryban fognak eltárolódni, a groupid, artifactid és a verziószámnak megfelelő könyvtár struktúrában. Ahogy az alábbi ábrán is látható a Jenkins build szám megegyezik a snapshot verzióval (0.0.13-SNAPSHOT) és snapshot sorszámával (3), ami esetünkben a 0.0.13-SNAPSHOT-3.

Ha a pipeline indításakor a release-t választjuk ki, a build termékek a release repositoryban fognak eltárolódni és taggelődik a forráskód bázis is, azaz ehhez az állapothoz a későbbiekben bármikor visszatérhetünk. Release készítésekor egyébként a release:prepre és release:perform fog lefutni. Látható, hogy release készítés után a következő snapshot verzió egy inkrementált vagy az általunk megadott sorszámot kapja majd.

A pipeline következő 2 fázisa a kód lefedettség mérés és a statikus kód ellenőrzés párhuzamosan fog futni. A statikus kód ellenőrzéshez a SonarQube eszközt szoktam javasolni, ahova az aktuális verziószám szintén delegálásra kerül, így a mérési eredmények beazonosítása egyértelmű.

A következő lépésben egy szkript automatikusan feltelepíti a tesztkörnyezetre az alkalmazást, majd performancia teszteket futtatunk úgy hogy a dynaTrace a háttérben méri az alkalmazás dinamikus jellemzőit mint például a válaszidőt és a performancia hot spotokat. A mérés lefutása után a dynatrace session és minden eredmény adat (unit teszt, kódlefedettség) a Jenkins eredmény oldalán megtekinthető és bármikor vissza kereshető.

Összefoglalva nézzük meg milyen előnyökkel kecsegtet az így kialakított pipeline:

• Jenkins 2 segítségével egy szabványos és hatékony pipeline megvalósítás
• Maven release-elés verziószáma megegyezik a Jenkins build számával
• Ha parancssorból (Jenkins nélkül) futtatjuk a maven release kiadását, akkor sem csúsznak el a verziószámok egy későbbi Jenkins pipeline indításakor
• A verziószám végig kíséri az összes lépést
• A Jenkins eredmény oldalán minden lépés eredmény fájlja és naplói elérhetők

A végére hagytam egy hasznos lehetőséget, méghozzá egy általam létrehozott Deployer jobot, aminek a segítségével a Nexus repository-ban, egy korábban eltárolt release vagy snapshot app verzió egy gombnyomással telepíthető az általunk kiválaszott környezetre. Ez a kis job nagyon hasznos az élesítések végrehajtásához is, ugyanis a megfelelő jogosultságokkal rendelkező adminisztrátorok gyorsan elvégezhetik ezt a feladatot.

A legközelebbi cikkben a környezetenként eltérő konfiguráció kezelésről és az adatbázis automatizált verziózásáról fogok írni, ami szintén szerves része a kialakított platfromnak.

IIR - Szoftvertesztelés 2016

Az idei évben is meghívást kaptam az IIR szoftvertesztelési konferenciájára, ami május 24-25-én kerül megrendezésre a Park Inn Radisson hotelben. A két évvel ezelőtti Agilis tesztkörnyezeti teljesítménymenedzsment témakör után most az Agilis monitorozásról fogok egy fél órás prezentációt tartani az alábbi témakörökkel:

• CI Delivery Pipeline a gyakorlatban
• Az automatizált monitorozás új aspektusai
• Statikus és dinamikus jellemzők mérése (SonarQube és Dynatrace)
• DEVOPS, ahogyan tényleg működik

A prezentáció ezen a linken letölthető. 

Selenium - RemoteWebDriver + Jenkins

Egy folyamatos integrációs környezetben általában nem azon a gépen futtatjuk a felületi teszteket ahol a Jenkins is dolgozik, ezért felhúzunk egy külön Windows-os gépet ahova feltelepítünk Internet Explorer-t, Firefox-ot meg egy Chrome-ot mivel azt szeretnénk, hogy a Jenkins indította klikkelő robot már itt kattintgasson majd az eredményeket juttassa vissza a Jenkins számára.

Ez a működés a Selenium RemoteWebDriver segítségével egyszerűen megoldható. Először is rögzítsük a felületi tesztesetet a Selenium IDE Firefox plugin segítségével, majd exportáljuk Java forrásként és módosítsuk az alábbi mintakód alapján, ahol is a baseURL az alkalmazás kezdő URL-e, a távoli Windows-os gép a remoteSeleniumServer URL-en figyel, a browser pedig az a böngésző típus amivel a tesztet futtatni fogjuk. Látható, hogy ebben a minta kódban be vannak égetve az alapértelmezett értékek, de a Jenkins-ből ezeket majd felülírhatjuk.

import static org.junit.Assert.fail;
import java.net.MalformedURLException;
import java.net.URL;
import org.apache.commons.lang3.StringUtils;
import org.junit.After;
import org.junit.Before;
import org.junit.Test;
import org.openqa.selenium.remote.DesiredCapabilities;
import org.openqa.selenium.remote.RemoteWebDriver;
import com.thoughtworks.selenium.webdriven.WebDriverBackedSelenium;


public class NLRTest {
 private String baseURL = "https://webapphost:8113/";
 private String remoteSeleniumServer = "http://rsh:4444/wd/hub";
 private String browser="chrome";//firefox,internet explorer,chrome
 
 private WebDriverBackedSelenium selenium;
 private RemoteWebDriver remoteWD = null;

 @Before
 public void setUp() throws Exception {
  
  
  if(!StringUtils.isBlank(System.getProperty("baseURL")))
   baseURL=System.getProperty("baseURL");
  
  if(!StringUtils.isBlank(System.getProperty("remoteSeleniumServer")))
         remoteSeleniumServer=System.getProperty("remoteSeleniumServer");
  if(!StringUtils.isBlank(System.getProperty("browser")))
         browser=System.getProperty("browser");
   

  DesiredCapabilities capabilities = new DesiredCapabilities();
  capabilities.setJavascriptEnabled(true);
  capabilities.setBrowserName(browser);
  try {
   remoteWD = new RemoteWebDriver(new URL(remoteSeleniumServer),capabilities);
   

  } catch (MalformedURLException e) {
   e.printStackTrace();
  }

  selenium = new WebDriverBackedSelenium(remoteWD, baseURL);

 }

 @SuppressWarnings("deprecation")
 @Test
 public void testNLR1() throws Exception {

  selenium.open("/NLR/login");
  
  //IE certification ok button
  if(browser.equals("internet explorer"))
   remoteWD.navigate().to("javascript:document.getElementById('overridelink').click()");
  
  
  selenium.type("id=fnev", "myuser");
  selenium.type("id=password", "mypass");
  for (int second = 0;; second++) {
   if (second >= 60)
    fail("timeout");
   try {
    if ("felhasználónév:".equals(selenium
      .getText("css=td.left_label")))
     break;
   } catch (Exception e) {
   }
   Thread.sleep(1000);
  }

  selenium.click("css=button[type=\"button\"]");
  selenium.waitForPageToLoad("30000");
  for (int second = 0;; second++) {
   if (second >= 60)
    fail("timeout");
   try {
    if ("Munkamenet".equals(selenium.getText("link=Munkamenet")))
     break;
   } catch (Exception e) {
   }
   Thread.sleep(1000);
  }

  selenium.click("link=Munkamenet");
  ...
  selenium.click("link=Előzmények keresése");
  selenium.waitForPageToLoad("30000");
  selenium.click("link=Kilépés");
  selenium.waitForPageToLoad("30000");

 }

 @After
 public void tearDown() throws Exception {
  selenium.stop();
 }

}

A klikkelő robotnak létrehozott távoli Windows-os hosztra, ahol feltelepítettük az IE, Firefox és Chrome böngészőket, másoljuk fel a selenium-server-standalone.jar, a chromedriver.exe és IEDriverServer.exe fájlokat. A firefox driver-t nem kell külön letölteni, mert azt a selenium-server-standalone.jar már tartalmazza. Ezután ezen a dedikált Windows-os gépen indítsuk el a Selenium-ot az alábbi paranccsal, felparaméterezve a driverek elérési útvonalával. Innentől kezdve a Jenkins már képes elindítani a klikkelő robotot ezen a gépen.

java -Dwebdriver.chrome.driver="c:\\chromedriver.exe" -Dwebdriver.ie.driver = "c:\IEDriverServer.exe" -jar c:\selenium-server-standalone-2.47.1.jar 

Itt olvasható, hogy a Selenium-ot hogyan illeszthetjük be a maven-es projektünkbe, a Jenkins felületén pedig a Goals and options résznél állíthatjuk be a megfelelő paramétereket:

test -Dbuild.number=${PIPELINE_VERSION} -Dtest=hu.bakai.selenium.* -DbaseURL = "https://172.22.22.22:8113" -DrempoteSeleniumServer = "http://10.128.11.11:4444/wd/hub"  -Dbrowser = "internet explorer"

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

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

dynaTrace - Nemcsak tűzoltásra!

A dynaTrace egy hasznos eszköz az éles környezetben felmerült teljesítménybeli és stabilitási problémák beazonosításához, de lássuk be ez nem más mint tűzoltás! Én azt javaslom, hogy ne csak akkor kezdjünk el foglalkozni a problémákkal ha már ég a ház, mert ilyenkor biztos sokkal nagyobb lesz a kárunk és a javítási költség is!


A problémákat jóval korábban, már a fejlesztés-tesztelés fázisban ki kellene mutatni, így azok gyorsan orvosolhatók! Felmerülhet a kérdés, hogy miért használjunk dynaTrace-t amikor ott vannak a már jól bevált teszteszközök? A dynaTrace-t nem a teszteszközök helyett, hanem azokkal integrálva érdemes használni! Az alapvető probléma a teszt eszközökkel, hogy azok csupán rámutatnak a sokáig tartó kérésekre ill. hibákra, de nem tudják felfedni a problémák valódi okát, mivel nem látnak bele az alkalmazásba!

A dynaTrace integrálható a legtöbb kereskedelmi és nyílt teszteszközzel, legyen az terheléses (JMeter, LoadRunner), felületi (Selenium) vagy éppen egység teszt (JUnit, TestNG). A leghatékonyabb eredményt akkor érhetjük el, amikor ezt a folyamatos integrációs környezetünkbe is beillesztjük.

A gyakorlatban ez úgy néz ki, hogy egy CI eszköz (gombnyomásra vagy ütemezve) meghajtja az alábbi lépéseket:

1. Forráskód letöltése az SCM-ből
2. A build eszköz lefordítja a kódot, létrejönnek a build termékek
3. Lefuttat egy SonarQube kód analizálást
4. Átszól egy REST-es interface-n a dynaTrace-nek, hogy kezdheti a session mentést
5. Lefuttatja a dynaTrace-szel integrált unit teszteket
6. Telepíti a web-alkalmazást a tesztkörnyezetbe
7. Lefuttatja a dynaTrace-szel integrált felületi és terheléses teszteket
8. Átszól egy REST-es interface-en a dynaTrace-nek, hogy zárja le a session mentést

Nézzük is meg, hogy mit nyertünk vele:

• Minden egyes release-hez automatikusan létrejön egy dynaTrace session, ami tartalmazza a PurePath-okat és minden mérési eredményt a dinamikus jellemzőkről (lekérdezések ideje, kivételek száma, válaszidők, stb...)
• Minden egyes release-hez megkapjuk a kód statikus jellemzőit (System.out.println()-ek száma, stb...)
• Mivel a trendekből kiolvashatjuk a dinamikus (dynaTrace) és statikus (SonarQube) jellemzőket, a negatív elváltozásokat azonnal felismerhetjük
• Tetszőleges 2 release jellemzőit is összehasonlíthatjuk

Persze a dynaTrace a fejlesztőknek is tartogat hasznos funkciókat. Az Eclipse ill. az MS Visual stúdióval történő integrációt követően, a dynaTrace-ben megjelenő metódusokra kattintva átugorhatunk a fejlesztőkörnyezetünkben lévő projekt megfelelő metódusára!

Legközelebb pedig egy teljesen új témával jelentkezem, ez pedig az An...

Jenkins - Folyamatos integráció kialakítása

A folyamatos integráció egy olyan fejlesztési folyamat, ami hatékonyabbá teszi a csapatmunkában történő fejlesztést azáltal, hogy a fejlesztők gyakran (legalább naponta) és már a kezdetektől összeillesztik (integrálják) a kódjukat. A Continuous Integration arra a felismerésre épít, hogy a fejlesztés során a kódok integrációja a legproblematikusabb fázis és hogyha ezt korán lekezeljük akkor az esetleges problémák is gyorsabban javíthatóak lesznek!

A gyakorlatban ez úgy néz ki, hogy a fejlesztők bekommittolják a forráskód módosításaikat a verziókezelőbe, amiről a CI szerver értesül így frissíti a helyi kódbázisát majd lebuildeli a kódot és lefuttatja a teszteket, végül a build terméket kiteszi egy teszt szerverre ahol is a tesztelők egyből elkezdhetik a legfrissebb verzió tesztelését! Hibás build esetén a fejlesztők automatikusan visszacsatolást kapnak (email, sms, rss), így lehetővé válik a gyors beavatkozás a probléma elhárítása érdekében. Az értesítések mellett a CI szerverek lehetőséget adnak a buildek és a tesztek sikerességének időbeli követésére is egy dashboard-on keresztül.

Az előbb ismertetett folyamat akár manuálisan is elvégezhető lenne, azonban a CI szerverek segítségével ez kiválóan automatizálható és valóban egy gombnyomással minden elintézhető!

A piacon többféle kereskedelmi és open source CI szerver is megtalálható, a legelterjedtebb azonban mégis a Hudson ill. Jenkins a rengeteg rendelkezésre álló plugin-nak köszönhetően! Amikor az Oracle felvásárolta a SUN-t, a Hudson core fejlesztői létrehozták a Jenkins projectet, így a hasonlóság miatt a két CI szerver üzemeltetése és a konfigurálása szinte teljesen megegyezik.

Nemrég az én feladatom volt a céges folyamatos integráció bevezetése, így a következőkben megosztok egy-két hasznos tanácsot ezzel kapcsolatosan:

• Hudson helyett használjunk inkább Jenkins-t, mivel az eredeti Hudson csapat fejleszti, dinamikusabban fejlődik és néhány plugin csak a Jenkins alatt érhető el!
• Definiáljuk a JENKINS_HOME ill. JENKINS_BASE környezeti változókat!
• A Jenkins jobok futtatását igény szerint állítsuk be kommitonként vagy napi egyszeri futtatáshoz (éjszakai build).
• Archiváljuk a sikeres build termékeket (EAR, WAR) majd tegyük letölthetővé egy-egy link formájában.
• Automatizáljuk a tesztek futtatását. (unit teszt, felületi teszt, integrációs teszt, performancia teszt)
• Automatizáljuk a kód lefedettségi riportok futtatását.
• Használjunk statikus kód ellenőrzőket a kódolási hibák kijelzésére és a cégen belüli kódolási konvenciók betartásához. (findbugs, pmd, checkstyle)
• Sikertelen build esetére állítsunk be automatikus e-mail értesítőt, így a fejlesztők azonnal értesülnek a hibákról.
• A webalkalmazás teszt szerverre történő telepítése után, hajtsunk végre egy egyszerű Smoke tesztet a telepítés sikerességének ellenőrzéséhez.
• Aktiváljuk és használjuk a Jenkins security lehetőségeit.

Amennyiben a napi egyszeri build mellett döntünk, a web-alkalmazás telepítését követően érdemes automatizáltan lefuttatni egy 2-3 órás JMeter tesztet hétköznapi terhelést szimulálva, majd a teszt végén kigyűjteni a heap dump és verbose gc napló állományokat, melyeket a build termékek mellé is kirakhatunk, így szükség esetén gyorsan elővehetjük és analizálhatjuk. Sőt, a verbose gc információkból akár egyből egy diagramot is legenerálhatunk amit szintén betehetünk a build termékek közé!

Végül következzen egy-két hasznos Jenkins és Hudson plugin, amelyeket érdemes feltelepíteni:

• Selenium plugin: Selenium alapú automatizált felületi tesztek futtatásához.
• Performance plugin: JMeter alapú teljesítménytesztek eredményeinek megjelenítéséhez. 
• Email extension plugin: Az értesítő e-mail tartalmának részletes bekonfigurálásához.
• Site Monitor plugin: A site elérhetőségének ellenőrzéséhez. (HTTP 200)
• ViewVC plugin: A ViewVC forráskód böngésző integrációjához.
• FindBugs plugin: FindBugs riport megjelenítéséhez.
• PMD plugin: PMD riport megjelenítéséhez.
• CheckStyle plugin: CheckStyle riport megjelenítéséhez.
• Static Code Analysis plugin: Statikus kód analizálók eredményeinek közös diagramon való megjelenítéséhez.

A Jenkins további megismeréséhez és részletesebb konfigurációjához a Jenkins: The Definitive Guide ingyenesen letölthető e-könyvet ajánlom!