Maven, Release, Hudson

Tuesday, July 27th, 2010 | Uncategorized | No Comments

Az ideális releaselés minimum követelményeit így képzelem:

1. A release automatikus (egy gombnyomásra történik) és a CI szerver készíti el
2. hiba esetén újra lehet indítani
3. nem befolyásolja közben a fejlesztést (nincs commit csönd)

Alapvetően sose voltam nagy barátja a Maven release pluginnek, kicsit merevnek tartottam, de hosszas kísérletezés után legtöbb esetben még mindig ez tűnt a legkevésbé problémás megoldásnak. Kicsit kell figyelni a pom-ok felépítésére, de az még jó is, ha tisztább pomokra kényszerít. (Egyébként a forrása is viszonylag kellemes csalódás volt, egész szép, leszámítva a modellos fejlövéstől, amit az előzőekben már felhánytorgattam).

Ha a maven release plugin már adott mint eszköz, akkor még mindig van néhány nyitott kérdés:

1. trunkon vagy branchen?

A kedvenc koncepcióm a tárgyban itt olvasható. (Git-ről beszél, de Mercuriallal ugyanúgy használható). Ez egyértelműen azt javasolja, hogy külön ágon releaseljünk. Ez egy kicsit megbonyolíthatja a release folyamatot, de amellett előnyei is vannak:

1. a hármas pontot alapból kielégíti. A release branchre rámergáljuk a trunkról a stabil változatot, és release közben már senki se ronthatja azt el.
2. lehetőség van arra, hogy ne csak a trunk ágat, hanem más ágakat is releaseljük. Ha egyszer a release ágon működő release-gép tökéletes, akkor csak azt kell elérni, hogy bárhonnan a release ágra mergeljünk bármilyen kódot (akár egyoldalú merge-vel, ahol minden fájlból a külső branchen lévő változatot tekintjük alapnak).

A .2 pont persze már eltér a fenti linken található ábrától, amely ábra külödben sem is használható tisztán maven release pluginnel, mivel pl. a tagelést a plugin egyértelműen a release branchen végzi. A 2-es pont szerint a release branchünk igazából csak egy staging hely, ahová felrakhatjuk a kódot, amíg a release sikerül, és a mikor ténylegesen kész lesz, akkor vissza mergelhetjük.

2. külön release job a hudsonban vagy nem?

Ha használjuk a trunk mellett a release branchet is, akkor rögtön jön a probléma, hogy a hudsonon alapból a trunk branchet akarjuk buildelni, de releasekor a release branchet. Ezt a hudson egy kicsit nehézkesen kezeli. Léteznek workaroundok: pl. m2 extra stepst-ben hg parancsok, vagy paraméterezett build, ahol a paraméter alapján checkoutol, de a gyakorlatban nekem egyik se bizonyult stabil megoldásnak (az átláthatóságról nem is beszélve).

Az egyszerű megoldás, amit épp követünk, új jobot hozunk létre a Hudsonon. Klónozzuk az eredetit, és az új job az előzőekkel megegyezően működik (változás esetén sajnos mindig frissíteni kell a build paramétereket), de a release branchet forgatja (célszerűen private local maven repository-t használva!!).

A külön job-os megoldás arra is jó, hogy a release branchre való merge után még egy utolsó ellenőrzésként egy hagyományos buildet is kérhetünk az ágra, mielőtt a release build-et kérjük a hudsonból

3. M2 release plugin vagy általános release plugin?

A Hudsonban két release plugin is van. Egy általános és egy kifejezett Maven-re szabott. Mindkettő azt nyújtja, hogy megjelenik egy új gomb is a job oldalán: a build now mellet lesz egy start release build opció is.

Az általános release pluginban  pre-steps és post-steps lehetőségek vannak. A release build gyakorlatilag egy rendes build, csak a post f’ázisban tetszőleges múveleteket (pl. release:prepare release:perform) is elvégezhetünk. Sajnos a Hudson korlátai miatt a post lépések mindenképpen lefutnak még akkor is, ha a rendes build elhalt, ami nem túl elegáns.

