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

Maven vs. scripting

Saturday, March 14th, 2009 | Uncategorized | No Comments

Van egy régi félkész projekt, ami az előző munkánkból potyogott ki, mint újrahasznosítható alkatrész. A központi része egy absztrakt adatbázisséma reprezentáció Java osztályokból. Ezt az absztrakt fát fel lehet építeni többfajta forrásból (pl. Oracle DB connection alapján leképezi egy meglévő DB felépítését, vagy egy Jar-t megadva leképezi a Jpa entitások által meghatározott sémát az absztrakt adatbázis sémává). Természetesen az absztrakt DB sémát ki is lehet iratni (célszerűen mindenféle adatbázis specifikus SQLé). Illetve egy eszköz meg tudja mondani két sémadefiníció különbségét, és azt is le tudja képezni SQL parancsokká.

Mire jó? Mi két dologra használtuk. Egyrészt a JPA osztályokból előállítottuk azokat a fájlokat, amikben az SQL parancsok voltak, amivel a sémát fel tudtuk építeni. Ez már csak a Unitils-es teszt környezetünk miatt is kellett, ami, ha érezte, hogy az SQL-ek megváltoztak, a teszt adatbázist rögtön törölte, és felépített egy teljesen új adatbázist. Másrészt a fejlesztési adatbázist is tudta frissíteni, mert beolvasta a jelenlegi sémát (Oracle system táblákból), és az új sémát (JPA osztályokból), összehasonlította a kettőt, és a különbséget SQLben mondta el. Így a fejlesztési adatbázist (és akár az éleset is) tudtuk inkrementálisan frissíteni, úgy hogy a meglévő tartalom ne vesszen el.

Most jön a lényeg. A projektet kicsit kipofoztam múltkoriban, és már ott tartok, hogy csináljak hozzá ANT taskot és Maven plugint. Azon gondolkoztam, hogy hogyan tudnám a konfigurálhatóságot úgy megragadni, hogy az egyes elemeket bármilyen párosításban lehessen használni. Bárhonnan tudjak sémát beolvasni (létező Oracle vagy Mysql séma, JPA osztályok), és bármit meg tudjak velük csinálni (Mysql vagy Oracle specifikus kiiratás, összehasonlítás különbség számítás).

Arra gondoltam, hogy a legrugalmasabb az lenne, ha nem az XMLen kéne erőszakot tenni, hanem mondjuk valami scrip nyelvel lehetne megfogalmazi, hogy mit akarok, és milyen összetételben.Az első tesztek szerint a JSR-223 teljesen jó megoldást adna, mindenki abban írhatná meg a logikát, amiben akarná, akinek meg mindegy, annak ott az alapértelmezésben is elérhető JavaScript motor a Rhino. Ez utóbbival (a még teljesen átgondolatlan API) valahogy így föst:

new DDLWriter();.generateDDL(new JPAReader(“target/test-classes”).readDefinition()).printAll();

Az elképzelés az, hogy csinálok egy Maven plugint, amibe ezt bele lehet írni konfigurációként. Persze ez rögtön általános Maven plugin lenne, amibe bármit lehetne írni bármilyen JSR-233az script nyelv segítsévégel. Akár már létezhetne is ilyen plugin (rákerestem, nem találtam), amivel ha mást nem a Maven kicsit merev logikáján és deklaratív eszméjén sikerülne rést ütni. Valahogy úgy mint az antrun plugin, csak itt ráadásul scripteket lehetne írni ANT XML részletek helyett.

És itt, hogy ne nyúljak túl hosszúra, inkább Szczepan Faber-t a Mockito szerzőjét idéznem:

“After Jason Van Zyl’s session I had an impression that he believes the best fit for the build system is a declarative architecture. I tend to disagree and I believe the build has inherent scripting nature.”

Tags: JPA, jsr223, maven, rhino, scripting

Jason van Zyl: Efficient Enterprise Builds

Thursday, December 11th, 2008 | Devoxx | 2 Comments

