Co bych rád slyšel v září na CZJUG

22. 8. 2007

Tento post je tak trochu věnován Petru Ferschmannovi ze SoftEU, který bude mít 19. září 2007 přednášku na téma praktické nasazení Mavenu na CZJUGu. Jelikož vím, že občas na můj blog zamíří (doufám že pravidelně :-) ), věřím, že na článek zareaguje a kdo ví - třeba na moje otázky v září odpoví.

Problémy s maven-release-plugin

Vycházím z praktické zkušenosti (cca 3/4 roku staré tedy), kdy jsem se snažil použít maven-release-plugin pro vydávání verzi v multiprojektu. Typicky mám parent pom.xml v nadřízené složce, a pom.xml jednotlivých modulů ve složkách o úroveň níže (obdobný problém jsem ale měl i pokud jsem parent umístil také do složky druhé úrovně, myslím). Při použití maven-release-pluginu na parent projektu bych čekal, že správně releasne jak hlavní projekt, tak všechny moduly v něm registrované. Problém je v tom, že plugin všechny zdrojáky zataguje ve VCS a následně si je vycheckoutuje pod tímto tagem do složky "target". Po vycheckoutování mu ale nesedí relativní cesty k pom.xml jednotlivých modulů a celé to vyhoří. Jediným způsobem, jak plugin použít, pro mne bylo spouštět postupně releasy na všech modulech projektu, což bylo velmi nekomfortní. Dále mě na celém tomto způsobu vadilo, že v celém release procesu jsou spouštěny např. testy 2x - přitom by přeci stačilo je spustit jen jednou. Navíc parametry, se kterým se spustil daný release se posléze nepřenesly do buildování již té vycheckoutované verze - mám ten dojem, že plugin si interně spouští úplně novou instanci mavenu na zbuildování vycheckoutované verze.

Existuje nějaký lepší plugin (i když zmíněný plugin patří mezi ty "oficiální", mavenovské pluginy)? Nebo jak správně sestavit strukturu pomů a používat release plugin tak, aby pracoval dle očekávání i v multiproject použití?

Stanovení jednotné verze pro modul s potomky

Co řeším velmi často je opravdu jednoduchá věc a zatím jsem nenašel žádné elegantní řešení. Pokud mám multiprojekt, rád bych vedl verzi jen na úrovni parent projektu a při jeho buildu by všechny moduly tohoto projektu byly vydané pod touto verzí. Problém je v zápise a odkazování, které maven používá. Aby se informace z verze mohla zdědit, musí se všichni potomci odkázat na svého parenta - ovšem musí uvést verzi tohoto parenta. Takže jakmile změním verzi v parent projektu, tak bych musel ve všech modulech změnit i prolinkování na tu správnou "novou" verzi parenta aby se verze mohla pro build změnit - prostě deadlock jako vyšitej.

Řešil jsem to pomocí property souboru, který parent používal (moduly díky dědičnosti také) - takže jsem verzi mohl mít jen v něm. Bohužel s takto zapsanou verzí nedokáže pracovat Artifactory, takže jsem tuto cestu musel opustit. Ono je to také dost nestandardní - když potom kouknete do pomu, tak tam tu verzi nenajdete, což není zrovna ideální stav.

Prohledal jsem web i pár elektronických knih o Mavenu, ale nějak jsem řešení tohoto problému nenašel. Možná to je hloupost, ale opravdu to otravuje život ;-) .

Nasazení firemní repository - proxy veřejných repository

Obvykle každá firma řeší problém vlastní repository a velmi rychle i nasazení nějaké proxy, která centralizuje pro všechny vývojáře přístup ke knihovnám třetích stran. Rozhodně by byly zajímavé zkušenosti z této oblasti. Konkrétně třebas:

s jakými proxy máte zkušenosti, která by se dala doporučit?
jak řešíte deploy knihoven třetích stran, které nejsou ve veřejných repository (třeba u Artifactory je to poměrně snadné, ale u Maven-proxy od Codehaus už to byl trochu problém)?
oddělujete v repository SNAPSHOT a "ostré" verze knihoven? jak potom řešíte nastavení distributionManagement pro tyto různé druhy repository - vše přes profily?

CI, Night buildy

Jelikož se má přednáška týkat i CI, zajímavá informace by byla i o struktuře build konfigurací a jejich skladbě. Mám tím na mysli, jestli při každé změně ve VCS se okamžitě spouští kompilace i testy. Nebo jen kompilace a testy jen v definovaných intervalech (např. každou hodinu). Jestli a jakým způsobem řeší vytváření night buildů a jestli je cílem těchto night buildů pouze vyrobení artefaktů, nebo i instalace na nějaký testovací server (tady ale narážíme na problém PermGenSpace).

