Magie DevOps a Agilních metodik

Posted on Posted in DevOps

Dnešní doba je plná zaklínadel v podobě Buzzwords. Pokud zrovna nejste z IT branže nebo nejste protřelý obchodník, tak vám mohou termíny jako DevOps, Lean,Waterfall, Agile, Scrum, Kanban  přivodit nejeden odpolední bolehlav. Situaci ještě mnohem více zhoršuje fakt, že se často jedná pouze o pojmy, které sdružují obecná pravidla nebo postupy.

Takže hon za hledáním absolutní pravdy se stává marným hned na začátku. Dodatečnou mysteriózní atmosféru dotváří fakt, že každý z nás si pod těmito pojmy představí něco trochu rozdílného.

Jak tedy dnešní optikou nahlížet na problematiku vývoje a jak se vyznat v rozmanité terminologii? Dle mého názoru je nezbytné si uvědomit, že nic jako absolutní pravda neexistuje. Je nutné si připustit, že kontext je král. Problémy, které má software řešit jsou velmi rozmanité a vždy specifické pro svou doménu. Takže jen těžko budete hledat  jakékoliv “best practises”.

Na druhou stranu veškerý dosud napsaný software a i budoucí software má společného jmenovatele. Každý software se zrodí za účelem vyřešit určitý zákaznický problém. Pokud vaši zákazníci nebudou mít problémy, tak nebudeme potřebovat software. Z předchozí úvahy se dá usoudit, že veškerý software by měl být řízený zákaznickými požadavky, protože má řešit problémy zákazníka, který si od nás software objednal.  Je to určitě správný přístup, ale jak už to v našem světě bývá, nic není tak jednoduché,  jak se zprvu zdá.

Zákazník dost často neví co přesně chce. To se stává z mnoha důvodů. Může se to stát, když má zákazník špatně zmapovaný trh nebo se mu během vývoje změní priority nebo jen není technicky schopný přesně specifikovat problém, který potřebuje vyřešit.

Zde vystává otázka. Jak je možné v takto měnícím se prostředí, které je plné nástrah na každém rohu dodat zákazníkovi software, který opravdu potřebuje? Teď je ten správný čas, kdy se před námi otevře rozmanitý svět vývojových metodik a postupů obohacených právě o výše zmíněná zaklínadla.

Lean manufacturing a lean startup

Termín Lean startup  vznikl z principů takzvané štíhle výroby (Lean manufacturing). Z laického pohledu je to vývoj řízený trhem, který klade důraz na zvyšování efektivity a snížení plýtvání zdrojů. V praxi to znamená, že na základě měření a získaných dat se snažíte zjistit, jak zlepšit Váš produkt. Tím se snažíte snížit rizika a zvýšit hodnotu produktu. Snažíte se dodávat na trh pouze změny, které koncový zákazník potřebuje. Nejtěžším bodem lean startupu je měření a vyhodnocení dat, abychom se dokázali poučit a pochopit význam dat. Měření a vyhodnocování dat je kapitola sama pro sebe, která v sobě zahrnuje další buzzwords jako jsou A/B testing , Business Inteligence , Data mining a další.

 

 

Agilní metodiky vývoje

Každá IT firma má velmi odlišné prostředí, takže je přirozené, že se snažíte co nejlépe adaptovat principy na své možnosti. Existuje mnoho možností, jak se postavit před výzvu vývoje softwaru, ale asi nejčastější heslo, se kterým se dnes setkáte, je agilní vývoj. Proč agilní vývoj ?

 

Dříve byl obvyklý takzvaný vodopádový model (Waterfall). Vodopádový vývojový model měl pevně definované kroky, kde bylo zásadní, že následující krok nemohl začít pokud nebyl dokončen předchozí. To mělo ze začátku své výhody, ale pro svět, kde se vývojové požadavky neustále mění, se tento přístup moc nehodí. Zároveň v období od počáteční analýzy po dodání softwaru byl produkt pro zákazníka black box. Takže často na konci vývoje dostal produkt, který třeba ani nepotřeboval, protože se jeho požadavky od doby, kdy se prováděla analýza, značně změnily.

Z tohoto důvodu se vyvinuly agilní metodiky vývoje, kde je mnohem jednodušší změnit požadavky ještě během vývoje. Jak ale zajisté všichni víme, každý přístup má své výhody a nevýhody. Například jakákoliv agilní metodika vývoje je  ze své podstaty velmi vrtkavá na rozpočet, termín dodání a zpětnou kompatibilitu komponent. Jedná se však o zcela přirozenou vlastnost agilních metodiky.

Na jednu stranu jste schopní se přizpůsobit jakýmkoliv požadavkům zákazníka, ale pokud zákazník v půlce vývoje zvolí jiný směr, tak se termín dodání zcela změní, protože již výsledkem má být zcela něco jiného, než na začátku projektu. Stejné je to s rozpočtem. Bohužel ani s magickou koulí nedokážeme predikovat kolik může stát vývoj produktu, který zatím nevíme jak má vypadat na svém konci. Je nutné však dodat, že z pohledu zákazníka je to v některých případech nejbezpečnější cesta, jak dosáhnout svého. Výsledkem agilního vývoje bývá software, který je šitý zákazníkovi přesně na míru.