Gyakorlatilag Maven-es előadás, Maven és közel álló eszközökről: m2eclipse, tycho, maven, hudson, nexus.
A (számomra) érdekes rész a következő Maven kiadásról szóló fóliák voltak (Eclipset aktuálisan nem használok, Hudsont meg úgyis, Nexus telepítése todo listán) Rengeteg kisebb változás (versionless parent element, XML POM fromat with attributes), és rengeteg alapvető dolog: teljesen újraírt komponensek, teljesen kicserélhető részek, okosabb pluginelhetőség, mixinek stb.

Elég ígéretesnek tűnt, bár csak egy részét sikerült az újdonságokat felfogni. (A demó sajnos nem a részek közt volt, mert az laptop nem bírta a váltogatásokat). Néhány bejegyzéssel azelőtt pont azt némi ügyes kiterjeszthető hookot, és jól átgondoltásgot hiányoltam a Maven-ből,  úgy tűnik meg fogom kapni.

Tags: build, maven

Dependency management és Apache (pletykák)

Tuesday, December 9th, 2008 | Devoxx | No Comments

Na, akkor még egy kis pletyka. Miután az előző bejegyzést elküldtem, még beszélgettünk kicsit. Egyrészt valaki megkérdezte, hogy a Maven miért nem használja dependency managerként az IvY-t. Azt mondta Xavier, hogy volt róla szó, és beszélgettek róla a Mavenesekkel, és mindketten rendkívül nyitottak, csak még nem lett belőle semmi. Állítólag a Mavenbe nagyon bele van drótozva a függőség kezelés mindenhová, de vannak rá törekvések, hogy ez refaktorálva legyen, vagy esetleg cserélhető függőség kezelő legyen.

Beszéltünk még az EasyAnt-ról, ami az ő proof-of-concept projektje volt: ez egy ANT alapú de a Maven koncepcióit elsajátító rendszer volt. Én azt hittem, hogy elsikkadt az egész, de kiderült, hogy ugyan neki nincs rá ideje, de mások fejlesztgetik tovább (easyant.org), csak sajnos most csak egy patch-elt ANT-tal tud együttműködni. Elvileg a patchek átmennek majd az ANT forrásba, és az ANT következő release-vel lehet majd könnyen használni.

Valamint tt van még a Gradle (tegnap volt előadás, de nem azon voltam), ami egy Groovy alapú build rendszer, amit szintén IvY-t használ. Persze annak az IDE támogatása valószínű még rosszabb, ezért is izgalmas projekt az EasyAnt, mert ANT-ot viszont mindenki támogat, és ha ANTba okosan beépül, akkor már szinte mindenhol ott van.

Tags: apache, build, ivy, maven

Maven nyűgök

Monday, September 15th, 2008 | Uncategorized | 2 Comments

Lassan kikerülhetetlenül beszivárog az életembe a Maven minden előnyével és hátrányával együtt.

Az egyik legkényelmetlenebb dolog a használata közben, hogy ha egy projekt több modulból is áll, és az almodulok függenek egymástól, akkor a függőségeket nem fordítja újra a Maven egy adott almodul fordításakor.

A NetBeans pl. az ANT alapú projekteknél ezt csinálja: ha van egy közös lib projektem, amit a war és az ejb modul is használ, akkor a war fordításakor megnézi, hogy a lib-be változott-e valami, és ha igen automatikusan újra fordítja.

A Maven ilyet nem csinál (vagy nem tudom, hogy hogy lehet ezt elérni). Próbáltam rákeresni, de csak azt a választ találtam, hogy ilyet filozófiailag ne akarjak. A modulok önállóak, és ha változtatok valamit az egyikben, azt külön teszteljem, majd terjesszem az új változatot a repositoryn keresztül. Ezt a választ egy ideig el is fogadtam, csak a kolegáim kérdőjelezték meg, hogy talán egy csupa DTO-t tartalmazó projektet nem nagyon kell tesztelni, és az igazán le fordulhatna automatikusan, ha csak egy új gettert raktam bele.

(Ja, és még azt is ki kell derítenem, hogy hogyan lehet elérni, hogy hogy a package phase-ben ne hívódjon meg a jar:jar. Az ellenkezőjére már sok példát láttam, az executions jól megoldja, de az nem világos, hogy hogyen lehet törölni executionst. Lehet, hogy nem úszom meg, hogy a maven forráskódját is meg ne ismerjem?)

Tags: build, maven