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 felhasználó, épp az éves díjat szeretné, ha levonnánk a kártyájáról. Aztán meg sehol semmi. Pedig ő szeretné.
No de, 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.
Continuous Delivery is a series of practical steps designed to allow the code to get into the production environment quickly and safely through a production-like (stage) environment where one can make sure that all the apps and services are functional. We automatically run all sorts of tests that have merciless red lights when something is not functioning as expected.
Now then, if everything has gone to the stage environment previously, then it is quite probable that they can go live and there won’t be any issues.
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.