Scrum

Scrum je přesně definovaný framework pro agilní způsob vývoje software. Scrum se snaží změnit sekvenční přístup vývoje na iterativní proces, kde je schopný zákazník ovlivnit směr vývoje v každém kroku. Scrum se dá aplikovat na různé oblasti a ne jen na vývoj. Ale pokud se bavíme v kontextu vývoje, většinou je scrum spojovaný pouze s vývojovou častí v procesu dodání softwaru.

 

Když se snažíte zobrazit celý Váš vnitrofiremní proces vytváření softwaru, tak často dojdete k hybridním modelům, kterých je celá řada. Můžete zjistit, že během analýzy požadavků a návrhu obecné architektury postupujete vodopádovým přístupem, ale když nastane čas vývoje, tak přistoupíte na agilní metodiku. Můžete i zjistit, že nasazení softwaru je u Vás závislé na určitém milníku vývoje nebo časovém úseku a pak je nasazení také spíše vodopádovým procesem. Hybridních modelů je velké množství a nemusí být špatně, záleží pouze zda jsou efektivní pro Váš případ použití.

 

Continuous integration 

Kontinuální integrace (CI) je další často skloňovaný termín v kontextu vývojového procesu. O co tedy jde? CI je proces pravidelného spojování částí kódů od všech členů vývojového týmu do jednoho funkční celku. CI je praktika, kterou postupně adaptovaly všechny agilní metodiky vývoje. A to z jednoduchého důvodu. Pro zrychlení vývoje a omezení takzvaného “integration hell” je CI nezbytné. Většinou je proces CI spuštěn ve chvíli, když vývojář publikuje změny do systému pro správu verzí zdrojového kódu (Git,TFS,SVN atd…). Může k ní však docházet třeba i pouze jednou denně. Velmi často jsou do procesu CI zahrnuty nejrůznější druhy automatických testů, které se starají o koexistenci projektu a Váš klidný spánek.

CI Vás zároveň donutí, abyste nedrželi všechny změny v kódu pouze u sebe. Tato vlastnost je důležitá jak v malých, tak hlavně ve velkých týmech.

Continuous Delivery Vs. Continuous Deployment

V tuhle chvíli si určitě říkáte, zda se nedá zautomatizovat i jiná část procesu od návrhu po dodání softwaru. Určitě to lze. Dá se dokonce zautomatizovat nasazování do produkčního prostředí. Zde je však nesmírně nutné vědět, zda je to dobrý nápad 🙂 . I v případě, že Váš software projde rozmanitou dekádou testů a třeba i statickou analýzou kódu, může být z obchodního hlediska automatické dodání nové funkce špatným nápadem. V souvislosti s těmito případy se setkáváme s termíny  continuous delivery a continuous deployment. 

 

 

Hlavním rozdílem je, že při continuous delivery rozhodujeme o nasazení manuálním pokynem. Na druhou stranu v případě continuous deployment se jedná o zcela automatizovaný proces. Jak je možné vidět na diagramu.

DevOps vs. Agile

Konečně až závěrem se dostávám k myšlence, o které jsem chtěl psát. Pokud nejste v této chvíli zmaten jako lesní včela z předchozích termínů, tak je nejvhodnější příležitost objasnit, co vlastně DevOps znamená. Agilní přístup k vývoji je nesmírně důležitý, ale je nutné si uvědomit, že celá dodávka softwaru není pouze o vývoji. Pravda je zcela opačná. Od počátku projektu až k jeho provozování vstupuje do procesu celá řada profesí.

Jako programátoři si dost často myslíme, že vše leží na nás, ale není to pravda. V dnešním světě pokud chcete dodávat software nestačí mít pouze šikovné programátory. DevOps je pouze pojem a myšlenkový směr, který se snaží o zboření bariér mezi jednotlivými pozicemi a klade důraz na komunikaci a spolupráci. DevOps nahlíží mnohem  komplexněji na celý proces života projektu a ne pouze na jeho vývojovou část.

 

 

Problematice DevOps a různým nástrojům spojených s DevOps se chci dlouhodobě věnovat a psát o nich. Takže v tomto článku nenaleznete scénář jak na to, tedy zda se vůbec něco takového dá popsat. Cílem tohoto článku je pouze ukázat, že problematika kolem vývoje softwaru a jeho provozování je nesmírně rozsáhlá a složitá. Sestavit a dodržet opravdu efektivní procesy ve firmě je extrémně náročné, ale nechce to propadat panice.

Nejdůležitější je používat selský rozum. Snažte se dělat rozhodnutí, která jsou podložena výsledky a měřením. Automatizujte rutinní procesy, které se dějí pravidelně a brzdí Vás od další práce. Využívejte k práci nástroje a zkuste je pochopit do hloubky. Často povrchní znalost nástrojů směřuje k tomu, že vymýšlíme něco, na co jsou naše nástroje již dávno připravené. A hlavně to nejdůležitější. Mějte otevřenou hlavu pro nové myšlenky a snažte se být pozitivním týmovým hráčem. Vývoj je dnes týmová hra.