• úvod
  • témata
  • události
  • tržiště
  • diskuze
  • nástěnka
  • přihlásit
    registrace
    ztracené heslo?
    SPACEANGELContinuous integration, App Deployment
    URPUTNIK
    URPUTNIK --- ---
    MUXX: vida :) tak dej vedet, rad zahodim tu obfuskaci, co jsem musel kvuli chybejicimu wildcard searchi delat
    MUXX
    MUXX --- ---
    tak to vypada ze Nexus3 ma konecne search:
    Search Improvements Available in Nexus Repository Manager 3.14
    https://blog.sonatype.com/search-improvements-coming-to-nexus-repository-manager-3
    O API se teda primo nezminuji, ale zkusim to pristi tyden asi upgradnout a vyzkouset.
    MUXX
    MUXX --- ---
    URPUTNIK: ano :)
    URPUTNIK
    URPUTNIK --- ---
    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 ..
    URPUTNIK
    URPUTNIK --- ---
    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 ..
    URPUTNIK
    URPUTNIK --- ---
    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 :)
    URPUTNIK
    URPUTNIK --- ---
    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
    MUXX --- ---
    URPUTNIK: Jasny, ale se zkompilovanyma zdrojakama se da delat spousta legrace. Proto se ptam co konkretne resis. Ja se snazim deploy resit pres plugin do jenkinsu: https://wiki.jenkins.io/display/JENKINS/Repository+Connector+Plugin
    Ten plugin vylistuje tomu kdo deployjuje dostupne releasy/snapshoty a on si vybere co a kam chce deploynout.
    Je k tomu jeste potreba nejaky shell/groovy ale co se tyka verzi, tak to mi predzvejka ten plugin.
    URPUTNIK
    URPUTNIK --- ---
    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')..
    MUXX
    MUXX --- ---
    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.
    URPUTNIK
    URPUTNIK --- ---
    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 ..
    MUXX
    MUXX --- ---
    URPUTNIK: Tvuj popis zni jako ´xy problem’. Co vlastne potrebujes vyresit za problem?
    URPUTNIK
    URPUTNIK --- ---
    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
    MUXX
    MUXX --- ---
    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.
    URPUTNIK
    URPUTNIK --- ---
    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
    MUXX --- ---
    URPUTNIK: Hlavni nevyhoda je, ze verzi webserveru definuje vyvojar a kdyz pak potrebujes upgradnout tomcat, tam musis vyreleasovat novou verzi apky. Ja treba mam pristup do kodu tak si verzi zvednu sam, ale ne vsude je to realny. Na druhou stranu jsem vzdycky delal na projektech ktery nikdy nebezely verejne, tak me stara verze tomcatu zas tak netrapila.
    URPUTNIK
    URPUTNIK --- ---
    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?
    SPACEANGEL
    SPACEANGEL --- ---
    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
    MUXX --- ---
    URPUTNIK: jo, mame pom.xml. Java JAR ma embedded tomcat a resi si frontend sam.
    S WARem nevim, protoze jsem s tim nedelal. Rekl bych ze ten JAR pak najdes v WEB-INF/lib a je na te aplikaci jak to preda do tomcatu.
    URPUTNIK
    URPUTNIK --- ---
    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 :)
    Kliknutím sem můžete změnit nastavení reklam