abclinuxu.cz AbcLinuxu.cz itbiz.cz ITBiz.cz HDmag.cz HDmag.cz abcprace.cz AbcPráce.cz
AbcLinuxu hledá autory!
Inzerujte na AbcPráce.cz od 950 Kč
Rozšířené hledání
×
eParkomat, startup z ČR, postoupil mezi finalisty evropského akcelerátoru ChallengeUp!
Robot na pivo mu otevřel dveře k opravdovému byznysu
Internet věcí: Propojený svět? Už se to blíží...
24.6. 16:16 | Nová verze

Eclipse Foundation oznámila vydání nové verze vývojového prostředí Eclipse. Eclipse 4.6 s kódovým označením Neon vychází rok po vydání verze 4.5 s kódovým označením Mars (zprávička) a přináší celou řadu novinek. Jejich představení také na YouTube.

Ladislav Hagara | Komentářů: 1
24.6. 10:38 | Nová verze

Vyšel oVirt 4.0, open source virtualizační rozhraní pro KVM. Novinek je opravdu hodně, namátkou třeba vylepšená live migrace, nový administrační portál (Cockpit), vylepšená práce s libvirt obrazy, podpora Atomic guest OS, vylepšené API (vylepšený výkon + přibylo sdk pro ruby), hotplug SR-IOV vNIC u spuštěné VM. Kompletní seznam změn viz : release notes.

Max | Komentářů: 0
24.6. 00:11 | Nová verze

Po 8 měsících od vydání verze 4.6 byla vydána verze 4.7 virtualizačního softwaru Xen. Z novinek lze zmínit například Live Patching. Podrobnosti v poznámkách k vydání, přehledu nových vlastností a porovnání s předchozími verzemi.

Ladislav Hagara | Komentářů: 0
23.6. 21:00 | Komunita

Otevřená certifikační autorita Let's Encrypt informuje, že musí bránit název Let's Encrypt. Comodo Group se snaží registrovat ochranné známky Let’s Encrypt, Let’s Encrypt With Comodo a Comodo Let’s Encrypt. Žádosti byly podány v říjnu 2015. Certifikační autorita Let's Encrypt byla představena v listopadu 2014 (zprávička).

Ladislav Hagara | Komentářů: 5
23.6. 18:48 | Zajímavý článek

HackerBoards.com (ještě nedávno LinuxGizmos.com) zveřejnil výsledky čtenářské ankety o nejoblíbenější jednodeskový počítač (SBC) v roce 2016. Letos se vybíralo z 81 jednodeskových počítačů (pdf) (vloni to bylo 53, předloni 32). Nejoblíbenějšími jednodeskovými počítači v letošním roce jsou Raspberry Pi 3 Model B, Odroid-C2 a BeagleBone Black.

Ladislav Hagara | Komentářů: 0
23.6. 17:06 | Zajímavý projekt

Indiegogo kampaň na rozšiřující desku pro použití Raspberry Pi v průmyslových aplikacích - Monarco HAT - se blíží ke konci. Vybralo se zatím 92 % z cílových 10 000 EUR a do konce zbývají už jen 4 dny. … více »

VSi | Komentářů: 1
23.6. 13:53 | Zajímavý projekt

Jedním z cílů otevřené certifikační autority Let's Encrypt je zcela nahradit HTTP protokolem HTTPS. V příspěvku na blogu autority je hodnocen dosavadní stav. Při spuštění veřejné bety v prosinci 2015 (zprávička) bylo pomocí HTTPS stahováno 39,5 % webových stránek (měřeno pomocí Firefox Telemetry). Dnes je to 45 %. Certifikační autorita Let's Encrypt vydala od prosince více než 5 milionů certifikátů. Aktivních je 3,8 milionu certifikátů. Chráněno pomocí Let's Encrypt je více než 7 milionů unikátních domén.

Ladislav Hagara | Komentářů: 12
23.6. 00:11 | Komunita

Mozilla na svém blogu informuje, že z fondu Mission Partners, jenž je součásti programu Mozilla Open Source Support (MOSS), bylo uvolněno 385 000 dolarů. Tyto peníze byly rozděleny mezi 8 projektů: Tor, Tails, Caddy, Mio, DNSSEC/DANE Chain Stapling, Godot Engine, PeARS a NVDA.