Zajímavé by bylo i porovnání a zkušenosti různých CI serverů - myslím tím z hlediska praxe a nikoliv z oficiálních zdrojů.

Výkonnostní testy

Jaké mají zkušenosti s automatickými testy výkonnosti aplikace - jak řeší např. problém spouštění testů na různě výkonných serverech nebo v různých časech (někdy může být stejný server vytížen více a někdy méně - pokud nemáme dedikovaný server jen na výkonnostní testy).

*) výkonnostními testy jsou myšleny testy, které např. odpovídají QOS pro danou web aplikaci a měly by garantovat, že postupným vývojem projektu se nepřekročí stanovené limity odezev

Web testy

Jak řešíte spouštění automatických web testů, které potřebují pro svůj běh nainstalovanou a zprovozněnou aplikaci na web serveru? Součástí buildu by potom musela být nejprve automatická instalace na server a pak teprve spuštění automatizovaných web testů. Vždy mne od tohoto záměru odradila představa potenciální "chybovosti" tohoto procesu. Řešili jste třebas toto?

Praktické nasazení

S jakými praktickými problémy jste se při nasazení setkali? Na co si vaši vývojáři, kteří na něco takového nebyli před tím zvyklí stěžovali a jak jste jejich výtky překonali? Byli třeba nějaké slepé větve, které jste s postupem času opustili?

Výzva ostatním

Možná vás tohoto článku při čtení otázek a problémů, které trápí mne, napadnou i další - z vaší vlastní vlastní praxe. Uvítám, pokud se s nimi o ně podělíte a napíšete je do komentářů k tomuto článku. Myslím, že rozhodně není od věci, zkusit apelovat na řečníka, aby ve své přednášce probral i otázky, které nás pálí.

Komentáře

Novoj 28.8.2007 20:20

Díky - přesně stejný postup jsem zkoušel před necelým rokem a neprocházel mi - je možné, že v té době byl release plugin ještě v ranějším stádiu s chybkami.

Věnoval jsem zopakování postupu asi hodinku a nějak jsem se zasekl na použití maven SCM pluginu - potřebuji z Windows komunikovat s CVS přes SSH s použitím privátního klíče. Což není zase až taková trivka, jak jsem si nejdříve myslel.

Napojení na CVS je must-have precondition pro maven-release-plugin, takže než rozlousknu tohle, tak si to neozkouším. Škoda, že teď zrovna nemám moc času :(.

Každopádně 3rojko, díky za reakci a článek.

3rojka 28.8.2007 19:22

Našel jsem si chvíli na vyzkoušení a něco jsem o tom naspal http://blog.3rojka.com/index.php/2007/08/28/maven-release-plugin-in-action/

Novoj 24.8.2007 08:25

No měl jsem dojem, že problém je v deklaraci toho parent pom.xml. Tam mám v deklaraci dejme tomu dva moduly:

<modules> <module>test1</module> <module>test2</module> </modules>

Maven očekává, že najde pom.xml pro tyto dva moduly v podložkách test1 + test2 složky, kde se nachází parent pom.xml. Pokud bych chtěl mít modul na stejné úrovni jako je složka parent pom.xml musel bych uvést:

<modules> <module>test1</module> <module>test2</module> <module>../test3</module> </modules>

Problém toho maven-release-pluginu byl myslím (pozor toto jsou vzpomínky půl roku staré) v tom, že po checkoutu do složky target, resolvoval plugin cesty vztažené k parent pom.xml ve “vývojové” složce a ne ve složce “target”, kam si to celé vycheckoutoval. A na tom to myslím vyhořelo. A to i v případě, že ty moduly byly v podsložkách jako v prvním příkladě, co jsem uvedl (tedy žádné používání ../ v cestě a podobné hrůznosti).

Petr Ferschmann 24.8.2007 06:40

Zdravím, vycházel jsem z textu “Po vycheckoutování mu ale nesedí relativní cesty k pom.xml jednotlivých modulů a celé to vyhoří.”.

Maven v každém podprojektu vycheckoutuje do podadresáře target/checkout jen a pouze ten podprojekt.

Takže moje otázka zní: byla v to pom.xml Ještě další závislost mezi jednotlivými pom.xml (např. pomocí relativePath - s tím jsem se setkal) a nebo to Maven nezvládl sám o sobě? (a s tím už jsem se nesetkal :-)

Honza Novotný 23.8.2007 17:27

To že multiprojekt = více projektů a co z toho vyplývá, si myslím, že jsem pochopil. Nemám s tímhle žádný problém. Chyba je (nebo třeba už je to opraveno) v tom maven-release-pluginu - ten je na adresářové struktuře závislý právě díky tomu, že se to checkoutuje z VCS (nebo si to alespoň myslím). Nebyl jsem schopný vydat hromadně release, pokud jsem spustil goaly na parent projektu - první (přípravná) fáze proběhla, ale když jsem spustil druhou, kde se provádí checkout do target složky mi to celé failnulo na tom, že se maven snažil volat release:perform někde, kde ty moduly vycheckoutované nebyly. Když jsem to volal jednotlivě pro každý modul, tak to samozřejmě fungovalo - ale bylo to pracné.

To byl stav před půl rokem - je možné že s tím pluginem za tu dobu už pohnuli. Dám si domácí úkol a prověřím to, abych tady nedělal vlny zbytečně.

Petr Ferschmann 23.8.2007 16:26

Ještě doplním, že continuum to může nahrát do repository až po tom, co je prošli testy.

A pokud máte několik projektů s různými životními cykly (jak knihovny třetích stran tak ve vlastní firmě - např. “úžasný” framework) tak je toto řešení celkem příjemné a dobré.

Dříve jsme obvykle měli buď vše v jednom repository SVN/CVS a pokud něco bylo sdílené mezi více projekty byl to problém. Případně se prostě do projektu nahrál až výsledný JAR.

Petr Ferschmann 23.8.2007 16:20

Zdravím,

tak tedy zkusím trošku popostrčit správným směrem :-)

