DevOps 101 s Atlassian- stavíme produkty stylem DevOps, kontinuální dodávky

05.06.2017 | Popis interních procesů Atlassian a cesta ke směru menších, kontinuálních dodávek software

Před pěti lety Marc Andreesen prohlásil, že software sžírá svět.
Koneckonců- jaká společnost se v dnešní době nezabývá software?

DevOps není pouze prací jednotlivce, je o spoluúčasti všech.

 

Nejsou to pouze vývojové týmy, kdo využívá zkušeností DevOps, stejné postupy lze analogicky aplikovat i na hardware a konfigurace.

V Atlassian máme tým desítek zaměstnanců (nazvané „build engineers“), které se zaměřují na podporu vývojářům- ti poté píšou kód rychleji, díky tomu, že je jim poskytován nejlepší hardware a infrastruktura, kterou potřebují a vyžadují- dohlíží na integrační služby (Bamboo), a službu pro sdílení artefaktů (Sonotype Nexus), veškerý hardware, konfigurace, aplikace a služby o které se tento tým stará poskytují vývojářům komfort pro jejich práci.

 

Pojďme se hlouběji podívat na technologie a procesy, díky kterým fungujeme a na to, jak vývoj vylepšit z hlediska efektivity.

 

Zpětná vazba od vývojářů

Našimi zákazníky jsou vývojáři Atlassian, využíváme Jira service desk- díky kterému nám uživatelé mohou poskytovat zpětnou vazbu.

 „Zůstaňte na palubě“ během stand-upů

Každé ráno máme stand-upy stejně tak, jako většina vývojových týmů, kde procházíme všechna issue, které jsou v běhu na našem kanban boardu v JIRA. Každé issue má svojí kategorii.

Nastavujeme limity pro počet Issue, které mohou být v každém sloupci s daným stavem. Níže můžete vidět několik sloupců, které jsou již červené- to znamená, že jsme překročily hodnoty limitů. To nám značí, že musíme nejprve danou práci odbavit, než do sloupce dáme něco nového.

Pull-requesty: swarms („smrště“), schvalování a udržování věcí zelených

Vytváříme větve pro jakékoliv typy hardware anebo konfigurace, které se měnily, nezáleží na tom, jak velká změna to je, přesně stejný postup aplikují i kolegové z vývoje. Každý jednotlivý pull-request je linkován do issue v JIRA a všechny pull-requesty spravuje přes BitBucket, ke schválení je potřeba dvou úspěšných schválení (plus zelený build), aby se daná věc pohnula kupředu.

Náš tým má také místnost na HipChatu, kam píše bot, který sleduje všechny naše pull-requesty. Ukazuje nám všechny otevřené pull-requesty, ale i to, jak se uzavřeli, když změny byly zahrnuty a provedl se merge kódu. Ponecháváme na týmu, aby si vyřešili pull-requesty a poskytli zpětnou vazbu těm, komu je potřeba. Všichni tuto činnost dělají velice dobře a efektivně posunují rychlost procesu.

Takže HipChat, JIRA, Jira service desk a BitBucket jsou velkou součástí našich úkonů den co den.

Oblíbené nástroje pro pipeline

Možná vás zajímá, jaké všechny nástroje využíváme pro řízení toku kódu, zde jsou ty nejoblíbenější z nich.

Software pipeline

 

Stejně jako náš vývojový tým, i my využíváme Bamboo na straně infrastruktury k organizaci našich plánů a procesu deploymentu.

Bamboo také využíváme ke správě Puppet, kde píšeme nové moduly a konfigurujeme komponenty na našich serverech, jako model pro přidání SSH klíčů všech členů našeho týmu.

Vagrant nám umožňuje snadno spustit testovací servery, na které se následně aplikuje Puppet konfigurace pro testování. Puppet a Vagrant lze snadno integrovat a díky této kombinaci je snadné automaticky testovat nové konfigurace AWS serveru.

 

Cucumber je skvělý nástroj i pro testování. Používáme jej k tomu, abychom správně instalovali naše agenty a k ověření, že změny, které jsme provedli, nic nepoškodily.

Když dokončíme testování změn kódu anebo konfigurace, nasazujeme nový Puppet tree do produkce a HipChat automaticky provede post notifikaci odpovědné osobě, jednak pro informaci, a za druhé, aby ověřil funkčnost a případně uzavřel issue spojené s tímto procesem.

Jako vždy, Bamboo zobrazuje aktuální stav buildu a další podrobnosti každého release, jako například prostředí, ve kterém bylo implementováno a které problémy jsou k danému release a build number vztaženy v JIRA.