Az általános release pluginnak viszont kellemes szolgáltatása, hogy a release buildet tartóssá teszi (keep this build forever) és meg is tegeli. Így a job lefutásai között egyértelműen látszik, hogy melyik volt a release.

Egyelőre én mégis a Hudson M2 release plugint használom. Ez kifejezetten Maven releasere lett kitalálva, tehát korlátozottabb tudású, azt viszont jól csinálja, és nem kell trükközi post stepekbe rejtett release logikával. A sikeres release buildet aztán kézzel tartosítom (keep build forever).

4. staging scm vagy éles?

Az egyik problémája a release pluginnek, hogy elosztott SCM esetén nem csak commitol, hanem pushol is. Ha a release mégsem sikerül, akkor is teleszemetelte a repónkat mindenféle saját committal. Erre ad egyfajta megoldást Fabrizio Guiduci. Ennek lényege, hogy a release alatt egy profile/property trükkel az aktuális scm bejegyzést egy temporáls repositoryra állítja át, így oda fog pusholni a release plugin. Amennyiben a release sikeres volt, akkor a staging repositoryból lehet pusholni az élesbe.

Volt, ahol használtam ezt a trükköt, de ma már úgy látom, hogy nincs nagy jelentősége. Egyrészt mivel külön release branchen releaselek, ott nem zavarnak a felesleges commitok annyira. Legrosszabb esetben hg backout-olok (remek parancs, egy adott commit diff-jét invertálja és commitolja újra be.) Git-be meg ugye alapból lehet changeseteket törölni.

Másrészt mivel a Hudson-on a release branchre rá van állítva a release job, amit release előt még sima buildel ellenőrzök, az esetek nagy részében a releasenek már hiba nélkül kell lemennie. (Általában hiba ebben a fázisban már csak akkor merült fel, ha pont a pusholás volt sikertelen)

5. staging repo vagy éles?

Az előbbi linken nem csak a mercurial repositoryból csinált stage-et az író, hanem a cél Maven repositoryból is. Kezdetben csak egy temporális helyre deployolt, és ha minden jól ment, akkor onnan egy maven pluginnel tolta fel a végleges helyére a buildelt artifactokat.

(Egy kicsit kidolgozottabb staging koncepció is létezik, amit a Nexus Pro támogat.)

Eddig az volt a tapasztalatom, hogy ilyenek nélkül elég jó tudok élni. A deploy a release:perform utolsó lépése, tehát ha felmentek az artifactok, akkor a release már jó volt, ha nem ment fel, akkor még gyűrni kell. De olyan eset eddig nem volt, hogy felment, de le akartom volna szedni.

Egyéb tapasztalatok

1. A maven release plugin nem szereti, ha elosztott verzió kezelőt használunk és nem a gyökérben van a pom.xml. A release:perform lépésben ugyanis a target/checout könyvtárba az egész repót klónozza, de arra nem lehet rávenni, hogy a repó egy alkönyvtárát buildelje csak meg. Botrány.

2. A release:prepare lépés során történik egy ellenőrzés. A checkoutolt source-on a maven futtat egy clean verify kombót. Ez kellemetlen meglepetésekkel szolgálhat, ha az alprojektek kézileg össze vannak kötögetve. (Pl. dependencies:unpack). Ekkor a nagyerejű -DpreparationGoals=”clean install” segíthet.

A többi meg már megy magától.

Tags: hudson, maven, mercurial, release

Modello, Maven

Tuesday, July 20th, 2010 | Uncategorized | No Comments

Egyszer már kitaláltuk egy kolegával (talán már le is írtam), hogy csinálni kéne egy kiégett Java blogot, ahol minden bejegyzés keserű kiábrándultsággal ostorozna valamilyen Java terméket vagy technológiát (user name: Thomas Bernhard). Az esetek nagyrészében bármilyen jó is legyen a program, fogást jó eséllyel lehet találni rajta.

