• úvod
  • témata
  • události
  • tržiště
  • diskuze
  • nástěnka
  • přihlásit
    registrace
    ztracené heslo?
    SPACEANGELContinuous integration, App Deployment
    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 :)
    MUXX
    MUXX --- ---
    jj, pres maven + frontend-maven-plugin balime do JARu, ten jde do Nexusu. Javova aplikace si pak stahne JAR a da si ho na classpath a dal s tim pracuje. Je to asi slozity, ale funguje to. Konkretne "da do nexusu" se dela pres maven-release-plugin, protoze na tomhle projektu se jednou mikroreleasy. Snapshoty se nepouzvaji (netusim proc, jeste jsem nemel silu do toho vrtat).
    URPUTNIK
    URPUTNIK --- ---
    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" :)
    MUXX
    MUXX --- ---
    URPUTNIK: Docker minimalne. Jenom tam, kde se to skutecne vyuzije. Jinak se vetsinou js zabali do jaru a da do nexusu. Java aplikace to pak pouzije jako zavislost. Zalezi co s tim pak chces dal delat.
    Vetsinou to mame tak, ze se kompiluje vzdy s kazdym novym deployem. Dokud stiha jenkins tak neni priorita to menit...
    URPUTNIK
    URPUTNIK --- ---
    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 ..
    URPUTNIK
    URPUTNIK --- ---
    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
    MUXX
    MUXX --- ---
    URPUTNIK: Docker? Npm? Php se nejak kompiluje?
    URPUTNIK
    URPUTNIK --- ---
    URPUTNIK: gradle + artifactory? :)
    Kliknutím sem můžete změnit nastavení reklam