Platí základní pravidlo “U Mavenu se multiprojekt skládá z více projektů”. To ale znamená, že mohu vycheckoutovat jen podadresář a přesto budu schopný projekt přeložit. Takže není něco jako adresář výš.

Myšlenka je taková, že máte větší projekt a continuum vám pravidelně vše kompiluje a nahrává do vaší lokální snapshot repository. A vy buildíte všechno vůči ní. Když mi tohle došlo, tak mi téměř vše v Mavenu začalo fungovat :-)

Neříkám, že toto je jediné a ideální řešení (pro mně to byla docela změna způsobu myšlení), ale dá se s tím celkem dobře sžít a teď už mi to ani nepřijde zvláštní.

Honza Novotný 23.8.2007 11:55

No problém spočívá v tom, že se mi nikdy nepodařilo rozjet (pravda, je to asi půl roku, co jsem to zkoušel naposledy) maven-release-plugin pro multiproject. Po checkoutu se rozjely nějak cesty a build failnul. Jinak si myslím, že pak by stačilo jen dát všem modulům i parentu v úvodu stejnou verzi a release plugin by se postaral o náležité zvednutí verze všech artefaktů. Ale to taky vařím z vody, protože jak říkám - v praxi se mi to nezadařilo.

3rojka 23.8.2007 11:19

Ohledně toho jednotného verzovaní, nemám to vyzkoušené protože na to stále jaksi nezbyl čas, ale kdy jsem si stím hrál a myslím že by to šlo udělat nějak tahkle. Nazveme naší devel verzi DEVEL-SNAPSHOT a všechny potomky potom odkazují na DEVEL-SNAPSHOT parenta, o verzovaní se potom postará release plugin, který nahrazí SNAPSHOT release verzí. Jako následující verzi potom zase musíme zadat DEVEL-SNAPSHOT, tím odbouráme nutnost přečíslovávat verze paranta i jeho potomků a všechno verzování se odahrává pouze na releasu. Možná že blafu ale myslím že by to takhle nějak šlo, ale jak říkám nikdy jsem to neodzkoušel.

Novoj 23.8.2007 08:22

Záznamy obvykle bývají - jen mají asi měsíční zpoždění (jak kdy). Za první rok CZJUGu (do prázdnin) jsou myslím už všechny. Já to mám naštěstí “jen” 1,5 hodiny z Pardubic.

Jirka 23.8.2007 07:57

Pokud by byl záznam CZJUGu i na videu bylo by to super. ( Nejsu z Prahy - 5 hodin vlakem… :-( )

Jirka

Petr Ferschmann 22.8.2007 18:08

Zdravím,

přesně na tato témata (a i další) chci ve své přednášce odpovědět. Takže děkuji za hozenou rukavici :-) Odpověď si, ale nechám až na svoji přednášku - přijďte jste zváni.

Petr Ferschmann