Vállalható Vállalkozás Teszt >>

Osztroluczki Gábor

a Bridge Budapest ösztöndíjasa, Prezi, San Francisco, 2016

A szállító

Milyen opciók is vannak? Team City, Bamboo, Jenkins


Jenkins elég népszerű. Bárki letöltheti, használhatja. Csak úgy. MIT license alatt.


Nos, sok koncepció lézetik, hogy hogyan is építsünk CI környezetet.


Az első: minden részlegnek van saját Jenkins-e.


Adódik a kérdés, hogy ezt akkor ki felügyelje? Minden csapat dedikáljon embereket? Minden csapatban legyenek, akik értenek hozzá, és nem kellenek a dedikált Jenkins szakik? Amikor valami nem megy, annak hatása egy területre korlátozódik.


A második: egy nagy Jenkins van a cégnél, és az dolgozik minden csapat keze alá.


Amikor a cégnek van egy terméke, és azt szolgálja ki több szolgáltatás (microservice). Végső soron egy cél érdekében létezik az összes, összefüggnek. Ha az egyik build folyamatban hiba lép fel, akkor a hibás build ne kerüljön ki. Integrációs teszteknél jól jön, ha minden egyben van. Egy helyen a buildelendő projektek, az integrációs tesztek és az összes Jenkins-t érintő konfiguráció.


Persze ha elég sok binárist kell legyúrnia a CI rendszernek, itt már ki kell alakítani egy master-slave struktúrát. A master kiosztja a feladatokat, míg az egyes slave gépek végrehajtják azokat. Vagy jöhet a jó öreg malmozás.


Viszont, amikor egy ilyen CI rendszer nem reszponzív és az admin belépve a szerverre azt látja, hogy 100%-on pörög a CPU, na akkor kell okosnak lenni. Talán éppen valaki egy programot futtat, ami egy tömörített állományba gyúrja a teljes meghajtót (könyvtárszerkezetet). Ez a valaki talán szétnézett a szerveren és látta, hogy érdekes forráskódokkal van tele. Bespájzol, letölti aztán nyugodtabb körülmények között elemzi a fájlokat.


Bárkivel megeshet. Ezért érdemes monitorozni a CI-t is, ha netán unresponsive-vá válna. Főleg egy olyat, amin minden ott van.


Gyors iterációk


Agilis módszerekkel fejleszteni nagyjából kötelező lett manapság.



  • A módosításokat mihamarabb eljuttatni a felhasználóknak.

  • Biztosítani a fejlesztőknek, hogy fejlesztéssel foglalkozhassanak

  • A deploy és release automatizálásával gyorsítani a folyamatot


Itt már vannak lean jegyek is. Lényeg, hogy amit lehet és érdemes, automatizálni kell! Mindent, amivel felszabadítható emberi erőforrás, mivel a legnagyobb költség az élő munkaerő. Ráadásul az embernek lehet egy-egy napja, amikor átsiklik egy hiba felett, legyen másnapos, aznapos vagy csak szimplán fáradt.


Ezért jó, ha van egy CI a ház körül. Lefuttatja a unit teszteket, az integrációs teszteket meg a funkcionális teszteket. Már ha vannak, de miért is ne lennének?! Egy valamire való startup nem engedheti meg magának hogy ne legyenek tesztek. Egy necces helyzet és a felhasználók már mennek is. Mi lenne, ha a fizetéssel lenne valami? Ott a felhaszáló, épp az éves díjat szeretné, ha levonánk a kártyájáról. Aztán meg sehol semmi. Pedig ő szeretné.


Node, a tesztekkel az ilyen megelőzhető. Seleniummal egészen jól lehet UI-t automatikusan tesztelni.


Van ugye a Continuous Delivery és a Continuous Deployment. 


A Continuous Delivery egy sor gyakorlati lépés arra tervezve, hogy a kód gyorsan és biztonságosan kijusson a production környezetbe egy production-szerű (stage) környezeten keresztül ahol meggyőződhetünk,hogy minden app és szolgáltatás működik. Automatikusan lefuttatunk mindenféle tesztet, amik könyörtelenül pirosan világítanak, amikor valami nem az elvártaknak megfelelően funkcionál.


Namármost, ha minden automatikusan kiment a stage környezetbe korábban, akkor már igen valószínű, hogy elindulhat élesben is és ott sem lesz gond.


Continuous Deployment egy fokkal több mint a Delivery. Annyiban különbözik, hogy ami átmegy a teszteken, az automatikusan élesedik anélkül, hogy egy személy jóváhagyásást meg kéne várnia.


Azok a csapatok amik egy-egy rendszer alapjait teszik le, általában pár főből állnak. Így törekedniük kell az erőforrásaik minél jobb kihasznlására. Legtöbbször agresszív automatizlásban létrehoznak egy CI build rendszert, majd rengeteg automatikus teszttel látják el projektet. Ezeket a teszteket azután a CI elvégzi és amikor minden rendben, akkor a felhasználók megkaphatják a következő iterációjukat. Szebb, újabb, jobb, okosabb verziót.