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":
- 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. - Lefuttatja a teszteket.
- 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.
- Á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é.
- 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. - 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. - 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.
- 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.
- Ha nincs a setting.xml-ben megadva a maven repod eléréséhez a jelszó.
- É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!