2012. január 18., szerda

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:

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!

Nincsenek megjegyzések:

Megjegyzés küldése

Megjegyzés: Megjegyzéseket csak a blog tagjai írhatnak a blogba.