A cégnél, akiknek dolgozom, több csapat is azt a módszert alkalmazza, hogy a Continuous Integration eszközéből (Hudson/Jenkins ill. TeamCity) deployál a tesztkörnyezetekbe. Minden tesztelőnek van egy saját környezete, és mindegyik környezethez tartozik egy nyomógomb a CI eszközben. Ha a tesztelő megnyomja a környezetéhez tartozó gombot, akkor a CI eszköz deployálja az SVN trunkben lévő utolsó revisionhöz tartozó verziót a környezetébe.
A héten fültanúja voltam egy beszélgetésnek, ahol a cég vezetői fejlesztői beszélgettek. Az egyik vezető fejlesztő, akinek a csapatában nem alkalmazzák a fenti módszert, arról próbálta meggyőzni a többieket, hogy felesleges időtöltés azzal foglalkozni, hogy a tesztelő gombnyomásra tudjon telepíteni magának saját verziót. A tesztelő Putty-tyal belép a linuxos szerverre, majd elindít parancssorból egy szkriptet, ami leállítja a Tomcatet, előveszi a legújabb wart, bemásolja azt a Tomcat könyvtárába, és elindítja a Tomcatet. Az alkalmazás indulása során a tesztelő figyelje a logot, ha esetleg valami oknál fogva nem indulna el az alkalmazás.
A vezető fejlesztő azzal érvelt, hogy úgyis nézni kell, hogy van-e hiba a deploy folyamat során, és szerinte elfecsérelt idő lehetőséget biztosítani arra, hogy egy webes felületen kényelmesen gombnyomásra lehessen deployálni úgy, hogy ha hiba történik, akkor azt a felületen is jelezzük. Egyszerűbb belépni Putty-tyal, és figyelni a logot.
Végülis ha megnézzük, tényleg nincs sokról szó: egy bejelentkezés, egy parancssori futtatás és a napló figyelése. Nem?
NEM.
Automatizálás
A Continuous Delivery elv lényege röviden az, hogy a releaseadás, deployálása folyamata megbízható és bármikor megismételhető legyen. Ennek érdekében minden lépést, amit automatizálni lehet, automatizáljunk. Az okok egyszerűek: kevesebbszer fogunk hibázni (mert alig végzünk manuális műveletet) és gyorsabban is végzünk. Természetesen az automatizálásnak is van költsége, de a hosszú távú, több éves életciklusú termékfejlesztéseknél nehezen lehet vitatkozni azzal, hogy ezen automatizmusok kidolgozása, bevezetése ne hozná be a ráfordított időt/költséget. Ráadásul senki nem mondta, hogy elsőre tökéleteset kell alkotnunk, az automatizálást apró lépésekben, a hibákból tanulva, a projekt növekedésével párhuzamosan meg lehet alapozni, és soha nem késő vele foglalkozni.
Az alkalmazás logja általában egy szemét, sokszor nehezen lehet benne észrevenni fontos információkat. Miért a tesztelőnek kell figyelnie azt a naplóból, hogy sikeres volt-e a deployálás? (Odaültetném azt a fejlesztőt a logokat bányászni, aki ezt gondolja.) Nem lehetne a tesztelőt ettől tehermentesíteni? Másrészt, ha a tesztelőnél derül ki, hogy valami miatt nem indul el az alkalmazás, akkor úgy érzem, egy kicsit már késő. Minél hamarabb ki kell derülnie, hogy az alkalmazás nem indítható.
Amikor commitálunk, miért nincs egy automatikus smoke test is a unit teszteken kívül? Az automatizált szkriptünk deployálná az alkalmazást, bejelentkezne a felhasználói felületen keresztül, és lefuttatna egy alapfunkciót. Semmi bonyolult dolog, csak egy egyszerű, gyors teszt. A unit tesztek gyorsan lefutnak, egy smoke teszt is hamar lefuthat. Így meglesz az az előnyünk, hogy commit után pár percen belül visszajelzést kapunk (max. 5p), hogy az alkalmazásunkban nagyjából minden rendben. Nem szívnak a fejlesztők, tesztelők azzal, hogy a kódbázis éppen egy használhatatlan hulladék, ami blokkolja a munkát, mert az alkalmazást el sem lehet indítani. Ez kb. hasonló szintű probléma, mint az, hogy a kódbázis le se fordul.
Ha azonnali visszajelzést kapunk, a gyors korrekcióval a többieknél sem akad fenn a munka. A probléma orvoslása pedig akkor a leghatékonyabb, amikor éppen a hibát elkövettük. Ha pár órával később kell javítani, már nehezebben fogjuk tudni, mi okozhatta a gondot, és az se biztos, hogy egyből tudjuk majd, hogy ki követte el a hibát.
Absztrakció a szállítási folyamatban
Fejlesztőként szeretünk a kódban absztrahálni, az ismétlődéseket felismerve általánosítani. Ez része a szakmánknak. A duplikációk megszüntetésével karbantarthatóbbá válik a kódunk, kevesebb a copy/paste (másképp: editor inheritance J), ezáltal magasabb absztrakciós szintet érünk el nem csak a kódban, de a megoldandó probléma megértésében is. Ez a fajta absztrahálás nem csak a kódírásban, de a szállítási folyamatban is fontos.
Azzal, hogy felismerjük, hogy a gombnyomásra deployálás egy jó dolog, az igazolása annak, hogy jó irányba tartunk. Bennünk a vágy, hogy mindent egyszerűsítsünk, beleértve a teljes szállítási folyamatot. Ha gombnyomásra deployálunk tesztkörnyezetbe, akkor akár élesbe is telepíthetnénk gombnyomásra, nem? Mi akadályoz meg minket abban, hogy a committól kezdve az élesbe telepítésig valami megakasszon minket, és ne deployálhassunk élesbe naponta akár több tucatszor is? Ezt elérni persze nem egyszerű, de nem lehetetlen. De ha nem is érjük el (mert azért ezt a körülményeknek is támogatnia kell), törekedhetünk rá. És ez előnyére válik a projektnek, és a cégnek is, akiknek dolgozunk. A megrendelőről pedig nem is beszéltem még, aki a megbízható, automatizált szállítási folyamat révén stabil szoftvert kap, hatékonyan.
Coolság
Valakik, a Hudsonra szirénát vagy egyéb spéci eszközt kötnek. Ha a build elszáll, a szirénna villog és vijjog.
Nem cool?
Pár évvel ezelőtt a korábbi munkahelyemen Scrumot alkalmaztunk. A főnököm megkérdezte egyszer: “Nem lenne jobb valamilyen elektronikus eszköz, amin a feladatokat nyilvántartjátok? Nem kellene a fal, amire cetliket gyártotok, és nem kellene a falon a cetliket tologatni!”
A fizikai tábla azonban kézzel fogható. Bárki bejöhet a szobába, megnézheti, min dolgozik a csapat. Fejlesztőként büszke vagyok arra, hogy elkészültem egy feladattal, és a tábla következő oszlopába helyezhetem. A reggeli standupon a tesztelő kélyes mosollyal helyezheti át a tesztelés alatt álló cetlit a hiba oszlopba, ami arra készteti a fejlesztőt, hogy tanuljon a hibából, és legközelebb lehetőleg ne kövesse el azt még egyszer. A tábla a csapatot és a munkáját képviseli. Bárki, bármikor láthatja. Nincsenek titkok. Ha végzünk egy feladattal, felállunk a helyünkről, oda megyünk, áttoljuk a cetlit. Ezek vagyunk mi.
Nem cool?
Azzal, hogy fejlesztőként segítünk, hogy a tesztelőnek csak egy gombot kelljen megnyomnia, hogy deployáljon, megkönnyítjük a munkáját. Nem jó érzés azt mondani neki?: “Itt ez a gomb, nyomd meg, és egy-két percen belül kikerül a környezetbe a legújabb verzió”. Voltam ebben a helyzetben, büszke voltam arra, hogy megcsináltam, és segíthettem valakinek a munkáját. Hónapokkal később is használták a tesztelők a gombnyomásra történő deployálást, ez a napi folyamat természetes részévé vált.
Nem cool?
Konklúzió
Még az az egyszerű kérdés is, hogy egy tesztkörnyezetbe gombnyomással telepítsünk-e, vagy belépjünk-e inkább a távoli linuxos szerverre, és ott parancssorból deployáljuk-e az alkalmazást, miközben figyeljük a logot, hogy nem történt-e hiba, messzire vezet.
Hatékonyság, megbízhatóság, átláthatóság, egyszerűség. Ezek elérése, ill. az ezekre való törekvés belső motivációt teremt bennünk és a körülöttünk lévőkben, amitől szívesebben végezzük a munkánkat. A szakmai tökéletesség a cél.
Úgy gondolom, ezen elvek felismerése és érvényesítése része kell, hogy legyen professzionális attitűdünknek.
Viczián István
Nov 10th, 2011Nagyon jó! Élvezetes a felvezetés.
Nekem is pont ma jött meg a könyv az Amazontól.
Látom, kiakasztottak.
Annyit akarok kérdezni, hogy biztos, hogy a head-et kell mindig kipakolni? Valahol azt olvastam, hogy a deploynak ne legyen része a build. A deploy egy külön projekt, ami az artifact-ot egy repository-ból szedi (persze oda a build rakta), és paraméterezhető, hogy melyik verziót akarja kitenni és melyik környezetbe. (Pl. ha egy szoftvert személyre szabva több helyre adtok el, ami mondjuk egyik helyen WebSphere-en megy, másikon Tomcat-en, és mindegyiknek van fejlesztői/teszt/éles stb. környezete.)
Persze a build még belökheti a deploy-t, az aktuálisan előállított artifact-tal, hogy egy smoke teszt lefusson egy dedikált környezeten.
Marhefka István
Nov 10th, 2011Viczi: igazad van, a deploy már a commit utáni első lépésben előállított bináris buildet kellene, hogy deployálja. A későbbiekben ez a bináris build (mondjuk, war) megy végig a munkafolyamaton. Sajnos, ez nem maradéktalanul valósult (még) meg.
A könyvön nagy nehezen átrágtam magam. Nagyon sok ismétlődés van benne és hosszú, de nagyon jók benne az elvek és a gondolatok. Sok eszközt is megemlít. Egyfajta referenciakönyvként használható. Szerintem alapmű lesz, de jó lenne belőle egy max. százoldalas változat, amit mindenki el bír olvasni.
Gabez
Nov 21st, 2011Pár megjegyzés (a vezető fejlesztőnek is :)):
1. a logokat lehet egyrészt rendbetenni (írtad, hogy általában katyvasz), másrészt deploy (install, telepítés) után elemezni valami szkripttel, hogy minden oké-e és ha nem, akkor az a build (verzió) mehet a kukába (nem szabad publikálni), a villogót meg bekapcsolni a lava lamp-on szép pirosra, hogy valamelyik managernek (jobb esetben az egész csapatnak) kiégesse a retináját és azonnal javítsa – máris meg van oldva az automatikus deploy hiba ellenőrzés, se fejlesztő, se tesztelő nem kell hozzá
2. a feladatok nyilvántartása elektronyos formában azért lenne jó sokak szerint, mert akkor könnyebb őket összegeznie a roppant elfoglalt vezetőségnek és még feljebb reportálni, hogy ennyit és ennyit haladtunk – más kérdés, hogy ezt egy élelmes manager úgy is megteheti, ha napi szinten (vagy kétnaponta) körbesétál az egyes csapatok tábláihoz és 10 perc alatt összeszedi ezeket az infókat, ráadásul még mozog is egy kicsit (go and see!)
3. sztem ha vki olyannal találkozunk, aki ragaszkodik a rossz megoldáshoz, le kell vele ülni és bevonni a megoldásba – azaz, átrántani a másik oldalra és érdekeltté, motiválttá tenni. Hogy ez kinek a dolga nálatok, azt persze nem tudhatom…:)
Marhefka István
Nov 22nd, 2011Gabez: egyetértek azokkal, amiket írtál. Egy kis megjegyzést még fűzök hozzá.
1. Abszolút igazad van, ez szerintem is a leghelyesebb attitűd, amivel hozzá lehet állni a problémához.
2. Ha már Scrumot csinálunk, akkor a menedzser (alaphelyzetben) ne kotnyeleskedjen bele napi szinten, hogy áll a csapat. A csapat a sprintre kötelezte el magát. Minden sprint végén látható, hogy mennyi teljesült és mennyi van még hátra a product backlogból. Látható, mennyi a csapat sebessége. Ehhez nem kell a falat elektronikus formában vezetni.
3. Itt is igazad van. De erről a részről most nem írhatok részletesen. Az a szennyes kiteregetése lenne, ami nem illik
Gabez
Nov 22nd, 20113-ból 2-ben egyetértünk, az egész jó kiindulási alap.
A 2. ponthoz: nem is írtam, hogy a manager (bár nem tisztáztuk, milyen manager, de én a project managerre gondoltam) turkáljon bele a napi munkába, csak azt, hogy ha akarja, simán tudja összesíteni és rögzíteni akár napi szinten is a haladást, elég csak körbenézni a Scrum (vagy akár Kanban – ez a téma is megérne 1-2 misét) táblákat. Ezzel nem zavarja a munkát, egyáltalán nem szól bele és elkerülhető, hogy a Scrum csapat mindenféle tool-okban vezesse, hogy mit csinált, mennyit dolgozott és éppen mennyi az agynyomása. Ugyanakkor gyorsabb a feedback a PM számára, mintha csak sprintenként látna valamit. A gyors feedback mindig jó. A még gyorsabb még jobb.
De az scrum témából az egyik legjobb, hogy mindig fejlődni kell és persze lehet is. Magát a scrumot is meg lehet reformálni, ha bizonyos problémákba ütközik az ember adott projectben.
Nemrég olvastam, hogy a Toyotánál látogatást tett 1-2 nyugati fejes, és csodálkoztak, hogy semmit nem látnak abból, amit a LEAN-ről és a SCRUM-ról leírtak a különböző könyvekben. A japók meg nem értették, mi a probléma, hiszen a kaizen elv szerint (continuous improvement) egyszer minden elavul és lekerül a napirendről…;)
Marhefka István
Nov 22nd, 2011Gabez:
Ne haragudj, de nekem a Scrumban nincs projekt menedzser szerepkör. Van ScrumMaster meg Product Owner meg van csapat. Azt meg, hogy helyi szinten ki hogy (nem) tudja összeegyeztetni a menedzsmenttel az agilitást, azzal inkább nem foglalkoznék
A ScrumMaster feladata, hogy segítsen a csapatoknak, ha problémát jeleznek vagy ő maga problémát lát.
Amúgy meg egyetértek, ott a tábla meg a burndown chart, különösebb egyéb adminisztráció nélkül láható, hogy hogy áll a csapat. Bármikor oda lehet menni megnézni, ahogy írtad is.
Jó ez a toyotás történet!
Gabez
Nov 22nd, 2011Túl van tárgyalva.
Visszatérve a Kanbanra, egy kérdés: van arról tapasztalatod, hogy valaki/valamilyen cég már ezt (is) alkalmazná? Mennyire terjed ez a módszer és vannak-e eredmények a teljesítmény javulásáról? Egyáltalán, mekkora lehet ennek a “háttere” Mo-on?
Azért nyomozom ezeket, mert mi kipróbáltuk (persze vegyesen a scrummal) és nagyon jól működött! 1-2 scrum elemet feleslegessé tett, pl burn down chart.
Marhefka István
Nov 22nd, 2011Gabez: a cég, akiknek most dolgozom, Kanbant használnak több csapatnál is, de elég sok elemet meghagytak a Scrumból, ezért inkább Scrumnak hívnám, mint Kanbannak.
Van pl. WIP-korlát, és emiatt pl. a fejlesztők rendszerint besegítenek a tesztelőknek, ha a tesztelőknél tornyosul a sok feladat. Ez jó.
Több oszlop is van a falon, mint a hagyományos Scrum-táblán.
De megmaradtak pl. az iterációk, és nem mérik az átfutási időt sem, ami szerintem óriási probléma. (Ehelyett a sprintek során teljesített sztoripontok szolgálnak a mérés alapjául.) Az átfutási idő mérésének hiánya miatt (szerintem) nem alakul ki a folyamatos tanulásra való kényszer, és ezért nem hívnám igazából kanbannak. Azt hiszem, ezt hívják Scrumban-nak (sic!).
Hallottam másokat is, akik használják (startupok). Általában tetszeni szokott nekik.
Olyat viszont nem láttam, hogy vki kapásból azzal kezdte volna, hogy az átfutási idő mennyit javult
(Pedig azt hiszem, ez az egyik kulcsa a dolognak :))
Gabez
Dec 1st, 2011Egy induló oldal a témában.
http://kanbanlean.blogspot.com/
hron84
Mar 18th, 2012En az elso felvetesre reagalnek: igen, a deploy buildeljen is – ha ez nem tul sok ido. Eggyel tobb vagy kevesebb compile parancs mar nem feltetlen szamit, ugyanakkor egeszen biztos lehet benne az ember, hogy unit tesztek altal lefedett hiba nincs a deployolt alkalmazasban.
Amivel viszon nagyon egyet tudok erteni, az az automatikus deployment teszt, vagyis hogy egy nagyobb teszt korenek legyen resze az, hogy appszerverre deployol. Amugy is kellenek staging teruletek, ahol lehet bohockodni az appal, egyet be lehet aldozni egy ilyen teszt kedveert.
Marhefka István
Mar 21st, 2012hron84: A continuous delivery könyv szerint a build pipeline első lépése maga a build, aminek az eredménye egy bináris. Ez a bináris megy végig a teljes pipeline-on. Így biztosított az, hogy valóban minden egyes fázisban ugyanazzal a lefordított programkóddal dolgozunk.
Elvileg előfordulhat az, hogy egy kiterjedtebb grid esetében, ami végzi a tesztek futtatását, a tesztkörnyezetekbe deployálást és/vagy futtatást, hogy “szétcsúszik valami” (pl. nem ugyanaz a fordító van jelen mindenhol). Vagy mondjuk a környezetek más dologban különböznek, és emiatt a build eredménye is más lesz.
Ez persze egy javas/C#-os platformon nem annyira jellemző, de mondjuk egy C/C++-os közegben már sokkal inkább számít. Oprendszer verziója, oprendszeren lévő update-ek verziója, 32/64 bites környezet, ezek mind befolyásolhatják a build eredményét.
hron84
Apr 14th, 2012Jo, hat en valami egyszerubb felallast kepzeltem el, Jenkins, commitra lefut egy job, ami epit, tesztel, majd deployol, ugy repoba mind szerverre.