Mintha nálam tipushiba lenne a gubancos backend, amit integrálni kell a rendszerhez. Az egyik SOAP-os backend pl NPE-t vág az arcomba kiszámíthatóan minden alkalommal, amikor egy bizonyos metódust meghívok rajta teljesen tökmindegy milyen paraméterekkel. Állítja a szakember, hogy rosszul van telepítve és én hiszek is neki, csak akkor kérném hogy telepítsék fel jól, mert én akármit csinálok, mindig NPE lesz belőle.
A másik backend egy sima XML+http és a szerver oldalon mysql+php, de valami trükköt mégis csinálhattak rajta, a continuous integration szerver ugyanis egymás után kétszer is hibát jelzett a tesztben. Egyből éreztem kis motivációt utánnanézni és ez derült ki: két rekordot küldök át neki, a másodikban benne van az első ID-je, amit nyilván csak akkor kapok meg, ha az első sikeres volt. Általában működik is, de néha nem, néha azt van képe állítani, hogy az előző rekord nem létezik. Tipikus cluster hibának tünt elsőre, hátha aszinkron replikáció van adatbázisok közt, hogy az is "elég jó" és akkor kicsit várni kell, hogy szétreplikálódjon az első rekord, mielött becsapódik a második. Savanyú arccal a kettő közé tettem egy obj.wait(fubar)-t és lefuttattam újra a tesztet és ocsmány pofáraesés... megint elhalt. Úgyhogy kijött szépen az obj.wait és a helyére bement egy catch és retry. Most gondolj egy szóra... nekem is csúnya szó jutott eszembe.
Régebben meg volt a paypal történet, amit ha nem velem történik, nem hinném el senkinek és volt egy egész csinos rakás kis buhera a többi gubancos backendek kezelésére, azt gebaszos backendek egész hada idézte elő, az akkori projectem 9 backenddel tartott kapcsolatot. Mára azok szerencsére elmúltak de a helyükre újak jöttek.
A gubancos backendek megfigyelésére a múlt héten összeütöttem egy kis webappot és ez életem egyik leggyorsabban megtérülő befektetése lett :-) másnap reggel máris hibát jelzett és még a helyszinen elkaptam a merénylőt, aki buherálta az adott backendet.
Szóval a backendek az eddigi tapasztalatok szerint kulcsfontosságúak a szoftverhibák megvalósíŧásában. Ha csak egy mód van rá, használj inkáb beágyazható megoldást, legyen pár failover opciód, hogy ne menjen dőljön be az egész project, ha egy szolgáltató kifekszik.
A felhasználóidat ugyanis nem fogja érdekelni, hogy hol és miért volt gubanc, nekik áldozat kell majd és te vagy a legközelebb.
A következő címkéjű bejegyzések mutatása: CI. Összes bejegyzés megjelenítése
A következő címkéjű bejegyzések mutatása: CI. Összes bejegyzés megjelenítése
2011. január 10., hétfő
2010. november 17., szerda
Sonar eclipse plugin (FYI)
András hívta fel a figyelmem erre a pluginra, igazi frankó cucc :-) Amúgy nem szeretem pluginekkel telezsúfolni az eclipse-t, stabilabb biztosan nem lesz tőle, de ez egy értelmes ötlet: ahol hegesztek, ott nézhetem a hegesztés minőségét is és javíthatok rajta.
Király lenne az open source projectjeimhez egy sonar valahol, otthon is jó lenne bevetni. Az anzix.net-en ment egy, de eltünt.
Valamint még azt akartam kérni, hogy aki ott van a JUM-on, az légyszi írjon már beszámolót, lehetőleg minnél többen. Én még mindig melóban. Köszi...
Király lenne az open source projectjeimhez egy sonar valahol, otthon is jó lenne bevetni. Az anzix.net-en ment egy, de eltünt.
Valamint még azt akartam kérni, hogy aki ott van a JUM-on, az légyszi írjon már beszámolót, lehetőleg minnél többen. Én még mindig melóban. Köszi...
2010. június 4., péntek
JUM XV log
Tegnap esti Java felhasználók találkozója. A democamphez hasonlóan viszonylag kevesen voltunk, erre az eseményre viszont sajnálhatja aki nem jött el, nekem nagyon tetszett a két előadás. Mindkét előadást szakmai bloggerek tartották, nekem is itt vannak a google reader végén.
Kovács Richárd: btrace
A btrace egy trace eszköz, olyan mint a dtrace solarison (ez a legtöbb embernek azért nem mond sokat, nem egy mainstream oprendszer még a szervereken sem). Egyszerű kis scripteket lehet rá írni annotációkkal és nagyon kevés kóddal, ami a hotspot vm-hez kapcsolódik és bizonyos esetekben meghívódik. Például csinálhasz egy scriptet, ami a DriverManager.getConnection() metódusra ráakaszkodik. Tipikusan olyan komponensek tuningolásánál jól jöhet, amik nem logolnak és nem mi írtuk. Őszintén szólva tegnap került csak a látőterembe a cucc és most már nem tudom hogy élhettem eddig nélküle :)
Marhefka István: Domain Driven Development
István egy hosszabb előadást tartott a Domain Driven Developmentről, ami egy nagyon elméleti téma de nagyon sok gyakorlati tapasztalat is volt benne. A DTO pattern körül a végén sok kérdés volt, azt hiszem az említett fintorgók tábora nagy számban volt jelen. Én csak akkor szoktam bevetni, ha már nincs más választásom.
Egyébként nem is tudtam hogy van még a munkaadómon kívül teamcity felhasználó itthon. Elég borsos ára van :-)
Ez volt most az időny utolsó jum-ja, szeptemberig szünetelünk és akkor újjult lendülettel :)
2009. május 13., szerda
python kitérő
Rövidebb időre átkényszerültem python használatára 3d alkalmazást kalapálni. Nem első ütközés a pythonnal (például itt egy scriptem ami Oracle[TM] MySQL dumpformátumát tömi be PostgreSQL-be... Hmm, lehet ez még hasznos lesz egyszer....), de munkában talán most használtam elösször úgy, hogy nem csak valami gyors egyszeri hegesztés, hanem élesben kell mennie és futnia, ügyfelek nézik majd az eredményeit.
És hát rendesen megszívatott a httplib-bel. Az az alapfelállás, hogy ez a progi egy queue-t polloz melóért, renderel valamit a saját kis 3D enginén és az eredményt szépen visszateszi az queue-ba. Mivel persze az eredmény egy szép nagy kép, gondoltam file uploaddal elpostolom. A probléma már itt elkezdődött, ugyanis a httplib ilyet nem tud. Az urllib sem tud, a későbbi python verziókban megtalálható ezeknek a libraryknak a 2-es verziója (httplib2, nagyon elegáns), de azok sem tudnak ilyesmit.
Valahol megtaláltam, hogy mikorra igérték ennek a javítását, de ezzel inkáb nem keltenék pánikot, nekem amúgy sem volt adott lehetőség, hogy felűbereljek kevésbé régi python verzióra.
Mindenesetre itt van egy nagyon egyszerű és működő megoldás file uploadra. Kis módosítás után már működött is, és boldog voltam hogy ezt is elfelejthetem. Érdemes még ezen a lapon megnézni hányan jöttek alternatív megoldásokkal.
Egészen addig tartott a boldogság, amíg a CI rendszer fel nem kapta a változtatásokat és ki nem próbálta. Az úgy 2-3 perc. Ami a localhoston működött, az valamiért mocsokul nem akart menni a tesztkörnyezeten, legmeglepőbb módon 404-et dobott az MQ, amikor vissza próbálta küldeni a eredményt. Eltartott egy ideig, amíg végigkotorásztam a tesztrendszer konfigurációit, nézegettem a logfilejait, míg végül már wireshark-ot rántottam, és ott is jó ideig néznem kellett míg végre észrevettem: http 1.0-át használt a file uploadhoz. A http 1.0 egy matuzsálem, nem voltak virtuális hostok benne, így az apache-nek végig fogalma sem volt hogy kinek postol a kliens progi.
Innentől még egy szép nagy kalapálás volt, mire sikerült végre rávennem, hogy http 1.1-et használjon a file uploadhoz is.
Úgyhogy a fenti linken látható alternatív megoldásokhoz hozzátenném a saját mégalternatívabb megoldásomat. Még szerencse, hogy mindent tesztelünk, a publikus tesztoldalakon már sokkal nehezebb lett volna kideríteni az igazságot.
Kiváncsi vagyok a profi python programozók ezt hogyan használják. Például a google a legnagyobb python felhasználó. Vajon nekik ez nem fájt?
És hát rendesen megszívatott a httplib-bel. Az az alapfelállás, hogy ez a progi egy queue-t polloz melóért, renderel valamit a saját kis 3D enginén és az eredményt szépen visszateszi az queue-ba. Mivel persze az eredmény egy szép nagy kép, gondoltam file uploaddal elpostolom. A probléma már itt elkezdődött, ugyanis a httplib ilyet nem tud. Az urllib sem tud, a későbbi python verziókban megtalálható ezeknek a libraryknak a 2-es verziója (httplib2, nagyon elegáns), de azok sem tudnak ilyesmit.
Valahol megtaláltam, hogy mikorra igérték ennek a javítását, de ezzel inkáb nem keltenék pánikot, nekem amúgy sem volt adott lehetőség, hogy felűbereljek kevésbé régi python verzióra.
Mindenesetre itt van egy nagyon egyszerű és működő megoldás file uploadra. Kis módosítás után már működött is, és boldog voltam hogy ezt is elfelejthetem. Érdemes még ezen a lapon megnézni hányan jöttek alternatív megoldásokkal.
Egészen addig tartott a boldogság, amíg a CI rendszer fel nem kapta a változtatásokat és ki nem próbálta. Az úgy 2-3 perc. Ami a localhoston működött, az valamiért mocsokul nem akart menni a tesztkörnyezeten, legmeglepőbb módon 404-et dobott az MQ, amikor vissza próbálta küldeni a eredményt. Eltartott egy ideig, amíg végigkotorásztam a tesztrendszer konfigurációit, nézegettem a logfilejait, míg végül már wireshark-ot rántottam, és ott is jó ideig néznem kellett míg végre észrevettem: http 1.0-át használt a file uploadhoz. A http 1.0 egy matuzsálem, nem voltak virtuális hostok benne, így az apache-nek végig fogalma sem volt hogy kinek postol a kliens progi.
Innentől még egy szép nagy kalapálás volt, mire sikerült végre rávennem, hogy http 1.1-et használjon a file uploadhoz is.
Úgyhogy a fenti linken látható alternatív megoldásokhoz hozzátenném a saját mégalternatívabb megoldásomat. Még szerencse, hogy mindent tesztelünk, a publikus tesztoldalakon már sokkal nehezebb lett volna kideríteni az igazságot.
Kiváncsi vagyok a profi python programozók ezt hogyan használják. Például a google a legnagyobb python felhasználó. Vajon nekik ez nem fájt?
2008. december 9., kedd
Continuum
Rövid műsorajánlóval jelentkezünk korán reggel...
Szóval ajánlanám figyelmetekbe, hogy a continuum-hoz végre valahára megcsinálják a több agent-es build lehetőségét. Gondolom még sokat kell várni, amíg célba ér. Közben kijött a TeamCity 4.0, csili-vili dolgokkal, szóval munkában valószinűleg marad az...
Szóval ajánlanám figyelmetekbe, hogy a continuum-hoz végre valahára megcsinálják a több agent-es build lehetőségét. Gondolom még sokat kell várni, amíg célba ér. Közben kijött a TeamCity 4.0, csili-vili dolgokkal, szóval munkában valószinűleg marad az...
2008. november 18., kedd
Auto mate
Egy rossz élményemet leírnám ide a Continuous Integration témában, hogy erre esetleg vigyázzatok és próbáljátok meg elkerülni.
Abban az esetben, ha nálatok is minden csapat kitalálhatja magának hogy milyen build környezetet használ és esetleg bizonyos speciális dolgokat is beleépítetek (windowsos path-ok a build.xml-ben, exe fileok és más platform függő binárisok valahol a projectben, különleges classpath beállítások, környezeti változók, és a többi mocsokság), akkor a CI szervereteknél hamar felmerül az igény arra, hogy mindenkinek külön beállított build agentje legyen, amin az ő buildjei futnak. Egy kicsivel később már el is tulajdonolja egy-egy csapat ezeket a build agenteket és nem közös erőforrásként tekint rájuk, hanem inkább magántulajdon. Innentől kezdve egyes agentek majdnem teljesen kihasználatlanok lesznek, míg mások egész nap pörögnek, egyes csapatok csak másnap reggel kapják meg az eredményeket, mások azonnal.
Ez szerintem elég rossz irány és nagyon nehéz visszacsinálni ha egyszer megtörtént. Valamennyire le kell rendezni mindenkivel, hogy a buildje nem tartalmazhat speciális külső, hivatkozásokat és nem várhat el különleges beállításokat. Azaz ami kijött a verziókövetőből, annak úgy le is kell fordulnia akármilyen platformon. Persze megfelelő JDK és Ant és vagy Maven persze kell hozzá, de a megállapodás fontos. Talán még a legelején érdemes mindenkivel leüzletelni az egészet.
Szolgálati közlemény: Holnap elvileg JUM, legalábbis remélem mert már régen nem volt és ránk férne egy pár ötletcsere. Aki jó fej, az segíthetne egy 20-40 fős teremmel :-)
Abban az esetben, ha nálatok is minden csapat kitalálhatja magának hogy milyen build környezetet használ és esetleg bizonyos speciális dolgokat is beleépítetek (windowsos path-ok a build.xml-ben, exe fileok és más platform függő binárisok valahol a projectben, különleges classpath beállítások, környezeti változók, és a többi mocsokság), akkor a CI szervereteknél hamar felmerül az igény arra, hogy mindenkinek külön beállított build agentje legyen, amin az ő buildjei futnak. Egy kicsivel később már el is tulajdonolja egy-egy csapat ezeket a build agenteket és nem közös erőforrásként tekint rájuk, hanem inkább magántulajdon. Innentől kezdve egyes agentek majdnem teljesen kihasználatlanok lesznek, míg mások egész nap pörögnek, egyes csapatok csak másnap reggel kapják meg az eredményeket, mások azonnal.
Ez szerintem elég rossz irány és nagyon nehéz visszacsinálni ha egyszer megtörtént. Valamennyire le kell rendezni mindenkivel, hogy a buildje nem tartalmazhat speciális külső, hivatkozásokat és nem várhat el különleges beállításokat. Azaz ami kijött a verziókövetőből, annak úgy le is kell fordulnia akármilyen platformon. Persze megfelelő JDK és Ant és vagy Maven persze kell hozzá, de a megállapodás fontos. Talán még a legelején érdemes mindenkivel leüzletelni az egészet.
Szolgálati közlemény: Holnap elvileg JUM, legalábbis remélem mert már régen nem volt és ránk férne egy pár ötletcsere. Aki jó fej, az segíthetne egy 20-40 fős teremmel :-)
2008. október 13., hétfő
Egy hét scrum
Ritkán szoktam ide a munkámmal kapcsolatos dolgokat írni, márminthogy olyat ami konrétan a munkahelyemen történik, most viszont azt hiszem hosszú és érdekes hetünk volt.
Ahogy múltkor írtam, egy munkatársammal közösen dolgoztunk a UI tesztek Seleniumos megvalósításán. Ezután most a tesztelőnknek, aki eddig Visual Basic-ben kalapált egy ezer éves -és többezer dolláros- szoftverbe teszteket, adtunk egy eclipse-t, subersion hozzáférést és a srác még aznap elkezdett teszteket írni nekünk. Söt, tök jól haladt vele. Ez sokkal jobb mint amire számítottam, a learning curve egészen minimális volt. Még ezen a héten vissza is fizette a befektetett időnket a bárki által írható és futtatható automatikus teszt. Beidomítottam a Continuous Integration rendszerünket, hogy automatikus webapp deploy után futtassa le a UI teszteket is, és az aznap elszórt hibáinkat perceken belül megtalálta nekünk. Kézzel egyébként napokba tellene véggellenőrizni az alkalmazásunkat, elég cifrán el van bonyolítva :-D
A csapat felállása is megváltozott, ami már hónapok vagy talán évek óta érlelődött. Átálltunk a scrum metódikára, és egy hét munka után igazából azt lehet mondani hogy nagyon biztató a kezdet. Ez egyébként egy ismert (nem létezik hogy nem ismered) nemzetközi médiacég, az ilyenek nem a fürgeségükről és a rugalmasságukról ismertek, azaz valószinűleg az agile metodikák már majdnem teljesen mainstream dolgok lettek a világ minden részén.
Félig meddig külső segítségkünt kaptunk egy ausztrál srácot egy hétre, aki elmondta mindenkinek hogy miből áll az egész. Tisztáztuk hogy ki csirke és ki disznó (itt a rövid összefoglaló arról hogy miért), és hogy nekik mi a dolguk. Innetől kezdve, mivel disznó besorolást kaptam természetesen, nem kellett résztvennem olyan megbeszéléseken ahol konkrét példát említve valami skandináv országban tervezett marketingkampány részleteiről beszélnek :-) A csirkék egy részének ez úgy láttam kicsit fáj, nekik valamivel több munka az, hogy mi nem szedjük össze magnuknak az információkat a munkánkhoz, de úgy látszik beletörődnek és csinálják ezt a részt helyettünk. Pontosítok: eddig mi csináltuk helyettük. Egyébként a csapat egészén úgy láttam hogy nagyon megszerette az új rendszert és emögött én azt sejtem, hogy mindenki körülbelül azt csinál amit szeret csinálni: kódol, embereket irányít, tesztel, stb. A dologban nagy szerepe van a pozitív motivációnak is, látszott hogy most a project lényegesen jobban halad, több időt tudunk a munkánkra szánni, nem kell kisdobos találkozókra járnunk.
Az ausztrál srác nélkül nem hiszem hogy egy éven belül sikerült volna bármi ilyesmit összehozni, szóval ha van rá lehetőséged hogy külső segítséget kérj scrum bevezetéshez, akkor szerintem sokat segíthet. Egyrészt nagyon jól is adta elő a dolgokat, másrészt azt hiszem szükség volt arra hogy egy nagyjából külsős ember vezesse a cserét. Tőlem lázadásnak vették azt amit mástól reformnak.
Így néz ki a helyzet az első hét után, persze még hónapokba tellhet amíg a véglegesül az új módszer, talán fél év is lehet amíg a többi fejlesztőcsapatnak is megtetszik és követnek minket, akár évek is amíg a rendszergazdák, webmesterek, designerek megpróbálják bevezetni maguknál. Meglátjuk nálunk hogy muzsikál.
Most egy időre megint csend lesz, integrációs teszt megoldásokról fogok tanulni pár dolgot kicsit távolabb a nyolcker otthonos bűzétől. Többek közt.
Ahogy múltkor írtam, egy munkatársammal közösen dolgoztunk a UI tesztek Seleniumos megvalósításán. Ezután most a tesztelőnknek, aki eddig Visual Basic-ben kalapált egy ezer éves -és többezer dolláros- szoftverbe teszteket, adtunk egy eclipse-t, subersion hozzáférést és a srác még aznap elkezdett teszteket írni nekünk. Söt, tök jól haladt vele. Ez sokkal jobb mint amire számítottam, a learning curve egészen minimális volt. Még ezen a héten vissza is fizette a befektetett időnket a bárki által írható és futtatható automatikus teszt. Beidomítottam a Continuous Integration rendszerünket, hogy automatikus webapp deploy után futtassa le a UI teszteket is, és az aznap elszórt hibáinkat perceken belül megtalálta nekünk. Kézzel egyébként napokba tellene véggellenőrizni az alkalmazásunkat, elég cifrán el van bonyolítva :-D
A csapat felállása is megváltozott, ami már hónapok vagy talán évek óta érlelődött. Átálltunk a scrum metódikára, és egy hét munka után igazából azt lehet mondani hogy nagyon biztató a kezdet. Ez egyébként egy ismert (nem létezik hogy nem ismered) nemzetközi médiacég, az ilyenek nem a fürgeségükről és a rugalmasságukról ismertek, azaz valószinűleg az agile metodikák már majdnem teljesen mainstream dolgok lettek a világ minden részén.
Félig meddig külső segítségkünt kaptunk egy ausztrál srácot egy hétre, aki elmondta mindenkinek hogy miből áll az egész. Tisztáztuk hogy ki csirke és ki disznó (itt a rövid összefoglaló arról hogy miért), és hogy nekik mi a dolguk. Innetől kezdve, mivel disznó besorolást kaptam természetesen, nem kellett résztvennem olyan megbeszéléseken ahol konkrét példát említve valami skandináv országban tervezett marketingkampány részleteiről beszélnek :-) A csirkék egy részének ez úgy láttam kicsit fáj, nekik valamivel több munka az, hogy mi nem szedjük össze magnuknak az információkat a munkánkhoz, de úgy látszik beletörődnek és csinálják ezt a részt helyettünk. Pontosítok: eddig mi csináltuk helyettük. Egyébként a csapat egészén úgy láttam hogy nagyon megszerette az új rendszert és emögött én azt sejtem, hogy mindenki körülbelül azt csinál amit szeret csinálni: kódol, embereket irányít, tesztel, stb. A dologban nagy szerepe van a pozitív motivációnak is, látszott hogy most a project lényegesen jobban halad, több időt tudunk a munkánkra szánni, nem kell kisdobos találkozókra járnunk.
Az ausztrál srác nélkül nem hiszem hogy egy éven belül sikerült volna bármi ilyesmit összehozni, szóval ha van rá lehetőséged hogy külső segítséget kérj scrum bevezetéshez, akkor szerintem sokat segíthet. Egyrészt nagyon jól is adta elő a dolgokat, másrészt azt hiszem szükség volt arra hogy egy nagyjából külsős ember vezesse a cserét. Tőlem lázadásnak vették azt amit mástól reformnak.
Így néz ki a helyzet az első hét után, persze még hónapokba tellhet amíg a véglegesül az új módszer, talán fél év is lehet amíg a többi fejlesztőcsapatnak is megtetszik és követnek minket, akár évek is amíg a rendszergazdák, webmesterek, designerek megpróbálják bevezetni maguknál. Meglátjuk nálunk hogy muzsikál.
Most egy időre megint csend lesz, integrációs teszt megoldásokról fogok tanulni pár dolgot kicsit távolabb a nyolcker otthonos bűzétől. Többek közt.
2008. szeptember 26., péntek
Sonar 1.4.2
Nem akarok kicsi freshmeat.net-et indítani a blogomban, de tegnap a sonar fejlesztői kidobták a 1.4.2-es verziót, ami végre javítja a framework furi adatbáziskapcsolati hibáját. A JRuby ugyanis nem szöszöl holmi DataSource-okkal, hanem valami saját megoldása van az egészre. (Ezen a ponton a dolog nekem nem szimpi) Fel is űbereltem és idáig tényleg nem zuhant magába. Melóban már az 1.4.0 verziótól kezdve gyüjti a projecteink coverage adatait, annyi volt vele a probléma, hogy egy cron jobból időnként újra kellett startolni.
Eleinte kicsit lelombozónak tűntek az eredmények amiket produkált -ezt a munkatársak érdeklődésére, a saját stabilítására, sebességére és a generált grafikonok görvéire egyaránt értem- viszont lassan úgy tűnik mind a három valahogy javulgat. Sok-sok türelmet tanulok mostanában.
Eleinte kicsit lelombozónak tűntek az eredmények amiket produkált -ezt a munkatársak érdeklődésére, a saját stabilítására, sebességére és a generált grafikonok görvéire egyaránt értem- viszont lassan úgy tűnik mind a három valahogy javulgat. Sok-sok türelmet tanulok mostanában.
2008. szeptember 16., kedd
Selenium bütykölés
Ez a selenium dolog nem új a nap alatt, ha jól látom a jhacks bejegyzés majdnem 2 éve született rá. Akkoriban próbálgattam, igazán rajtam kívül nem sok embert érdekelt körülöttem, el is halódott. Ezzel mondjuk sajnos nem szünt meg az igény arra, hogy az alkalmazásokat a felhasználói felületen keresztül is leteszteljük, csak szerencsére az azóta munkahelyemen van erre dedikált ember, drága pénzért furcsa szoftver, tesztgépekből rakott hegyek, ilyesmi. Azt lehetne hinni, hogy akkor ez már a paradicsom, valami mégsem volt teljesen oké. Ez a drága-pénzért szoftver ugyanis valami elég ütős összegért lett megvéve per seat (hmmm...) emiatt mi -java fejlesztők- nem kaptunk belőle, mindig a QA csapathoz kell tehát rohangálni ha valamit meg akarunk nézetni. Ennél nyilván ideálisabb megoldás lenne, ha az automatikus tesztek tényleg automatikusan futnának le, például minden alkalommal, amikor egy szintén automatikus folyamat bedobja a legfrissebb verziót egy alkalmazás szerverre, valamint a fejlesztők is írhatnának tesztet, nem csak a teszt-fejlesztők.
Erre találtunk ki egy kicsit más felállást, csupa ingyenes/OSS cuccra építve (igazából a CI szerver pénzes, de ez most nem számít, vegyük úgy hogy például hudson)
Erre találtunk ki egy kicsit más felállást, csupa ingyenes/OSS cuccra építve (igazából a CI szerver pénzes, de ez most nem számít, vegyük úgy hogy például hudson)
- Mindenki ír tesztet, a QA team csak annyiban kitüntetett, hogy ők mást se csinálnak :-)
- Minden SVN módosulás elindítja a UI teszteket. Hát igen, kicsit terheli a gépeket, na bummm...
- A CI szerver nyomonköveti a UI tesztek futását és értesít azonnal ha valamit elszúrtunk.
- Illetve mindenki lefuttathatja saját magánál is a teszteket a saját alkalmazás példányán.
- Keresni kellett egy windows-os gépet, mert senkit nem érdekel hogy linuxon firefoxban jól működik-e a felület. Az már sokkal inkáb hogy az MS-IE bugjai között túléli-e. Egyelőre nem tudom hogyan kéne helyesen beállítani ezt a gépet, hogy például egy áramszünet után automatikusan bejelentkezzen rajta egy felhasználó és elinduljon a selenium szerver.
- Jó browser nincs, csak elég jó van. Valahogy a browserek, verziók, beállítások olyan sok hibalehetőséget jelentenek, hogy talán mintha nem is létezne univerzális megoldás. Az IE 7 + hta futtatás egyes gépeken nem megy (egyes gépeken az IE 7 sem például). Az IE 6 se sokkal jobb. Egyes pontokon mintha nem is ugyanazt csinálná, például nem hozza be a megfelelő oldalt. Nincs más kisérletezni kell. (A hta egyébként persze experimental állapotban van seleniumban)
- A browser problémákhoz képest a SSL problémák igazán semmiség volt, de rendet kellett tenni, ugyanis eddig nem volt rá motiváció, hogy korrekt https beállításokkal hajtsuk az apache-t.
2008. március 5., szerda
Amitől continuous az integration
Egy continuous integration szerver -szerintem- ott válik el egy sima nightly build cucctól, hogy nem egyszerűen csak lebuildeli a cuccod, hanem a különböző modulokból amiket fejlesztessz, abból egy éppen aktuális verziót rak össze és azon futtajta a teszteket.
Két megvalósítás...
A teamcity-ben lehet manuálisan beállítni project függőségeket, a build végén az eredményt (a jart) beletolja az új projectbe és azzal is leteszteli azokat a projecteket amik ezen a projecten függenek. Ant projectek esetén ez egyszerűen csak nem lehet jobb. A maven projectek közti függőségeket TeamCity-vel még nem néztem meg, de manuálisan biztosan azt is be lehet állítani ugyanígy.
Na és akkor elmondanám a másik megoldást: Continuum + maven, a continuum a pom alapján felismeri a két project közti függőséget. Ez a rövidebb és egyszerűbb dolog :-) Ant esetén nem tudom mi van, de a saját fejlesztéseimben nem használok antot.
A TeamCity és a Continuum további lényeges különbsége, hogy a TeamCity webes felülete piszok jól néz ki, ezért a munkatársak jobban szeretik. A szép dolgokról könnyebb elhinni hogy hasznos.
Két megvalósítás...
A teamcity-ben lehet manuálisan beállítni project függőségeket, a build végén az eredményt (a jart) beletolja az új projectbe és azzal is leteszteli azokat a projecteket amik ezen a projecten függenek. Ant projectek esetén ez egyszerűen csak nem lehet jobb. A maven projectek közti függőségeket TeamCity-vel még nem néztem meg, de manuálisan biztosan azt is be lehet állítani ugyanígy.
Na és akkor elmondanám a másik megoldást: Continuum + maven, a continuum a pom alapján felismeri a két project közti függőséget. Ez a rövidebb és egyszerűbb dolog :-) Ant esetén nem tudom mi van, de a saját fejlesztéseimben nem használok antot.
A TeamCity és a Continuum további lényeges különbsége, hogy a TeamCity webes felülete piszok jól néz ki, ezért a munkatársak jobban szeretik. A szép dolgokról könnyebb elhinni hogy hasznos.
2008. február 12., kedd
Hírek
A hét jó híre: Karenin tolja a JHacks híreit, szóval a régi közösségi események mellé mennyiségi és minőségi technológiai híreket is kaphatunk. Ez alkalomból lecseréltem a régi nagy böszme RSS ikont két kisebb XML ikonra, ott jönnek a hírek és a tartalomváltozások RSS-ben.
A nap első jó híre: a maven régi, sokak szerint elszúrt (szerintem is) XML formátuma, amiben csak tag-ek vannak de nincsenek attribútumok... Na ez most úgy tűnik lassan elmúlik a fejlesztő blogja szerint. A 2.0.9-től kezdve. Ez mondjuk nem holnap lesz, de remélem hamarosan.
A nap második jó híre: ráakadtam a sonar nevű alkalmazásra, ami egy érdekes frontend PMD, checkstyle, cobertura, surefire és stb elé. Nem ugyanaz mint a qalab, ez szerver komponens (viszont időbeli változásokat is figyel). Elösször is: semmit nem kell a project build leírásához hozzáadni, a maven pom.xml-jéből kitalál mindent amit ki kell. Mire nem jó, ugye, a deklaratív build... A statisztikákat egy tetszőleges adatbázisban gyűjti fel. Konkrétan az ami felgyűjti (egy maven plugin) az ennek az adatbázisnak a JDBC kliense. Én jobban szeretném az egészet, ha valami web service-n keresztül menne be az adat, és akkor csak egyet kellene mindenhol bekonfigolni: a sonar server URL-jét meg a firewallt se kellene bütykülnöm. Sebaj, végülis így is jó. CI szerverbe is simán be lehet lökdösni build definíciónak, és akkor van napra kész infónk arról hogy mi az ábra. QAlab done right :-)
A nap első jó híre: a maven régi, sokak szerint elszúrt (szerintem is) XML formátuma, amiben csak tag-ek vannak de nincsenek attribútumok... Na ez most úgy tűnik lassan elmúlik a fejlesztő blogja szerint. A 2.0.9-től kezdve. Ez mondjuk nem holnap lesz, de remélem hamarosan.
A nap második jó híre: ráakadtam a sonar nevű alkalmazásra, ami egy érdekes frontend PMD, checkstyle, cobertura, surefire és stb elé. Nem ugyanaz mint a qalab, ez szerver komponens (viszont időbeli változásokat is figyel). Elösször is: semmit nem kell a project build leírásához hozzáadni, a maven pom.xml-jéből kitalál mindent amit ki kell. Mire nem jó, ugye, a deklaratív build... A statisztikákat egy tetszőleges adatbázisban gyűjti fel. Konkrétan az ami felgyűjti (egy maven plugin) az ennek az adatbázisnak a JDBC kliense. Én jobban szeretném az egészet, ha valami web service-n keresztül menne be az adat, és akkor csak egyet kellene mindenhol bekonfigolni: a sonar server URL-jét meg a firewallt se kellene bütykülnöm. Sebaj, végülis így is jó. CI szerverbe is simán be lehet lökdösni build definíciónak, és akkor van napra kész infónk arról hogy mi az ábra. QAlab done right :-)
2008. január 2., szerda
Pár hét TeamCity-használat tapasztalatai
Még a JavaPolis-on találkoztam a JetBreains embereivel, akik bemarketingelték nekem, hogy a TeamCity most már ingyen is használható 20 projectig és 20 felhasználóig. Ezzel érdemesnek tűnt egy alapos kipróbálásra.
- Megpróbáltam a régi és az új perverz verziókövetőt is hozzáilleszteni a munkahelyemen. A rémlassú kapcsolatunkkal a verziókövető rendszereinkkel már az elején gebasz volt, erre az Jira-ba nagyon gyorsan adtak egy workaround-féleséget, amivel a Perforce (az új perverziónk) elment, az MS-VSS valami rettenetes összevisszaságot teremtett a filerendszeren. Nem vagyok bizos benne, de úgy látszik file nem maradt épen. Úgy látszik ezt valami natív VSS kliens okozza, amit a TeamCity futtat.
Ez túlélhető, ásatunk egy csinos kis gödröt a VSS-sel és megkérjük hogy térdeljen a szélére. - Itthon persze a finom kis SVN fut, ezzel pillanatig nem volt probléma, ezt mondjuk el is várom :-)
- Maven multiprojecteim buildelése. Ezzel van egy olyan különbség a continuum-mal szemben, hogy nem dobja be az alprojecteimet külön projectként. A probléma akkor következik, amikor az előző project teszt hibái miatt az új projectek tesztjeit már le sem futtatja. Ez mondjuk logikus, de jobban szeretném ha mindent mindig lefuttatna, SNAPSHOT verziókban mindig vannak törött tesztek. Na erre beállítottam egy -Dmaven.test.failure.ignore kapcsolót a maven paraméterei közé. Ezzel megy. Persze kérdés hogy ez mennyire korrekt.
- Ezt még nem tudom, hogy miért, de a build agent újrastartolása után újra azonosítani kell a szerveren. Hmm, sebaj.
- Az egyik eclipse installációban a TeamCity plugin nem működget. Valószinűleg az a baja hogy utólag dobtam utánna a SVN plugint. Nyilván, munkában nem használunk SVN-t, az túl egyszerű lenne. Viszont a windózos teamcity tray icon az csodás dolog, egy ilyet szeretnék én gnome-hoz linuxra.
2007. augusztus 16., csütörtök
QALab felhasználóknak
A üzemeltetés elfelejtett szólni hogy elrakják a kissé perverz verziókövető rendszerűnket máshova, ennek következtében a continuum érintett pluginje letörölte a teljes forrásfát egy pillanatra. Nem lenne érdekes, de benne voltak az utóbbi 3 hónap alatt összegyüjtöt teszteredmények.
Aki QALab-ot vagy ilyesmit integrál a build környezetébe, annak javaslom hogy tegye ki a qalab.xml-t a forrásfán kívülre, esetleg backupolni is lehet...
Aki QALab-ot vagy ilyesmit integrál a build környezetébe, annak javaslom hogy tegye ki a qalab.xml-t a forrásfán kívülre, esetleg backupolni is lehet...
2007. augusztus 14., kedd
Hungarian Notation
Változónév konvenciók.
Az ex-magyar májkroszoftos űrtúristától származó Hungarian Notation-nak éppenséggel lehet valami értelme nem típusos nyelvek esetén. Java esetén azt hiszem nem sok, ha meg használ az ember bármilyen IDE-t, akkor végképp semmi. Egy billentyűkombináció és látod a deklarációt. Lehet hogy nem kellene már arra készülni hogy bárki is nano-val vagy vim-mel, ne adj isten notepad-del akarja majd szerkeszteni a kódot. Igazából én jobban örülnék neki ha valami frankó dologot neveztek volna el így, még valami negatív kép alakul ki rólunk...
Tegnap volt életem körülbelül első összeütközése a fortran nyelvvel. Ez egy típusos nyelv, viszont az az arc aki írta a progit a saját hangulatáról nevezte el a változókat "shit" és "fuck" névre. A szintaxis is teljesen új volt, egy ideig eltűnődtem rajta hogy vajon mi célt szolgálhatnak ezek a változók :)
Szerintem kötelezővé kellene tenni a minden projecten a kódstílus ellenőrzéseket mint pl checkstyle, mégpedig rendszeresen, a continuous rendszerben például, és a violation-ök változásait projekt-vezetői szinten figyelemmel kisérni. Mondjuk a magányos fortran cowboyok még így is lelövik pár agysejtemet, de a legtöbb megmenekül.
Az ex-magyar májkroszoftos űrtúristától származó Hungarian Notation-nak éppenséggel lehet valami értelme nem típusos nyelvek esetén. Java esetén azt hiszem nem sok, ha meg használ az ember bármilyen IDE-t, akkor végképp semmi. Egy billentyűkombináció és látod a deklarációt. Lehet hogy nem kellene már arra készülni hogy bárki is nano-val vagy vim-mel, ne adj isten notepad-del akarja majd szerkeszteni a kódot. Igazából én jobban örülnék neki ha valami frankó dologot neveztek volna el így, még valami negatív kép alakul ki rólunk...
Tegnap volt életem körülbelül első összeütközése a fortran nyelvvel. Ez egy típusos nyelv, viszont az az arc aki írta a progit a saját hangulatáról nevezte el a változókat "shit" és "fuck" névre. A szintaxis is teljesen új volt, egy ideig eltűnődtem rajta hogy vajon mi célt szolgálhatnak ezek a változók :)
Szerintem kötelezővé kellene tenni a minden projecten a kódstílus ellenőrzéseket mint pl checkstyle, mégpedig rendszeresen, a continuous rendszerben például, és a violation-ök változásait projekt-vezetői szinten figyelemmel kisérni. Mondjuk a magányos fortran cowboyok még így is lelövik pár agysejtemet, de a legtöbb megmenekül.
2007. augusztus 7., kedd
CI könyv
Az InfoQ publikált egy fejezetet a diszkós srác könyvéből, érdemes elolvasni, nagyon jó a gondolat a komponensek megbízhatóságának kihatásáról az egész rendszerre. 3 darab 90%-os megbízhatóságú komponensből összeállított rendszer megbízhatósága csak 73% kürül van. Azt hiszem kicsit másként kéne kiszámolni ezt, de az eredmény nem lesz sokkal szebb.
2007. június 7., csütörtök
Járt útat járatlanért
Munkaadómnál, a HumanBrainProgramming Inc-nél a VeryBigCompanyOfAmerica OurOwnVersionControlThatRunsOnlyOnOurSoftware verziókontrol rendszeréről átmigrálunk lassan a CompletelyUnknownCompany VerySpecialProductWithANiceName termékére. A migráció első szárnypróbálgatásai sikeresnek tűnnek, az infrastruktúránkba behelyettesíteni viszont rémálom. A continuous integration rendszerek közül tegnap óta már 4-et kipróbáltam hogy melyik hajlandó vele együttműködni. Eddig egyik se. Az előző megoldást is csak egy continuum SNAPSHOT verzió (pre-alfa) tudta elvinni.
A relációs adatbázisoknál az SQL nyelv azért annyit ért hogy a leggyakrabban használt objektumokat (táblák, tárolt eljárások, triggerek, kütyük és izék) minden termékben ugyanazt a nevet kapták, nagyjából ezek mind ugyanazt csinálják.
A verziókezelőknél ezt a harmóniát még nem sikerült megközelíteni, persze mind kb ugyanazt tudja, de teljesen másként nevezi. Írhatnánk egy SVN-VSS szótárat azoknak akik még nem láttak VSS-t. Bár remélhetőleg már nem is fognak, ha eddig megúszták.
A continuous integration szerverek teljesen a technológiai görbe elején vannak, nemcsak hogy mindent másként hívnak bennük, de a koncepciók is egészen hajmeresztően eltérnek egymástól időnként.
A relációs adatbázisoknál az SQL nyelv azért annyit ért hogy a leggyakrabban használt objektumokat (táblák, tárolt eljárások, triggerek, kütyük és izék) minden termékben ugyanazt a nevet kapták, nagyjából ezek mind ugyanazt csinálják.
A verziókezelőknél ezt a harmóniát még nem sikerült megközelíteni, persze mind kb ugyanazt tudja, de teljesen másként nevezi. Írhatnánk egy SVN-VSS szótárat azoknak akik még nem láttak VSS-t. Bár remélhetőleg már nem is fognak, ha eddig megúszták.
A continuous integration szerverek teljesen a technológiai görbe elején vannak, nemcsak hogy mindent másként hívnak bennük, de a koncepciók is egészen hajmeresztően eltérnek egymástól időnként.
2007. május 10., csütörtök
My SOC
Persze hogy nem megyek nyaralni. Túrázni persze hogy megyek, de attól függetlenül már most készülgetek arra hogy nyáron lesz egy kis szabadidőm, és ez az egyik dolog amit szeretnék megcsinálni:
A Continuum-ba szeretnék egy kicsit erősebb integrációt építeni a maven report pluginjaival és a QALab segítségével, vagy legalábbis mintája alapján. A continuum szépen kifigyelné a test kimeneteket, eltárolná és innen lehetne a project élettartamán végig figyelni a változásukat.
Azért continuum, mert annak van elég komoly integrációja mavennel, és azért maven, mert az az egyetlen build tool, ami foglalkozik kifejezetten test futtatással és riportolással.
Semmi új, tudjátok, csak máshova tenni azt ami már létezik. Utálom a megdöbbentően új dolgokat :) Persze lesznek kihívások, nade ismeritek a törpök életével kapcsolatos népi közhelyet...
A Continuum-ba szeretnék egy kicsit erősebb integrációt építeni a maven report pluginjaival és a QALab segítségével, vagy legalábbis mintája alapján. A continuum szépen kifigyelné a test kimeneteket, eltárolná és innen lehetne a project élettartamán végig figyelni a változásukat.
Azért continuum, mert annak van elég komoly integrációja mavennel, és azért maven, mert az az egyetlen build tool, ami foglalkozik kifejezetten test futtatással és riportolással.
Semmi új, tudjátok, csak máshova tenni azt ami már létezik. Utálom a megdöbbentően új dolgokat :) Persze lesznek kihívások, nade ismeritek a törpök életével kapcsolatos népi közhelyet...
2007. április 18., szerda
Unit tesztek idővonatkozásai
Mind a TestNG mind a Junit 4.x támogatja a teszt futásra tett timeout-ot, ami hasznosnak látszik amikor kritikus kérdés a művelet idő igénye. Az idő-igény az valahonnan a számítás-igényből származik, és innen kezdve az ember már sejti hogy egy művelet futási idejét nem lehet csak úgy megsejteni, mert java esetében nagyban függ a virtuális gép paraméterezésén is, a processzorról és a többiről nem is beszélve.
Emellett interface-re írt tesztek esetén nagyon kevés értelme látszik a timeout-nak, hiszen az interface nem tartalmaz elvárást az implementáció futási idejére. Arra a futás időre amiről az derült ki az elöbb hogy csak homályos arányszámokban sejtjük.
Következtetés: a timeout inkáb arra jó hogy lockolás és egyéb problémák miatt ne ragadjon be a teszt a CI szerverbe, hanem inkáb hasaljon el, ehhez viszont bőven nagy időkorlátot kell megadni, amit a leggagyibb implementáció se tud alulmúlni. Performance tesztre nem igazán oké.
Mekkora havaj amikor vannak junit tesztek, most már nem fogom engedni hogy bármi bajuk essen :)
Emellett interface-re írt tesztek esetén nagyon kevés értelme látszik a timeout-nak, hiszen az interface nem tartalmaz elvárást az implementáció futási idejére. Arra a futás időre amiről az derült ki az elöbb hogy csak homályos arányszámokban sejtjük.
Következtetés: a timeout inkáb arra jó hogy lockolás és egyéb problémák miatt ne ragadjon be a teszt a CI szerverbe, hanem inkáb hasaljon el, ehhez viszont bőven nagy időkorlátot kell megadni, amit a leggagyibb implementáció se tud alulmúlni. Performance tesztre nem igazán oké.
Mekkora havaj amikor vannak junit tesztek, most már nem fogom engedni hogy bármi bajuk essen :)
2007. április 12., csütörtök
Continuum 1.1 preview
Alpha release elött áll a continuum 1.1, aki türelmetlen, vagy akinek nagyon fáj a foga az eddig nem támogatott perverz SCM implementációkra (mint én) annak rendelkezésére állnak nightly release-k, egész stabilak.
Az újdonságok közül:
Az újdonságok közül:
- Project csoportok.
- Notifier-ek projecte csoportokra és projectekre is.
- Finomabb role kezelés, már lehet project csoportonként kiosztani különböző szerepeket (admin, fejlesztő, felhasználó)
- Végre működik azzal a bizonyos PiciPuha verziókövetővel, ami annyi fejfájásom és minden fejlesztési processz probléma kimeríthetetlen forrása :)
- Emberbarátibb schedule szerkesztő felület
- A logót már a company POM-mal lehet beállítani, ez spec nem mindig jön jól, de talán sikerül rácsábitani a népeket a company POM-ok megírására
- Mint már írtam régebben, a maven 2 projecteknél ha van SNAPSHOT dependency, akkor akkor is buildel ha nincs változás a forráskódban, helyes :)
2007. március 8., csütörtök
Random ötletek a CI-ről
Kicsit aktívabb együttműködés lehetne a CI és a teszt frameworkok között. Például a project életciklusa alatti teszt-eredmény változások, futásidő, ilyesmi, ezt valahogy a CI-nek kellene megjegyeznie. Legalábbis a build résztvevők közűl leginkább rá tartozik az ilyesmi. Erről már nyűglődtem azt hiszem.mi lenne akkor
-na jó, ez csak elmélet-
ha sokkal hosszabbra
nőne a kezem...
Aztán konkrétan a continuum esetében, ha már maven-t hajtunk, ha egy projectnek van SNAPSHOT dependency-je, akkor szerintem az tűnik logikusnak hogy akkor is újra kell buildelni teljesen, ha nem történt változás a forráskódban. Ugyanis a dependency-ben attól még lehet hogy történt változás. Pont erről szólna a mese. Ennek utánakérdeztem és Brett azt mondja az 1.1 már így csinálja. Frankó, csak győzzem kivárni.
Meg esetleg egy egységes felület eléjük jó lenne, mint a Cargo a J2EE szervereknek. Erre lehetne falazni a IDE integrációkat, és akkor nem kéne mindegyikhez külön plugin. Mint a JDBC driverek-nél.
Ennyi jutott hirtelen eszembe. Egyébként nyilván ha annyit használnánk mint ami már megvan, akkor is sokkal közelebb lennénk.
Bocsi a kaoitkus postolásért, ma kicsit kiégett az agyam.
Feliratkozás:
Bejegyzések (Atom)