Hardware pipeline 

Bamboo spravuje vše v našem HW pipeline procesu. Od začátku až po dokončení vývoje. Od dob, kdy využíváme Amazon web Services (AWS), využíváme Terraform ke správě naší hardware infrastruktury. Milujeme jej, protože umožňuje uplatnit naše zkušenosti a podporuje workflow taková, aby se změny projevily všude, kde je třeba.

Například: Změny na naší HW infrastruktuře, které požadujeme skrze Terraform, si vyžadují schválení přes pull-requesty a procesy nasazení přes kontinuální delivery pipeline- ten samý proces musí využívat náš vývojový tým. To stále drží kvalitu produktu napříč celkového procesu.

Zde je ukázka, jak vypadá kód z Terraform

Jak je vidět, v něm nastavujeme nový NAT server na AWS. Využíváme kód pro nastavení všech parametrů jako např. subnet, atp. Můžeme naplnit kompletní parametry o HW do Terraform, a ty se využijí a objeví, když bude voláno API na AWS, aby provedlo změny na naší topologii- ze stavu současného, do stavu požadovaného kódem.

Následně můžeme po Terraform požadovat spuštění příslušných úloh a provést tyto změny.

Sledujeme všechny release na Bamboo, stejně tak, jako sledujeme všechny změny našeho software. Bamboo provede deploy každého release z  Terraform nejprve na naše interní testovací servery, a následně, když jsou připravené a schválené, tak na produkci. Bamboo také využíváme, abychom věděli, jaká verze produktu byla nasazena.

Tři klíčové koncepty k zapamatování

Nic nemění hru víc, než myšlenka „infrastructure as code”

To povoluje využití znalostí z procesu vývoje, ale jejich použití na hardware je ještě o něco vylepšené díky stabilitě naší platformy. Zdvojování procesů vyhrazených pro Bamboo v Atlassian byla stejná práce, jako přidání pouze jednoho. Naše týmy využívají tři základní pravidla a kdokoliv si jej může osvojit:

  1. Vše automatizujte

Kritickou částí je to, jak naše buildy fungují.

Pokud je nebudeme dostatečně testovat, potom si nemůžeme být jisti, jak fungují. Automatické testy snižují rizika a dávají nám jistotu našich změn a tím pádem nám umožňují kontinuální vývoj a dodávky.

Automatizujeme upozornění, vše co potřebujeme je eliminovat faktor lidské chyby a jistota, že nezapomeneme na důležité věci.

Nakonec, s větší automatizací, můžeme držet menší týmy. To znamená méně komunikace a větší rychlost, což je přesně na pořadu dne.

  1. Soustřeďte se na kontinuální dodávky

Stabilní hardware a odpovědné konfigurace jsou kritické, aby měli naši vývojáři jistotu toho, co dělají.

  • Náš kód je vždy schopný release
    Naše master větev má vždy „zelenou“, takže kdykoliv můžeme vydat release
  • Release děláme často
    To minimalizuje risk, jelikož předáváme pouze malé změny mezi jednotlivými release a když je třeba, tak lze změny snadno vracet zpátky
  • Soustředíme se na „fast value delivery“
    Od doby, co jsou naši uživatelé vývojáři Atlassian, chceme, aby byli šťastni. Kontinuální dodávky znamenají, že chyby ve změnách jsme schopni případně opravovat velice rychle
  1. Leštěte infrastrukturu stejně tak, jako kód

Jednoduše- spouštíme kód k automatické konfiguraci serverů, aplikací a dalších- místo toho, abychom psali konfigurace ručně.

Technicky- Říkáme „udělej mi N serverů s aplikacemi X, Y a Z“, a poté využíváme zpětné vazby a procesů workflow k eliminaci faktoru lidského selhání.

Ve výsledku- jsme schopni vydávat 10x více buildů, aniž bychom do týmu přidali jediného člověka. Můžeme dělat deploy s vysokou jistotou a větší nezávislostí.


Pro další informace o novinkách Atlassian a JIRA sledujte web www.myJIRA.cz.

Diskutujeme také na LinkedIn ve skupině Atlassian komunita CZ & SK.

V případě dotazů se obraťte na atlassian_zavináč_onlio.com nebo na tel. +420222744766


Pavel Novák,
Java Developer

Zdroje:

https://www.clearvision-cm.com/wp-content/uploads/2017/04/devops-ebook-final.pdf 
(„DevOps, Promote the philosophy across your organization“, Atlassian)

Zpět