A Mavenről pl. kevés ember hiszi, hogy egy jól megtervezett alkalmazást. Roszmájúak szerint csak egy kicsit kellett volna gondolkozni mielőtt elkezdték volna fejleszteni. Reálisabban úgy is lehet fogalmazni, hogy azóta mindenki sokat tapasztalt már a build tool businessben, ma már nyilván ezen tapasztalatok fényében jobb build tool-t lehet írni (hello gradle, hello buildr), de az utat kétségkívül a Maven taposta. És az is érthető, hogy amikor kezd de facto ipari standard lenni a Maven használata, akkor a Sonatype-nak nem érdeke egy nagy nem-kompatibilis refaktor. (Jó ilusztráció pl. a plexus IoC konténer használata, mivel amikor a Mavent elkezdték kalapálni a Spring nem volt még tényező, a Guice-ról még el se gondolkoztak. Viszont néhány ügyes varázslattal elég jó eredményeket értek el a Sonatype-osok a plexus>guice migrációban, úgy hogy minden visszafelé is kompatibilis maradt).

De igazából nem is a Mavenről akartam írni, hanem Modello-ról. Azt is eltudom képzelni, hogy eredetileg volt valami érv a  használata mellett. De így kívülről a partvonalról nehezen tudom elképzelni ezeket az érveket. Azt értem, hogy mindenféle XML writer/reader-t generál, de ezekre azért vannak már dinamikus frameworkok is. És csak ezért felvenni a kód generálás keresztjét, mert akkor dom4j writer-t nem kell írni… Hát, nem tudom.

Ma pedig pont a maven release plugin patchelése közben találkoztam egy szép MDO-val. Na ezt az XML-Java turmixot magyarázzal el nekem valaki.

Tags: maven, modello, wtf

NoSQL házi helyzetjelentés

Tuesday, July 13th, 2010 | Uncategorized | 2 Comments

Az előző posztban vázoltam egy feladatot, amiben NoSQL adatbázisokba dolgozom fel az OSM térképadatait. Az aktuális kód elérhető a bitbucketről, az alábbiakban néhány megjegyzés hozzá, minden rendszer nélkül:

1. Az OSM adatszerkezete egyszerű, három típus van: node (egyetlen pont a térben), way (nodeok halmaza, lehet nyílt és zárt is), relation (nodeok és way-ek halmaza). Persze mindegyikbek van földrajzi koordinátája és kulcs érték pár típusú attribútum halmaza.

2. Jelenleg Magyarország hozzáférhető térképadataival dolgozom. Ebben nagyságrendileg 900 ezer node és 80 ezer way van.

3. Backendnek első körben a MongoDB-t kezdtem el használni. (Ákosnál épp olvasható róla egy rövid bevezető)

4. Betöltéshez az Osmosis programot használom. Ez tud az OSM export XML-ekkel dolgozni, illetve ezeket  transformálni is tudja. Elég ügyesen meg van írva: pipe-ok vannak benne, és ezeket lehet egymás mögé tenni. Én egy egyszerű pipe-ot írtam, ami tetszőleges helyről származó OSM adatokat (nálam egy xml reader pipeból származókat) tölt fel mongodb-be.

5. A forrás XML 100 Mb. A betöltendő adatok nagyságrendjét már írtam. A betöltés néhány másodperet vesz igénybe.

6. A MongoDB szinte az egyetlen olyan NoSQL DB, ahol van geospatial index is. Ez egyszerű feladatokhoz elég jó, de komplexebb lekérdezésekhez már nem elegendő. Mivel más NoSQL adatbázisokat is akarok használni backendnek, ahol még ennyi sincs, ezért kézzel kell implementálni hozzá indexet.(*). Ehhez találtam egy nyílt Java-s rtree implementációt. Az rtree nem a leggyorsabb algoritmus, de egy elég jó alap megoldás, ami kezdetnek jó lesz.

(Megjegyzés: *. A kézzel írt kvázi indexelés nagyon jól mutatja a NoSQL lehetőségeit. A NoSQL csoportba sorolt adatbázisok általában sebességben verik a relációs elődöket, de cserébe  kompromiszumokra kell számítani. Egy jól meghízott RDBMS sok olyat is ad, amire nincs is szükségünk, de az is előfordul, hogy a NoSQL kőbalta szintjére saját magunknak kell valami ottani szolgáltatást implementálni. Pl. programozás technikákkal gondoskodni kell, hogy tranzakció nélkül is konzekvensek legyenek az adatok. Ez persze plusz munka is lehet, meg szemlélet váltás is, de onnantól pedig egyedi megoldásra egyedi program jó eséllyel versenyre kelhet egy sokkal komplexebb és okosabb, de általános megoldással).

