MUXX: vida :) tak dej vedet, rad zahodim tu obfuskaci, co jsem musel kvuli chybejicimu wildcard searchi delat

URPUTNIK: ano :)

tak zkusim zas z jineho soudku :) verzujete s branchi i maven superpomy? u vytvareni branch je pak problem, ze je potreba superpomy zbuildit explicitne jeden po druhym driv, nez clovek zacne buildit celou vetev .. ale mozna je to tim, ze se na ne odkazujem bez relativni cesty, takze se musi stahovat z nexusu ..

mimochodem, stale hledam nejaky duvody, proc prejit na embedded tomcat/jetty misto standalone tomcatu .. mate nejaky pekny tip na srovnani treba narocnosti na zdroje? asi nejvystiznejsi srovnani tomcat/jetty jsem nasel tady, kazdopadne z toho pro mne vypadlo, ze embedded tomcat/jetty jsou (uz) srovnatelne ..

a jestli embedded, nebo ne, zalezi spis od toho, kdo se vam stara o deployment ..
- standalone tomcat bude asi lip konfigurovatelnejsi na danym serveru ('vypnout, prenastavit, pustit' narozdil od 'vypnout, prenastavit, prebuildit, nahrat, pustit')
- na standalone je mozne pustit vic waru naraz, kdyby to bylo potreba (my u SOA nepotrebujem)
- v deployi bude embedded tomcat cistsi, nemusite se starat o webovy server
- zkusili jsme nejaky testovaci spusteni a tam do dokonce vypadalo, ze embedded zraly vic pameti nez standalone, ale nedelal jsem to ja, tak nevim detaily

neco by jste doplnili?

a jeste, docetl jsem se, ze tomcat v oficialni dokumentaci vyzdvihuje mod_ajp nad mod_proxy, narozdil od jetty, ktery to zminuji obracene .. co pouzivate vy? pokud tam teda mate nejaky loadbalancer ..

a treba to nekomu pomuze, na nexus 3 nezapomente poustet pravidelne ten 'compact store' task, coz je ten, ktery skutecne maze stare artefakty .. vsechny ostatni to jen oznacuji ke smazani :)

mimochodem, stava se vam, ze REST api k Nexus3 obcas funguje podivne? tim jak neumi fulltext search a navic spatne pracuji s verzema u snapshotu, tak nejdriv musim vyhledat vsechny artefakty stejneho jmena a ve vysledcich pak grepem hledam ten spravny .. a stava se mi, ze treba na prvni zavolani vrati 4 stranky vysledku (maji to API navic strankovany :/ ) ale artefakt ve spravne verzi v nich neni a o minutu pozdeji vrati jenom 2 stranky a artefakt tam je ..

MUXX: asi nerozumim :) snazime se o kontinualni integraci a drzet 'build once, run/deploy everywhere', tzn jednou se sestavi a kdyz projdou testy, sype se to do nexusu. Deploy na libovolny prostredi si pak taha posledni verzi z nexusu. Ten kdo je zodpovedny za deploy nic nemusi vedet o buildu a naopak. Ze pouzivame snapshoty misto tagovany verze je nase zjednoduseni, master je stabilni vetev deploynutelna kdykoli a ma tak ma stale stejnou snapshot verzi (vyvijime interni system, takze nepotrebujem 'verzovat')..

URPUTNIK: No ale co resis za problem? Deploy starsich snapshotu do environmentu? Ja se na to vykaslal protoze build bez testu mi na environmentu trva o 20 vterin dyl nez kdyz to budu tahat z nexusu. Takze stahovani finalniho buildu z nexusu nemelo nikdy prioritu k predelani. Zavislosti se tahaji pres maven a npm.

MUXX: zajimalo mne jak stahujete vybuildene zdrojaky z nexusu3 .. protoze maven-dependency-plugin zabere jenom na javovy zdrojaky (nebo bych musel napriklad i do javascript buildu cpat pom.xml) .. a primou url na build poskladat nemuzu (viz gist), protoze pouzivame jenom snapshoty .. kazdopadne jsem to uz vyresil, skutecne jsem to zavolal krz to jejich search api z shellu (vytahnout vsechny, seradit podle buildu, vzit nejnovejsi) .. a nastesti nemusim resit strankovani, drzime jenom 2 posledni snapshoty od kazdy verze ..

URPUTNIK: Tvuj popis zni jako ´xy problem’. Co vlastne potrebujes vyresit za problem?

tak jsme optimisticky upgradovali nexus z 2.x na 3.13 (no dobre, zkolaboval nam fs a prislo nam to rychlejsi, nez obnovovat x hodin) .. vicemene vsechno funguje jako fungovalo, ALE narazili jsme na stahovani artefaktu z nexusu .. pac ten REST co mela v2 uz neni, je tam nejakej novej, kterej ma dost nesikovne api a neni to neco, co bych chtel ovladat z shellu .. pres co to stahujete vy? jeste zkoumame variantu s maven-dependency-plugin, pac tenhle gist nefunguje (metadata.xml neobsahuje timestamp a build number) .. mozna je to tim, ze uploadujeme snapshoty

URPUTNIK: No zacni asi u toho kdo ty logy bude cist a v jakym jsou stavu. Ja loguju lokalne do souboru, do graylogu, do SpringBoot Admina a ve vysledku jsem zjistil, ze ty logy stejne nikdo moc necte :) zvlast kdyz tam co minutu vyskoci nejaky error nebo exception.

rozpadam stavajici deployment tam, kde ted mame v jednom tomcatu vic bezicich aplikaci .. diky tomu ale ted vsechny zapisujou do jednoho log souboru .. jak vlastne zachazite s logy? ono to ma pak presah na virtualizaci, kde si taky nejsem jist, co s nima budu delat, kdyz se bude poustet vic instanci neceho .. 12factor to doporucuje sypat vsechno na stdout, jejich zachytavani pak bude zalezitosti prostredi, nikoli aplikace .. takze, jak to mate vy?

MUXX: ok, to mi asi staci a chapu :) dekuji ..

mimochodem, vsichni pouzivate embedded AS? my z nejakyho duvodu ne, toho se budu muset dopatrat, maji embedded nejake nevyhody? tipuju napriklad ze jsou mene konfigurovatelne?

tak php build muze bejt cela masinerie kroku - od composeru, pres vytvoreni pharu, az po operace nad frontend casti aplikace (vsechny ty gulpy, grunty a dalsi veci kterejm nerozumim)...

MUXX: coz znamena ze mate ve frontendovych zdrojacich pom.xml, ne?

a tomuhle asi porad nerozumim "Javova aplikace si pak stahne JAR a da si ho na classpath a dal s tim pracuje" .. chapu ze si na to jina javova aplikace udela maven dependency, takze se pri buildu pribali treba do waru .. ale neni mi jasny, jak se takhle pribaleny zdrojaky daji pouzit po deploymentu toho waru :)