Programování

Proč se Jenkins stává motorem devopsů

Trendy jako agilní vývoj, vývoj a nepřetržitá integrace hovoří o potřebě moderního podniku vytvářet software efektivně - a v případě potřeby zapnout desetník.

Tento druhý manévr je způsob, jakým se CloudBees stala společností, jakou je dnes. Jakmile byl nezávislý, veřejný cloudový poskytovatel PaaS pro kodéry Java (vysoce hodnocený Andrewem Oliverem v sekci „Který šílený PaaS bych měl použít?“), CloudBees se před 18 měsíci prudce otočil, aby se znovu spustil jako přední poskytovatel Jenkins, velmi populární otevřené zdrojový nástroj pro řízení procesu vývoje softwaru.

Podle generálního ředitele Sasha Laboureyho, jako poskytovatele Java PaaS CloudBees „pěkně rostl“, ale „mnoho větších lidí s většími kontrolami“ váhalo se dopustit na nestálém trhu PaaS, který postrádal standardizaci. Jenkins zároveň vzlétl jako raketa - a Labourey viděl velkou příležitost, zejména proto, že CloudBees již Jenkins nabízel jako službu a najal si už Jenkinsova tvůrce Kohsuke Kawaguchi. Hlavním jídlem se stala Jenkinsova příloha.

Jenkinsův juggernaut

Co je za popularitou Jenkinse? Jednoduše řečeno, Jenkins se stal standardem otevřeného zdroje pro správu dev stránky devops, od správy zdrojového kódu až po doručování kódu do produkce. Podle Laboureyho „komunita vnímá Jenkins jako nástroj pro orchestraci a automatizaci ... Myslím, že důvodem, proč se Jenkins stal de facto motorem, je to, že je extrémně připojitelný.“ Vznikl ekosystém s více než 1100 zásuvnými moduly, který zákazníkům umožňuje přidávat nejrůznější funkce a integrovat Jenkins se vším od Active Directory přes GitHub až po OpenShift PaaS.

Jenkins je řešení pro nepřetržitou integraci (CI) a nepřetržité doručování (CD). Myšlenkou CI je sloučit kód od jednotlivých vývojářů do projektu několikrát denně a průběžně testovat, aby nedocházelo k následným problémům. CD to posouvá o krok dále, aby zajistil, že veškerý sloučený kód je vždy ve stavu připraveném k výrobě. Jenkins umožňuje vývojářům tento proces co nejvíce automatizovat - až do okamžiku nasazení. Labourey poskytuje příklad:

Řekněme, že společnost k nasazení na AWS používá kuchaře nebo loutku. Jenkins to nenahradí. Jenkins bude volat Puppet, aby to udělal - OK, tady jsou kousky, tak zavoláme tento loutkový scénář a uvidíme, jak to funguje. A na výkonu Puppet bude záležet na Jenkinsovi, protože by se mohl rozhodnout rozbalit nasazení a podniknout další akce. Říkáme tomu „potrubí“. Je to opravdu tato řada kroků. Může to být pět kroků nebo to může být 50 kroků.

Jenkins slouží jako motor pracovního postupu pro správu tohoto kanálu CI / CD od zdroje k dodání, říká Labourey, ale na cestě může být požadováno mnoho různých nástrojů k provádění různých funkcí.

Docker je jedním z těchto nástrojů a Docker ve spojení s Jenkinsem má zásadní vliv na vývojové týmy. Každý ví, že Docker zefektivňuje vývoj a výrazně usnadňuje nasazení, ale Labourey podotýká, že také pomáhá udržovat čest vývojářů: Už nemohou obviňovat nějakou nesprávnou konfiguraci vývojového prostředí, když dojde ke zhroucení a vypálení sestavení. Na fyzickém stroji se vývojové prostředí postupně poškozuje a neúmyslně způsobuje rozbití sestavení. Ale když kódujete na nedotčeném Dockerově obrázku, můžete vinit pouze svůj vlastní chybný kód, když se sestavení nespustí.

Společně Jenkins a jeho integrovaný ekosystém poskytují koordinační softwarovou infrastrukturu pro agilní vývoj a v širším smyslu tvoří „jádro iniciativy devops“, říká Labourey.

Jak se odtud dostat

Celá tato automatizace a účinnost devopů zní skvěle, ale co organizace, které sotva obtočily hlavu agilním vývojem? Labourey nabízí rady pro brodění se na CI / CD:

Myslím, že nejlepší způsob, jak toho dosáhnout, je začít v malém. Vyberte projekt. Neříkejte: „Dobře, nyní jsme obchod s nepřetržitým doručováním, všechno jde takhle.“ Začněte s týmem, který je ochotný, který je možná flexibilnější než jiné týmy, možná novější členové týmu, méně zakořeněný ve stávajícím způsobu dělání věcí. Vyberte si snadný projekt. Nepokoušejte se to použít jako způsob, jak říci, že pokud to funguje, všechno bude fungovat. Nepokoušejte se selhat; pokusit se uspět. Vyberte si ochotný tým, vyberte snadný projekt a dojděte tam. Tento tým bude vaším nejlepším prodejcem, protože teď můžete ukázat, že to funguje. Mohou mluvit o tom, jak se jejich práce zlepšila, protože upřímně řečeno, stará cesta je nudná.

Součástí procesu, poznamenává Labourey, je „vytěžení znalostí, které tiše sedí v mozku lidí, a jejich logická implementace.“ To se nestane přes noc. Rozvojové organizace často začínají vytlouct CI a postupem času se propracují k CD.

Rozvojové organizace mají tendenci mít velmi rozdílné, velmi specifické požadavky. CloudBees tedy nabízí jak obecnou verzi SaaS založenou na předplatném, kterou provozuje CloudBees, tak verzi „soukromého SaaS“, kterou mohou zákazníci nasadit na AWS nebo Azure (nebo lokálně na OpenStack) a přizpůsobit ji obsahu svého srdce.

Je těžké zveličovat význam organizování, automatizace a zefektivnění procesu vývoje. CI / CD je pro devops klíčové a úspěšná implementace devopsů má zase důsledky, které přesahují rámec IT až po samotné podnikání. Neustálé zlepšování softwaru neustále vylepšuje produkty a služby. Například Tesla měla vážný neúspěch, když jeden z jejích modelů začal hořet - a zavedení softwarové aktualizace problém vyřešilo přes noc.

„Je zajímavé, když získáte o 10 procent vyšší efektivitu; pokud utratíte 100 milionů dolarů ročně v IT, skvěle - máte 10 milionů dolarů, které můžete utratit někde jinde,“ říká Labourey. „Skutečnou výhodou však je, když si podnik uvědomí, že využitím těchto nástrojů a způsobu, jakým věci dělají, mohou zvýšit prodej o 10 procent.“