Ladislav Hagara | Komentářů: 0
22.6. 23:32 | Zajímavý článek

Anwesha Das v článku Software Licenses in Fedora Ecosystem na svých stránkách informuje o přehledu použitých softwarových licencí a četnosti jejich použití ve Fedoře. Počet použitých licencí je 267. Nejčastěji použitá licence je MIT před GPL a BSD.

Ladislav Hagara | Komentářů: 0
22.6. 17:26 | Komunita

V Norimberku probíhá openSUSE Conference 2016 (oSC16). Na programu je řada zajímavých přednášek. Sledovat je lze také online.

Ladislav Hagara | Komentářů: 0
Jaký poměr stran pracovní plochy (příp. složené z více monitorů) preferujete?
 (7%)
 (13%)
 (52%)
 (20%)
 (4%)
 (2%)
 (1%)
Celkem 518 hlasů
 Komentářů: 30, poslední 11.6. 16:07
    Rozcestník
    Reklama

    Kontinuální integrace s Jenkins CI

    31.7.2011 02:44 | Přečteno: 15946× | Výběrový blog | poslední úprava: 31.7.2011 02:44

    Kontinuální integrace je stále více používaná technika pri vývoji aplikací, ale česky psaných článků na toto téma jsem zatím příliš neviděl. Jen víceméně neurčité narážky jako např. (citováno z článku Pár triviálních poznámek k vývoji aplikací) „Kontinuální integrace“ (Continuous integration) a „kontinuální –trvale udržitelné nasazení“ (Continuous delivery), na které narážím v dalším bodě, jsou pojmy, které se v poslední době často skloňují, a protože nemáme na jejich podrobné rozpracování prostor, dovolte, abych se vás zeptal: „Vy skutečně ještě nemáte svůj build server? A to přesto, že ho můžete často získat i zdarma a za vyzkoušení, jak určitě víte, nic nedáte?“. Rád bych tuto mezeru aspoň z části vyplnil.

    Kontinuální integrace

    Kontinuální integrace (CI) spočívá v častém kompilování zdrojového kódu projektu, obvykle následovaném spuštěním testů. Z tohoto důvodu je kontinuální integrace často zmiňována v souvislosti s technikami extrémního programování a test driven development. Při použití těchto technik vývoje má kontinuální integrace asi největší význam, nicméně i když vyvíjite jinými způsoby (případně ani netušíte nic o různých metodách vývoje :-) ), kontinuální integrace může být užitečná i pro vás. Při práci na nějakém projektu obvykle dříve či později vyzkoušíte, zda vámi provedené změny nezpůsobily problémy při kompilaci a zda skutečně dělají to, co chcete (ideálně tak, že na napíšete test). Před odeslání změn do verzovacího systému je potřeba zjistit, zda vaši kolegové, kteří pracují na tomtéž projektu, v mezičase neprovedli nějaké změny, které kolidují s těmi vašemi. Pokud dojde ke konfliktům, je třeba provést další změny, konflikty odstranit a následně změny odeslat do repozitáře. Pravděpodobnost těchto konfliktů a jejich složitost pochopitelně závisí na tom, jak často tento proces absolvujete - čím je tento interval delší, tím větší pravděpodobnost (za predpokladu, že každý vývojář nepracuje na submodulu, který je zcela oddělen od ostatních - což v reálu není přiliš časté), že dojde ke konfliktům a jejich integrace, případně hledání přičiny problémů, bude složitěší. Tato uváha nás dovede k závěru, že patrně bude nejjednodušší odesílat nejmenší možnou ucelenou změnu (tj. odesílat změny co nejčastěji) a poté spustit kompilaci zdrojového kódu a testy. Toto je princip kontinuální integrace. Kontinuální integrace by měla vést k tomu, že případné problémy jsou odhaleny v co nejkratším čase po odeslání změn, takže identifikace příčiny problému by měla být relativně snadná a rychlá. Stejně tak ostatní vývojaři mohou snadno zjistit, v jakém stavu je aktuálně zdrojový kód, místo toho, aby akceptovaly změny od ostatních vývojářů a pak řešili, zda za problémy mohou jejich změny nebo změny někoho jiného, které si stáhli při aktualizaci. Kromě kompilace a spuštění testů můžeme využít i dalších nástrojů, např. pro analýzu zdrojového kódu, jako třeba FindBugs, PDM, Checkstyle, generování dokumentace atd.

    Kontinuální integrace pochopitelně přínáší i dodatečné náklady, zejména na pořízení HW na kterém CI server běží a počáteční úsilí, kdy je potřeba nakonfigurovat pro každý projekt jeden (případně víc) uloh, které definují jak se má projekt kompilovat a pod. Nicméně tyto náklady jsou obvykle zdaleka preváženy výhodami, které kontinuální integrace prináší.

    Jenkins CI

    Úvod

    Patrně nejznámějším a nejvíc používaným(*) CI serverem je Jenkins. Server je napsaný v Javě a původně byl určen rovněž pro kontinuální integraci projektů napsaných v Javě. Pochopitelně tedy obsahuje velmi silnou podporu nástrojů určených pro projekty napsané v Javě, nicméně je možné jej bez problémů použít i pro projekty v jiných jazycích. S růstem popularity (jak kontinuální integrace, tak Jenkins CI) roste i počet pluginů, které podporují nástroje určené pro jiné jazyky než Java. Toto je ostatně jedna z velkých výhod Jenkins CI oproti jiným CI serverům - komunita vývojářů (projekt je pochopitelně open source) je veliká a velmi aktivní (projekt má v tuto chvíli na githubu 112 vývojářů a obsahuje 555 repozitářů), v nabídce několika set pluginů lze najít plugin pro kde co a stejně tak na mailing listu obvykle dostanete odpověd velmi rychle. Projekt je primárně určen pro malá nasazení (několik projektů a několik vývojářů), nicmé lze jej s úspěchem použít i pro obrovské nasazení (stovky/tisíce projektů, jedno z větších veřejných nasazení je např. build server ASF).

    (*) Podle průzkumu společnosti Sonatype 83% respondentů používá kontinuální integraci a z nich 71,5% používá (tehdy ještě) Hudson.

    Malá odbočka do historie aneb Hudson

    Projekt byl původně vyvíjen pod názvem Hudson Kohsukem Kawaguchim, toho času zaměstnancem Sunu. Vývoj byl rovněž Sunem částečne podporován. Téměř ihned po akvizici Sunu Oraclem Kohsuke z Oraclu odešel a postupně začalo docházet menším či větším konfliktům mezi komunitou a Oraclem, které nakonec výustily v roztržku velkou. O co presně ve skutečnosti šlo nevím (situace nebyla IMHO moc prehledná a navíc některá jednání neprobíhala veřejně). Oficiálně šlo o to, aby Oracle daroval jméno a logo Hudsonu komunitě, což Oracle kategoriky odmítnul a tak došlo k hlasování, kde komunita drtivou většinou rozhodla, že se projekt přejmenuje na Jenkins (k tomuto došlo cca před půl rokem). Hudson je nadále vyvíjen Oraclem (a dále zejména společností Sonatype), nicméně drtivá většina vývojářů a komunity vyvíji a používá Jenkins. Tuto odbočku považuji za důležitou zejména z toho důvodu, že starší články zmiňují a odkazí na Hudson, přičemž je ale míněm Hudson před přejmenováním, tedy vpodstatě Jenkins. Perlička na závěr této odbočky: poté, co Oracle vcelku nekompromisně odmítnul převedení projektu pod nejakou OSS nadaci, před nějakým časem Oracle rozhodnul, že projekt převede pod Eclipse foundation a ještě měli zástupci Oracle tu drzost tvrdit, že toto nabízeli (veřejně) od začátku.

    Instalace

    Na stránkách projektu naleznete buď instalační balíček nebo návod jak Jenkins nainstalovat ve vaší oblíbené distribuci. Pokud nenaleznete, můžete si stánout war (web archiv) a ten pak spustit zcela jenoduše pomocí

    java -jar jenkins.war
    
    Jenkins je webová aplikace. Obsahuje v sobě minimalistický servlet kontejner Winstone (resp. svuj vlastni fork toho projektu), který spustí a na něm pak spustí samotný Jenkins. Běžící Jenkins pak naleznete na http://localhost:8080. Pokud vám Winsotne přijde příliš obskurní a nedůvěryhodný, mužete Jenkins pochopitelně spustit na Tomcatu nebo jakémkoli jiném servlet kontejneru. Všechny potřebné soubory pak Jenkins bude ukáladat v ~/.jenkins, kde ~ je domovký adresář uživatele, pod kterým je servlet kontejner spuštěn. Tato výchozí volba se asi většíně uživatelů líbit nebude a lze ji změnit nastavením proměnné prostředí JENKINS_HOME.

    V případě, že Jenkins nainstalujete z baličku, bude Jenkins startovat na Winstone. Na Fedoře je instalace následující:

    wget /etc/yum.repos.d/jenkins.repo http://pkg.jenkins-ci.org/redhat/jenkins.repo
    rpm --import http://pkg.jenkins-ci.org/redhat/jenkins-ci.org.key
    yum install jenkins
    
    Po instalaci by měl být vytvořen nový uživatel jenkins. Hlavni konfigurační soubor naleznete v /etc/sysconfig/jenkins.conf a potřebné soubory si Jenkins bude ukládat do /usr/lib/jenkins.

    Vývojový cyklus je velmi rychlý, nový release se vydává obvykle jednou týdně (viz changelog). K dispozici je ale i stabilní verze, která je vydávána jednou za 3 měsíce.

    Jednoduchá konfigurace CI PHP proprojektu

    Nyní si ukážeme jednoduchou konfiguraci kontinuální integrace nějakého projektu. Abych ukázal, že Jenkins je možné použít i na jiné projekty než ty v Javě (Java tak jako tak není na tomto serveru moc populární :-) ), zkusme nakonfigurovat kontinuání integraci pro nějaký PHP projekt. Jako ukázka nám může posloužit např. projekt PHPUnit. Projekt používá ke spouštění testů a generování reportů ant, takze v dalším budu předpokládat, že jej máte nainstalovaný a přidaný v cestě (Jenkins je schopen si jej nainstalovat sám, ale o tom možná někdy jindy). Dále předpokládám, že máte nainstalováné všechny potřebné nástroje, které se při sestatování projektu používají (phppmd, phpcs, phpdoc atd.).

    Jak již bylo zmíněno, po spuštění Jenkins naleznete na http://localhost:8080. Jelikož ant máme nainstalovaný, není potřeba měnit nic v globální konfiguraci Jenkins. Nicméně je potřeba doinstalovat alespoň některé pluginy, zejména Git plugin a pak např. PMD plugin, podle toho, co chceme používat. Na stránku s konfigurací pluginů se dostaneme přes "Manage Jenkins" a následné "Manage Plugins" (případně rovnou přes URL http://localhost:8080/pluginManager/). Na záložce "Available" vybereme v sekci "Build Reports" PMD Plugin a v sekci "Source Code Management" Git plugin. Dole na stránce odklikneme Install a pluginy se stánou a nainstalují včetně závislostí (v tomto případě se navíc nainstaluje plugin Static Code Analysis Plug-ins).



    Po úspěšném nainstalování pluginů je potřeba Jenkins restartnout. Toto je jedna z věcí, která mi na Jenkins vadí, nicméně jelikož pluginy neinstaluji až tak často, dá se s tím žít.

    Nyní již k samotné konfiguraci. Základní konfigurace je velice jednoduchá. Vytvoříme nový freestyle projekt: na úvodní stránce link "New Job", zvolíme jméno a jako typ projektu vybereme "Build a free-style software project". Po OK se dostaneme na stránku s konfigurací projektu. První, co nastavíme, je repozitář projektu. V sekci "Source Code Management" vybereme Git, zadáme URL projektu na githubu (git://github.com/sebastianbergmann/phpunit.git), případně můžeme specifikovat větev, kterou chceme sestatovat (např. aktuální větev 3.5).



    Dále v "Build" sekci přidáme nový build step. Vybereme "Invoke Ant". Můžeme zde specikofovat jednotlivé cíle, které má Ant spustit, nastavit cestu k souboru, který má spustit, pamatery a pod. Jelikož konfigurační soubor PHPUnit se jmenuje build.xml, nachazí se v kořenovém adresáři projektu a ma definovaný defaultní cíl, neni ale potřena nastavovat vůbec nic. V sekci "Post-build Actions" nastavíme cesty k výsledkům junit testů, pmd analýzy a cestu k dokumentaci. Reporty se vygenerují do adresáře builds/logs a dokumentace do builds/api. Pokud testy obsahují chyby, pmd se defaultně nespustí. Jelikož toto je i náš případ (aktuálně jeden junit test neprojde), v "Advanced" sekci PMD zakrtneme "Run always".



    Konfiguraci uložíme, spustíme build a můžeme případně sledovat průběh buildu.



    Po doběhnutí nám na stránce projektu přibydou kromě odkazu na dokumnetaci i odkazy na výsledky junit testů a pmd analýzy. Výsledky si pochopitelně můžete podrobně projít.







    Pokud build spustíme vicekrát, na hlavní stránce proketu navíc přibudou grafy s trendy junit testů a pmd analýzy:



    A to je vše, základní konfigurace je hotová.

    Toto byla jen vcelku jednoduchá, ale v mnoha případech dostačující, konfigurace. Dále by bylo užitečné nastavit např. kdy se má build spustit (v určitý cas, pokud dojde ke změnám v repozitáři, atd.), odelání emailu, pokud build neprojde, případně odeslání mailu vývojáři, který pravděpodobně chybu způsobil. Krom tohot základního nastavení Jenkins a jeho pluginy mohou nabídnout mnohem více možností. O tom snad někdy jindy.

           

    Hodnocení: 83 %

            špatnédobré        

    Anketa

    Používáte kontinuální integraci?
     (33 %)
     (12 %)
     (47 %)
     (9 %)
    Celkem 92 hlasů

    Tiskni Sdílej: Linkuj Jaggni to Vybrali.sme.sk Google Del.icio.us Facebook

    Komentáře

    Vložit další komentář

    31.7.2011 08:20 CEST
    Rozbalit Rozbalit vše Re: Kontinuální integrace s Jenkins CI
    No jo, takhle.to taky v praci delame. Teda ja to musim drzet za behu, ale ted uz vim, jak se to jmenuje. Akorat mame vlastni systemy, ale jeden kolega asi testuje Hudson-instaloval jsem mu na to masinu.
    31.7.2011 11:09 dementni.lojzik | skóre: 19 | blog: ze zivota na vsi
    Rozbalit Rozbalit vše Re: Kontinuální integrace s Jenkins CI
    No jo, takhle.to taky v praci delame. Teda ja to musim drzet za behu, ale ted uz vim, jak se to jmenuje.
    jj, imho to kontinualni integraci provuzuje kde kdo, protoze je to vcelku prirozene, ale hromada lidi nevi, ze to uz stihnul nekdo pojmenovat:-) (A je na zvazeni kazdeho, jestli pouzije nejaky existujici nastoj nebo si napise par svy (napr. bashovych) skriptu)
    31.7.2011 08:59 Pavel Křivánek | skóre: 24 | blog: Kvičet nezávaznou konverzaci
    Rozbalit Rozbalit vše Re: Kontinuální integrace s Jenkins CI
    Mír je, když se střílí jinde.
    31.7.2011 11:05 dementni.lojzik | skóre: 19 | blog: ze zivota na vsi
    Rozbalit Rozbalit vše Re: Kontinuální integrace s Jenkins CI
    spatny okaz ke staneni, spravny je http://mirrors.jenkins-ci.org/plugins/copyartifact/latest/ :-) AFAIK tento plugin pro Hudson uz nikdo nevyviji (ostatne, posledni verze u Hudsonu je 1.9, kdezto u Jenkins 1.18)
    31.7.2011 13:29 Pavel Křivánek | skóre: 24 | blog: Kvičet nezávaznou konverzaci
    Rozbalit Rozbalit vše Re: Kontinuální integrace s Jenkins CI
    A existuje nějaká alternativa (krom kopírování v shell scriptu)? Používáme ho opravdu hodně. Třeba v jednom úkolu se z Gitu získávají aktuální scripty, které pak řídí zpracování dalších úkolů. Nebo díky tomu máme zvláštní úkoly stahující aktuální verze potřebných souborů z internetu atd.
    Mír je, když se střílí jinde.
    31.7.2011 15:08 dementni.lojzik | skóre: 19 | blog: ze zivota na vsi
    Rozbalit Rozbalit vše Re: Kontinuální integrace s Jenkins CI
    popravde receno nevim, ja tenhle pugin nikdy nepouzil. Ruznych atrifact uploaderu je pomerne hodne - zalezi dost na tom, co presne je potreba. Kazdopadne bych jako o alternative uvazoval o NFS - Jenkins master by ukladal joby na diskovy oddil, ktery by byl pres NFS sdileny se slave nody, takze by z kazdeho slave nodu byl pristup ke vsem artefaktum vsech jobu (ktere by se pak pripadne skopirovaly do workspace, pokud by bylo potreba do nich zapisovat). Nebo obdobne, mit pres NFS sdileny disk, pak jeden job napr. z githubu stahne zdrojaky a ostatni joby si je odtud kopiruji.
    pavlix avatar 31.7.2011 10:16 pavlix | skóre: 53 | blog: pavlix
    Rozbalit Rozbalit vše Re: Kontinuální integrace s Jenkins CI
    poté, co Oracle vcelku nekompromisně odmítnul převedení projektu pod nejakou OSS nadaci, před nějakým časem Oracle rozhodnul, že projekt převede pod Eclipse foundation
    Co mi to jen připomíná…
    GentooFedoraSCRAM – Jsem open source vývojář, nikoli markeťák ⇒ názory zde uvedené jsou jen mé vlastní.
    31.7.2011 11:39 jkb
    Rozbalit Rozbalit vše Re: Kontinuální integrace s Jenkins CI
    ... Pravděpodobnost těchto konfliktů a jejich složitost pochopitelně závisí na tom, jak často tento proces absolvujete - čím je tento interval delší, tím větší pravděpodobnost (za predpokladu, že každý vývojář nepracuje na submodulu, který je zcela oddělen od ostatních - což v reálu není přiliš časté), ...

    to bych rekl , ze je ten hlavni problem softwaroveho vyvoje.
    31.7.2011 12:01 Filip Jirsák | skóre: 66 | blog: Fa & Bi
    Rozbalit Rozbalit vše Re: Kontinuální integrace s Jenkins CI
    Ne každého. Jenom toho špatně organizovaného.
    31.7.2011 21:22 janek
    Rozbalit Rozbalit vše Re: Kontinuální integrace s Jenkins CI
    Podle mě je horší když máš skupinu lidí, kteří si dělají každý na svém písečku, protože ti lidé se potom stávají nenahraditelnými. Převzetí cizího kódu, o kterém nic nevím, bude trvat minimálně několik týdnů a to může být v mnoha projektech zásadní problém.
    31.7.2011 21:30 Filip Jirsák | skóre: 66 | blog: Fa & Bi
    Rozbalit Rozbalit vše Re: Kontinuální integrace s Jenkins CI
    Ale když bude každý vrtat do všeho, nijak se to nezlepší – naopak, nebude už vůbec nikdo, kdo by tomu kódu pořádně rozuměl. To oddělení modulů samozřejmě nemá vypadat tak, že na každé části dělá jen jeden vývojář, ale měla by to být nějaká menší skupinka, kde už se mezi sebou domluví, kdo na čem zrovna dělá, takže nebudou tři najednou upravovat jednu funkci.
    AsciiWolf avatar 31.7.2011 17:29 AsciiWolf | skóre: 34 | blog: Blog
    Rozbalit Rozbalit vše Re: Kontinuální integrace s Jenkins CI
    Jenkins? Leeroy! :-D
    31.7.2011 23:47 Já
    Rozbalit Rozbalit vše Re: Kontinuální integrace s Jenkins CI
    Ještě aby to nepotřebovalo 2 giga paměti jenom aby to dokázalo vůbec běžet (a další gigo aby mi aspoň spustilo bash skript). Jasně, jsme byznys, všecko máme, všecko se koupí a zařídí, ale i tak… co je mi platné jak hrozně snadno se to instaluje a všechno, když na to potřebuju celý samotný dedikovaný stroj. Představoval bych si něco praktičtějšího.
    1.8.2011 09:20 dementni.lojzik | skóre: 19 | blog: ze zivota na vsi
    Rozbalit Rozbalit vše Re: Kontinuální integrace s Jenkins CI
    no, jestli ti to zere 2GB po spusteni a a dalsi giga aby to spustilo bash skript, tak zjevne delas neco blbe. O tom, ze programy v jave se daji spoustet s ruznymi parametry, jako treba -Xmx jsi uz nekdy slysel? (resp. myslim, ze ses vubec neobtezoval tim, zkusit si to pustit, protoze 2GB to po startu vazne nezere)
    co se tyce HW, nikdo te pochopitelne nenuti, abys na to mel specializovany server, pust si to kde chces. Jestli mas treba SVN server u sebe na notebooku, Jenkins se tam urcite taky jeste vejde. Mozna by pro tebe bylo uzitecnejsi, kdyby sis to misto placani tady v diskuzi skusil opravdu pustit ...
    1.8.2011 13:49 Já
    Rozbalit Rozbalit vše Re: Kontinuální integrace s Jenkins CI
    Já to opravdu zkoušel, a virtuální mašina s 2G paměti byla dolní mez kde to aspoň naběhlo, další giga pak bylo třeba, aby tam šel ten bash skript a nedostal jsem Javovou výjimku o nedostatku zdrojů.
    1.8.2011 14:07 Filip Jirsák | skóre: 66 | blog: Fa & Bi
    Rozbalit Rozbalit vše Re: Kontinuální integrace s Jenkins CI
    Jakou velikost dostupné paměti jste v té Javě nastavil?
    1.8.2011 15:35 dementni.lojzik | skóre: 19 | blog: ze zivota na vsi
    Rozbalit Rozbalit vše Re: Kontinuální integrace s Jenkins CI
    v tom pripade by bylo velmi uzitecne udelat a nekam dat ke stazeni heap dump (jmap -dump:file=jenkinsDump.hprof $jenkins_proces_id), velmi rad se na nej podivam
    2.8.2011 15:54 alkoholik | skóre: 34 | blog: Alkoholik
    Rozbalit Rozbalit vše Re: Kontinuální integrace s Jenkins CI
    Me staci 1,5GB pro virtual, kde bezi Jenkins i Gerrit zaroven.
    Problemy s pameti jsem mel u starsi verze. Finta byla v tom, ze se nemusela zvetsit -Xmx, ale -XX:MaxPermSize.
    msk avatar 1.8.2011 11:04 msk | skóre: 27 | blog: msk
    Rozbalit Rozbalit vše Re: Kontinuální integrace s Jenkins CI
    Zacinam zavidiet programatorom pracujucich v normalnych prostrediach, kde sa veci ako CI pouzivaju bezne. Ja som teamcity pouzival uz pred rokmi, nevediac, ze je to vlastne to CI. Momentalne trpim v teame, kde je CI len ako doplnok a takmer sa nepouziva ( resp. nema zmysel jeho vystupy nejak analyzovat ), pretoze kombinacia zaostalych technologii a nastanevnych procesov sposobuje, ze verzovaci pasystem je takmer denne plny neskompilovatelneho bordelu ktory nikto zasadne neriesi, pretoze cely team je zvyknuty na to, ze eclipse to _nejak_ predsa len skompiluje.

    Co by som len dal za to, dostat sa zase do normalnych kolaji ( tymto nenapadne naznacujem, ze som pracovnym ponukam znacne otvoreny :-) )

    Založit nové vláknoNahoru

    ISSN 1214-1267  
    © 1999-2015 Nitemedia s. r. o. Všechna práva vyhrazena.