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

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í.