7. Az RTree implementáció nem rossz alap, de nincs felkészülve külső adattárolókra, márpedig én MongoDB-be szerettem volna tárolni az rtree-t, hogy lekérdezés esetén annak segítségével találjam meg egy adott területen elhelyezkedő összes elemet. Ezért kicsit átalakítottam. Az átalakításban alapvetően a gyors eredmény számított, nagyon ráférne egy kis optimalizálása (habár az algoritmus eredetileg a memóriában végzett műveletekre nagyon optimalizálva van, már talán túlságosan is. Pl. az Integer osztályok példányosításának a számára is figyelt az alkotó).

8. Az rtree indexelés remekül lefut. A gond ott van, hogy ha egy meglévő adatbázisra (800ezer bejegyzés) futtatom le, akkor a teljes indexelés 4 órát tartott (persze nincs optimalizálva, hanem egyfolytában a MongoDB-hez fordul). Megoldásként első körben a memóriában rakom össze a fát, és utána perzisztálom. A fa kiszámolása fél percet vesz így igénybe, a perzisztálás másodpercnél hamarabb megvan (34 ezer index rekord)

9. A végső próba úgy néz ki, hogy a JOSM nevű grafikus térkép rajzoló programban átállítom a szerver kiszolgálót a saját megoldásra, ami REST alakú lekérdezéseket küldd, és a válaszban érkező pontokat kirajzolja és szerkeszthetővé teszi. (a visszatöltés jelenleg nem célom). A mostani állapotban azt értem el, hogy ez működik, de csak node-okra (a nagyon optimális rtree sajnos még nem tudja kezelni, hogy létezhet node és way ugyanazzal az id-val), és az attribútumokat nem tárolja még.

10. A szerver oldal egy JavaEE6-os JAXRS-es alkalmazás. A JAXRS elég könnyen használható, de kell hozzá stabil JAXB-s ráhangoltság. Ott vannak félelmeim, hogy a nagyméretű adatkiszolgálásnál , hogy az eredményt tudja streamelni. Szerintem nem tud, ami miatt féltem kicsit a memóriát, de ezt még meglátjuk, hogy meg akarom-e oldani.

11.A MongoDB-ről néhány személyes élmény a teljesség igénye nélkül

• elég kényelmes használni, jó a command line interface-e is
• rendszeresen lelőttem futó db alól a laptopomat (érstd az áram kikapcs akkumulátor nélkül) és elég jól túlélte
• nagy szabadság, hogy nincsen séma benne, és mégis elég jól indexel
• valamilyen O(R)M jellegű mappolás nélkül elég fapad a Java API-val használni. Léteznek ilyenek, de én nem használtam, mert 800ezer rekodrnál már számít mennyit refletionözök. Így viszont elég szegényes.
• Clustert még nem próbáltam, viszont a leírás alapjáns csak master-slave replikációt. (helló, magas rendelekzésreállás, helló). Tulajdonképpen ez az, mi miatt leginkább elfordulok felőle. Bár annyit tud, mint amennyit egy MySQL adna, szóval sokszor elég lehet.
• Egy dokumentum írása atomi művelet. Ez még jól jöhet.

A közeljövő feladatai:

• Az rtree implementációt meghackolni, hogy több fajta objektumot is tudjon indexelni
• a nodeok és way-ek attríbutumait is tárolni kéne és a relationokat is kezelni kell
• az Osmosis pluginba beilleszteni az indexelést is
• cassandra backendre is implementáni az interfaceket
• MongoDB-n kipróbálni még:
  • map reduce algoritmus js-ben írva (bár 1 node-on ugye nem várunk csodát tőle)
  • ránézni az ORM-nek megfelelő megoldásokra
  • JS API-val kicsit barátkozni

(Biztos kimaradt valami, de most már olyan fáradt vagyok, hogy az elgépeléseket sincs erőm kijavítani. Peace.)

Tags: mongodb, nosql