Continous deployment, vagy afféle

Az ember a netet olvasgatva érdekes dolgokra tud bukkanni, illetve sokszor nagyon jó ötleteket lehet kapni pusztán a mások írásaiból.

Info@ írt arról, hogy náluk hogy került bevezetésre az, hogy a tesztelök gombnyomásra deployolnak a teszt rendszerre verziókat. Bár nálam max 1 tesztelö lenne, és öt sem szeretném a Jenkins közelébe engedni, azért elgondolkodtatott a dolog: mi volna, ha a Jenkins egyrészt monitorozná a deploy ágat (ez nálam a master ág, amint azt már említettem), ezen végrehajtana egy deployment tesztet is a staging környezetre (ezzel lenne egy folyamatosan friss teszt környezet), illetve adott esetben meg lehetne kérni öt arra, hogy, legyen már kedves az éles szerverre is kidobni az aktuál kódot.

Ez amennyire bonyolultan hangzik, annyira egyszerü volt megoldani. Egyrészt a staging és az éles szerverre fel kellett venni a Jenkins saját SSH kulcsát (már régebbröl volt ilyenem, mert a Jenkins slave-k kezeléséhez kell), másrészt kellett két olyan jobot csinálni, amelyek elvégzik a fent említett két müveletet.

Utána fogtam, lemásoltam azt a jobot, ami a normál (nem deployolós) teszteket csinálja, hozzácsaptam még egy lépést, miszerint deployoljon is a staging környezetbe. Illetve átírtam, hogy a master ágat figyelje. Annyit még egyszerüsítettem a dolgon, hogy egyik tesztnél sem csinálok coverage mérést, mert ez csak lassítja a tesztek futtatását, de érdemi eredményt nem ad hozzá a teszthez, hiszen itt a tesztek lefutása is csak azért fontos, hogy ha valaki véletlenül rácomittolt volna az éles ágra, mielött lefutna a deployment teszt, az még kibukjon. De általában senki nem szokott.

Az éles deploy job annyiban volt különbözö ettöl, hogy itt még kikapcsoltam a pollingozást is, mert ezt kézzel (na jó, XMPP-n keresztül) fogom triggerelni, és csak akkor, ha a staging környezetbe rendben kikerült a kód, illetve mindenki jóváhagyta a müködést is. Egyébként az elözö job másolata volt.

Így gyakorlatilag az van, hogy amikor release van, akkor szokás szerint mergelek egyet a master ágra, ezt felnyomom a git repóba, majd nekiállok türelmetlenül lesni az IM kliensem ablakát. Némi idö elteltével a Jenkins beszól, hogy (jó esetben) az aktuális job átment minden lépésen, és készen áll az élesítésre. Ekkor megkérem a jenkins-t, hogy deployoljon (jenkins, build project-deploy now), ez átfuttatja még egyszer a teszteket, majd kiteszi az éles szerverre a kódot, újraindítja a thin webszervert hozzá, és kész is. Mivel mind a teszteknek mind a deploymentnek része az adatbázis frissítése is (rake db:migrate), így nem fordulhat elö, hogy a db séma miatt halunk meg.

Azért itt még nincs vége a történetnek, a következö lépés az, hogy ellenörizni kell, hogy az app fel is bootolt-e tisztességesen. Sajnos a thin webszervernek megvan az a kellemetlen tulajdonsága, hogy csak azt várja meg, amíg ö maga meg a környezete felbootol, mielött forkol, magát a rails appot nem várja be. Vagyis lehet, hogy úgy kapsz HTTP 500-at, hogy amúgy a thin azt jelezte vissza, hogy sikeresen elindult (a deployment utolsó mozzanata az appszerver újraindítása). Egyelöre most a kézi meló is jó, a jövöben meg sztem lesz egy negatív teszt, egy fix oldalra fogok egy curl-t hívni, ha HTTP 200 jön vissza, már jók vagyunk.

Comments