2009. március 23., hétfő

maven release plugin

Úgy egy éve áttértünk a melóban is maven-re. Igazából ennek nem holmi technikai "megvilágosodás" állt a hátterében, egyszerűen annyi, hogy a főnököm magasabb pozícióba lépett és a technikai jellegű feladatait átadta nekem, én pedig a magam módján folytattam. Bocsi ezért a kitérőért, csak a honi csillagászat fejlődéséről olvastam egy nagyon jó könyvet nemrég, ami számos helyen megemlítette, hogy a paradigmaváltásokhoz egyszerűen csak generációváltás kellett a csillagászok között is. Na, ennyit megtettem ennek a mém-nek a túléléséért.

Nemrég egy másik projecttel kapcsolatban mégiscsak kiváncsiak lettek a többiek hogy hogyan csinálok egy release-t ebből az egészből. Elkezdtem hát elmutogatni a maven release plugin hogyan működik és azt hiszem volt pár dolog amin jogosan ráncolták a homlokukat.

Ennyi, amit csinálok: mvn release:clean release:prepare release:perform

Ezt csinálja helyetted a release plugin "release:prepare":
  1. Megnézi, hogy szinkronban vagy-e a verziókövetőddel
    Igen, itt például svn parancsot akar futtatni az operációs rendszereden keresztül. A $PATH-on rajta kell legyen. Itt kezd macerássá vállni a dolog a windows felhasználóknak.
  2. Lefuttatja a teszteket.
  3. A pom.xml-ben módosítja a verziót akármi-SNAPSHOT-ról simán akármi-re. Ezzel a SNAPSHOT dologgal is keresztben vannak páran nálunk, én nagyon bírom. Ezután bekommitolja a pom.xml-t, és egyből létre is hoz neki egy tag-et. Azaz létrejött egy tag, amihez nem is kell hozzányúlni, hogy a pom-ban a korrekt információk benne legyenek a verziójáról és persze ay SCM tag is a megfelelő információt tartalmazza.
  4. Átírja a pom.xml-t a legfrissebb fejlesztési verzióra és a scm url-t trunk-ra (illetve arra a branch-ra, ahol vagy) és bekommitolja. Szóval szépen elindított téged a következő verzió felé.
Majd a release:perform:
  1. Az éppen az "elöbb" betagelt verziót kicsekooutolja a target dir alá akárhova...
    A release:perform onnan tudja, hogy mi lett tagelve az elöbb, hogy hagy magának egy file-t a pom.xml mellett. Ezt a file-t a release:clean parancs törli le, ezért ezt is a biztonság kedvéért (azaz hogy ezen se kelljen gondolkodnom) a release parancs elejére oda szoktam írni, nehogy ott legyen az előző futásból és valami hülyeséget csináljak.
  2. Lefuttatja rajta a unit-teszteket, csak hogy biztos legyen a dolgában :-)
    Itt az a trükk, hogy igazából egy új mvn processzt indít el, azaz ha nincs az mvn parancs a $PATH-ban, akkor megint problémák következnek.
  3. Amikor kész, packagel, majd a distributionManagement tag információit felhasználva bedobja a csomagot a maven repo-ba.
    Ez nyilván csak egy sima deploy, nem release plugin spec a dolog, de el lehet tévedni. Például hogy ha scp-t használ az ember deploy-hoz, akkor kell neki egy scp. Windows felhasználóknak megint fejtörés, linuxon azért mindig ott van.
    A szervered nevére szükség van egy server bejegyzésre a settings.xml fileodban.
Kiválló lehetőségek elcsúszásra:
  1. első számú ok, hogy az SVN hozzáférésed nincs korrekten beállítva (nálam tipikusan a megbízhatatlan DNS szolgáltatás okozott bajokat régebben) és bár már módosította pom.xml-t, nem tudta bekommitolni. A dolog persze itt leáll, de nem csinálja ám vissza a változtatást. Ilyenkor futtatni kell egy svn revert-et a módosított file-okon.
  2. Ha nincs a setting.xml-ben megadva a maven repod eléréséhez a jelszó.
  3. És még egy pár dolog ami most nekem se jut eszembe :-D

Szóval a dolog legkevésbé sem golyóálló, de ha egyszer belőtted, akkor gyorsan kész lehetsz a release csomagolás unalmas feladatával, a kockázatokat és a mellékhatásokat is minimalizáltad. Ideális a release often release early gondolatvilágához. :)

Maven. Lustáknak, butáknak és nemtörődömöknek egyaránt tudom ajánlani.

A JUM-on megint nem voltam. Nagy megkönnyebbüléssel vettem tudomásul hogy nem került schedule-ra az a scrum kedvcsináló quickie, amit többen kértek tőlem, és inkáb a lemaradásaim csökkentésével foglalkoztam. Sajnos ki se látszom mostanában, például a fenti okokból.

Időközben pedig a scrum-ot kivégeztem, azaz alaposan átfaragtam a munkahelyi projectemen.

Ennyi a helyzet nálam. Boldog hétfőt, sziasztok!

2009. március 4., szerda

Néhány (majdnem) random gondolat

Mostanában kicsit elment az időm a munkámmal, ami nem túl érdekes, de persze abból is jön be valami input amit az ember összegez és eltesz későbbre. Ez jön most:
  1. Soha soha soha nem szabad elfogadni adatbázis schema-t gondos átbogarászás nélkül. A legcsúnyább dolog amikor migrálni kell az optimalizált adatszerkezetre. Előfordul ugyanis hogy valaki csv formátumban tart reláviókat. Ezzel már nem elösször szívattak meg életemben, de az előző úgy látszik túl régen volt.
  2. A beszállítókon be kell vasalni nem funkcionális követelményeket is, mint pl hogy a konfiguráció ne legyen belehegesztve a spring configba, de legalább tegyenek bele valami post processor bean-t (lehetőleg overrider-t), mert az üzemeltetők halálra szívják magukat a konfigurációk mergelésével. Ezeket a nem funkcionális követelményeket pont ugyanúgy kell kezelni mint a funkcionálisakat: ha nincs meg, akkor visszadobni. Ilyenkor kerülünk egyébként satuba a saját üzletembereink és az ellenség üzleteberei között. Még mindig jobb mint egy hét live rendszer pátyolgatás.
  3. Forráskód komentek: Soha ne írj trágár szöveget a kódba, nagyon rontja a munkahelyed imázsát amikor valaki idegen találja meg! Én most egy ilyet találtam: "Dirty hack to load the fuckers." Valójában velocity template-kről lenne szó egyébként. Nem vicces, bár nevettem rajta, de igazából azt gondoltam hogy jól kivagyok a szamócából ezekkel a srácokkal. Ugyanis engem rugdosnak az üzemeltetők ha a dirty hack mégsem működik.
    Ilyen is volt már régen, egy régi munkahelyemen valaki magyar káromkodást írt bele a logba, a német ügyfél visszaküldte a logfile-t, hogy nem érti.