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 :)

MUXX: " js zabali do jaru a da do nexusu" .. takze vas JS je soucasti frontendu dane javove aplikace (tzn balite to do waru), nebo ho jenom zazipujes (a tak defakto vyrobis jar)?

a to 'da do nexusu' je pres

mvn deploy:deploy-file

, jako zpusob jak to nevolat pres Nexus REST api?

a uz vubec netusim, co myslis tim "java aplikace to pak pouzije jako zavislost" :)

URPUTNIK: npm repository mi dava smysl, ale vlastne nevim, co musi projekt splnovat, abych ho tam spravne nahral (kdyz koukam do node_modules, tak vypada kazdy trosku jinak .. ) .. tip na nejaky hezky navod?

ja potrebuju nekde drzet vysledek buildu, pro ruzne verze .. a staci mi vzdy jen nejnovejsi build pro danou verzi .. a ten vysledek buildu nebude mit zavislosti na nicem jinem, to je kompletni samonosna aplikace, nejak jsem cekal, ze npm zacne mit smysl, az kdybych mel zavislosti na neco dalsiho ..

MUXX: sypete vysledek js buildu do docker repository? jako vcetne celeho docker image? tam my jeste nejsme :) zatim mame jenom vysledek buildu ..

ad php - samozrejme nekompiluje, defakto je to jenom zazipovani konkretnich zdrojaku tak, aby to po rozbaleni na virtual s nastavenym apachem fungovalo

URPUTNIK: Docker? Npm? Php se nejak kompiluje?

URPUTNIK: gradle + artifactory? :)

mimochodem, pokud v ramci CI buildite nejavovy zdrojaky, do jakyho repozitare sypete vysledky, co se budou deployovat? ja je sypu do nexusu a vyrabim jim imaginarni pom, ale mozna existuje nejaky elegantnejsi zpusob :) jde mi o php, angular a react ..

URPUTNIK: tak je ma to tam co driv (jenkins/job/[job name]/config.xml), meli jsme nakopnuty FS a normalne tam mizely soubory ..

asi jsem slepej, kde ma prosim vas novejsi jenkins ulozeny konfigrace jednotlivych jobu? nachazim vsude jenom na priklady pres groovy/dsl verzi, tu my ale nepouzivame :/ a historicke jenkins/job/[jobnam]/config.xml neexistuje ..

URPUTNIK: Rekl bych, ze idealni bude nejaka stredni cesta :-)).

URPUTNIK: k tomu me napada, nemate nejaky oblibeny navod/video/priklad/skoleni na razeni/pipeline jobu v jenkinsu? videl jsem to jednou pres rameno pouzity, ale nikdy jsem to nenastavoval .. tak ze bych si mohl usetrit nejaky skrabani na hlave

a druhy, obecnejsi, dotaz - na strategii, osvedcuje se vam delat elementarnejsi joby, ktery se navzajem pousti, nez delat 1 velky?

historicky jsem napriklad meli maven job pro kazdy artefakt, ale byl v tom strasnej chaos, kdyz jsem zacali zvedat/tagovat jednolivy komponenty .. takze jsem to zjednodusili a napriklad cely workspace drzi jednu verzi, kdyz se dela branche, tak se dela branche vseho, takze 1 job na 'git brach' .. na druhou stranu mame taky checkout joby co pousti hotovy aplikace na server, ktery ale v sobe zase schovavaj ovladani tomcatu, jbosse, apache, apod .. uz je to dost neudrzitelny, tak se zas klonim k tomu, ze bych to rozpadnul :)

a do toho se nam blizi zavedeni virtualizace, coz treba bude znamenat vyrabet exekutory kdyz budou potreba ..