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í
×
včera 11:36 | Pozvánky
LinuxDays, konference, která se bude konat 4. a 5. 10. 2014 v Praze v Dejvicích, zveřejnila návrh programu (stále probíhá call for papers). Mezi již přihlášenými jsou přednášky z oblastí síťování, vývoje softwaru a dalších.
Jendа | Komentářů: 3
včera 09:26 | Nová verze
Vyšel GIMP 2.8.14. Jedná se o opravné vydání. Řešena je řada chyb, vylepšená je dokumentace a překlady. Novinkou je, že ve výchozím stavu přijímá script-fu-server požadavky pouze z 127.0.0.1 (bezpečnostní problém CVE-2012-4245, commit). Verze 2.8.14 vyšla záhy po verzi 2.8.12. Řešen byl problém s verzemi knihoven (commit).
Ladislav Hagara | Komentářů: 0
26.8. 09:08 | Nasazení Linuxu
Na serveru computerworld.com se objevil článek o novém pokusu nahradit v Číně windows vlastní linuxovou distribucí Red Flag. Čínský výrobce počítačů "Penta Wan Jing Information Technology Industry Group" koupil aktiva spojená s Red Flag v přepočtu za cca 132 miliónů korun. Systém by rádi uvedli na trh do října.
ZAH | Komentářů: 11
26.8. 08:48 | Nová verze
Byl vydán PoorWSGI v první oficiální stable verzi 1.0.0. PoorWSGI je malý WSGI middleware, který ale poskytuje dostatečnou funkčnost pro tvorbu webových stránek v pythonu. Více informací je dostupných na stránkách projektu. Zdrojové kódy je možné stáhnout z git repositáře nebo pypi stránek, ze kterých je také možné rovnou instalovat Python balíček pomocí pip.
McBig | Komentářů: 0
26.8. 08:44 | Pozvánky

V rámci další akce GXG Jičín vám ukážeme jak snadno můžete nahradit váš operační systém (Windows, Mac OS X...) pomocí Linuxu. Možná ho už dnes používáte a ani o tom nevíte. Zajímá vás co je Linux, proč ho využívá i Google a jaké má výhody? Martin Vancl vám ho představí a i spoustu dalších programů, které jsou zdarma! Ukáže vám, jak můžete ušetřit náklady za licence a zároveň zvýšit bezpečnost vašeho počítače. Dozvíte se, kde všude můžete Linux

… více »
Gug.cz | Komentářů: 3
26.8. 07:56 | Zajímavý projekt
Na blogu projektu sandstorm.io byla zveřejněna zpráva o portaci Apache Wave (nástupce zaniklého Google Wave). Po Etherpadu a Ethercalcu jde již o několikátou kolaborativní webovou aplikaci podporovanou touto platformou. Cílem sandstorm.io je umožnit snadno a přitom bezpečně provozovat vlastní kolekci webových aplikací na vlastním hardware (či VPS), k čemuž využívá techniku sandboxingu. … více »
fedy | Komentářů: 0
25.8. 21:37 | Zajímavý projekt
Na stránkách hry Robocraft vyšlo oznámení o začátku testování portů alfaverze hry na Linuxu a OS X. Oficiální trailer je vhodné shlédnout raději až po samotném vydání portu hry pro váš oblíbený systém…
2X4B-523P | Komentářů: 4
25.8. 13:40 | Zajímavý projekt
Server Libre Graphics World informuje o spuštění projektu Libre Music Production. Jeho cílem je pomocí srozumitelných návodů vyplnit mezeru mezi zkušenými hudebními producenty a nováčky, kteří by rádi pro svoji tvorbu využili svobodný software. Má jít o server "od hudebníků pro hudebníky", čemuž odpovídají i jména za projektem stojící, kam patří mimo jiné tvůrce audio kitu JACK, Paul Davis, nebo Gabriel Nordeborn, jenž s pomocí svobodného softwaru vydal již několik alb.
xkomczax | Komentářů: 1
25.8. 02:00 | Komunita
Konference DebConf14 (Debian Conference 2014) probíhá od 23. do 31. srpna v Portlandu. Konferenci je možné sledovat online (program).
Ladislav Hagara | Komentářů: 0
24.8. 23:24 | Zajímavý projekt
Vědci z Rutgersovy Univerzity prezentovali metodu („elastic pathing“), pomocí které lze určit trasu pohybu dopravního prostředku, pokud je znám výchozí bod a záznam o rychlostech, jakými se prostředek pohyboval. Badatelé přitom upozorňují na to, že informace o rychlosti vozidla jsou vyžadovány některými pojišťovnami v USA. Více informací včetně zdrojového kódu na elasticpathing.org.
Petr Tomášek | Komentářů: 26
Hlasuji z:
 (85%)
 (10%)
 (2%)
 (1%)
 (0%)
 (0%)
Celkem 2937 hlasů
 Komentářů: 42, poslední 25.8. 11:10
Rozcestník
Reklama
Autoškola testy online Levný benzín

Kontinuální integrace s Jenkins CI

31.7.2011 02:44 | Přečteno: 9028× | 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í: 80 %

        špatnédobré        

Anketa

Používáte kontinuální integraci?
 (36 %)
 (13 %)
 (44 %)
 (7 %)
Celkem 72 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: 48 | 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á…
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 Fa & Bi | skóre: 65 | blog: Delfinárium
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 Fa & Bi | skóre: 65 | blog: Delfinárium
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: 32 | 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 Fa & Bi | skóre: 65 | blog: Delfinárium
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: 32 | 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: 26 | 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   Powered by Hosting 90 Server hosting
© 1999-2013 Argonit s. r. o. Všechna práva vyhrazena.