Kontinuální integrace s Jenkins CI

31.7.2011 02:44 | Přečteno: 20589× | | 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.

       

Anketa

Komentáře

[CEST]

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.

[dementni.lojzik]

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)

[Pavel Křivánek]

Velmi užitečný plugin je Copy Artifact.

http://hudson-ci.org/download/plugins/copyartifact/

[dementni.lojzik]

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)

[Pavel Křivánek]

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.

[dementni.lojzik]

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]

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á…

[jkb]

... 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.

[Filip Jirsák]

Ne každého. Jenom toho špatně organizovaného.

[janek]

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.

[Filip Jirsák]

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]

Jenkins? Leeroy!

[Já]

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.

[dementni.lojzik]

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 ...

[Já]

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ů.

[Filip Jirsák]

Jakou velikost dostupné paměti jste v té Javě nastavil?

[dementni.lojzik]

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

[alkoholik]

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]

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 )