DWICH: u nas delame ze testy bezi pouze na feature-branch (v docker image), pokud projdou, tak je mozno branch merge do master, a na masteru je uz jina build procedura bez testu, ktera vyplivne doker image obsahujici kod z masteru.
jinymi slovy, je jina build procedura pro CI build (s testy) a finalni build

DWICH: Best practice je urcite to co popisujes. Ze pokud projdou testy, tak se build resp. docker image oznaci jako OK.

Musi ty testovaci data nebo dalsi veci obsahovat ten image nebo muzes vzit image a do nej tyhle veci nahrat a pustit testy, pripadne vytvorit testovaci image, ktery bude dedit z toho buildnuteho?

Zdravíčko vespolek, dotaz ohledně best practices. Píšeme kód v pythonu, řekněme knihovny a aplikace. Ty chceme průběžně testovat po každém commitu, proto máme docker image s verzí pythonu 3.6 a 3.7. Používáme Bitbucket Pipelines, po commitu se kód automaticky nahraje do docker image, tam se spustí testy, a to pro verzi py36 a v dalším docker image pro verzi py37. Vývojář hnedka ví výsledek.

Každá knihovna nebo appka může mít seznam závislostí v requirements.txt, které se instalují během testu. Během testu se nebuildí docker image s tou appkou, jen se doinstalují závislosti, spustí testy a zjistí výsledek.

Když test projde, tak víme, že ta appka neobsahuje chyby a že je schopna běžet v tom obecném docker image. Kdybychom ji chtěli nasadit, tak ji buildneme jako docker image a mělo (!) by to fungovat. Jenže během toho buildu na míru se může něco stát jinak a už to není úplně bezpečný.

Přijde mi lepší, když se vybuildí docker image přímo s tou aplikací, s tou konkrétní verzí. Pak se spustí testy a když testy projdou, tak se ten buildnutej image označí za OK a může se později nasadit, nic na něm se už měnit nebude.

Ale i tady cejtím pár nevýhod - pro testy ta knihovna/aplikace může potřebovat nějaký testovací data nebo další věci, který nejsou potřebný pro provoz - pro provoz stačí opravdu jen kód. A tyhle věci navíc by zbytečně byly součástí toho docker image nebo by se po testech musely z toho docker image nějak mazat (?)

Tak jsem se chtěl zeptat, jak tohle řešíte. Díky!

MUXX: jak to dopadlo?

a z jineho soudku, poskladal jsem par dotazu na rozhrani docker/CI, zatim v docker klubu .. ocenim kdyz odpovite tam, at to nemusim kopirovat :) [ URPUTNIK @ Docker a kontejnery ]

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?