Jak Microsoft dodává software s DevOps

Microsoft má desetiletí zkušeností s poskytováním vysoce škálovatelných služeb do produkčních prostředí. Jak se služby a prostředí Microsoftu rozšířily, jejich postupy doručování se také v průběhu času vyvinuly. Mnoho zákazníků Microsoftu také přijalo tyto efektivní postupy doručování a využívalo je. Následující základní principy a procesy DevOps se můžou vztahovat na veškeré úsilí o poskytování moderního softwaru.

K implementaci procesů doručování DevOps společnost Microsoft přijala následující iniciativy:

• Zaměřte se na organizační myšlení a tempo doručování.
• Vytvářejte autonomní a zodpovědné týmy, které vlastní, testují a dodávají funkce.
• Posun směrem doprava pro testování a monitorování systémů v produkci.

Zaměření na doručování

Rychlejší doprava je zřejmou výhodou, kterou organizace a týmy mohou snadno měřit a ocenit. Typická četnost DevOps zahrnuje krátké cykly sprintů s pravidelnými nasazeními do produkčního prostředí.

Některé týmy se obávaly nedostatečné stability produktů s krátkými sprinty, a proto to kompenzovaly stabilizačními obdobími na konci svých cyklů sprintů. Technici chtěli expedovat co nejvíce funkcí během sprintu, takže vznikl testovací dluh, který museli zaplatit během stabilizace. Týmy, které během sprintu spravují svůj dluh, pak musely podporovat týmy, které vytvořily dluh. Dodatečné náklady se promítly do kanálů doručení a následně do produkce.

Odstranění období stabilizace rychle zlepšilo způsob, jakým týmy spravují svůj dluh. Místo odsouvání klíčové údržby do stabilizačního období musely týmy, které vytvořily dluh, strávit další sprint doháněním svých dluhových cílů. Týmy se rychle naučily spravovat svůj technický dluh v testování během sprintů. Funkce se dodávají, když se osvědčí a stojí za náklady na nasazení.

Plně automatizovat kanály

Většího zlepšení mohou týmy dosáhnout okamžitou plnou automatizací procesu od úložiště kódu po produkční prostředí. Automatizace zahrnuje kanály verzí s kontinuální integrací (CI), automatizovaným testováním a průběžným doručováním (CD).

Týmy se můžou vyhnout nasazení, protože je obtížné, ale čím méně často nasazují, tím obtížnější je. Čím více času mezi nasazeními, tím více problémů se hromadí. Pokud kód není aktuální, vzniká dluh z nasazení.

Je jednodušší pracovat v menších úsecích častým nasazováním. Tato myšlenka se může zdát zjevná při zpětném pohledu, ale v té chvíli může působit neintuitivně. Častá nasazení také motivují týmy k určení priorit vytváření efektivnějších a spolehlivých nástrojů a kanálů nasazení.

Použití interních nástrojů

Microsoft používá systém správy verzí, který sestavuje, a dodává ho zákazníkům. Jedna investice zlepšuje produktivitu týmu i produkty Microsoftu. Použití sekundárního systému by odčerpávalo rychlost vývoje a doručování.

Nezávislost a odpovědnost týmu

Neexistují žádné specifické klíčové ukazatele výkonnosti (KPI), které by měřily produktivitu nebo výkon týmu či určovaly, zda je funkce na správné cestě. Týmy musí být schopny spravovat vlastní plány a backlogy a zároveň najít způsob, jak sladit své cíle s cíli organizace.

Je důležité komunikovat přímo s týmy, aby bylo možné sledovat pokrok. Nástroje by měly usnadnit komunikaci, ale konverzace je nejprůhlednější způsob komunikace.

Určení priorit funkcí

Důležitým cílem je zaměřit se na poskytování funkcí. Plány můžou vyhodnotit, kolik práce mohou týmy a jednotlivci v daném časovém období rozumně dokončit, ale některé funkce budou dodány dříve a některé později. Týmy můžou určovat prioritu práce, aby se nejdůležitější funkce zpřístupňují do produkčního prostředí.

Použití mikroslužeb

Mikroslužby nabízejí různé technické výhody, které zlepšují a zjednodušují doručování. Mikroslužby také poskytují přirozené hranice odpovědnosti týmu. Pokud má tým autonomii nad investicemi do mikroslužby, může určit prioritu implementace funkcí a správy dluhu. Týmy se můžou zaměřit na plány faktorů, jako je správa verzí, nezávisle na celkových službách, které závisí na mikroslužbě.

Hlavní práce

Technici pracovali v samostatných oborech. Problémy s integrací na každé kódové větvi narůstaly, dokud se inženýr nepokusil integrovat svou kódovou větev do hlavní kódové větve. Čím více týmů a techniků tam bylo, tím větší byla integrace.

Aby integrace probíhala rychleji, nepřetržitěji a v menších blocích, technici teď pracují v hlavní větvi. Jedním z hlavních důvodů, proč přejít na Git, bylo jeho lehké větvení. Výhodou interního inženýrství bylo odstranění hierarchie hlubokých větví a jeho plýtvání. Veškerý čas, který jsme kdysi trávili integrací, se teď přesměrovává do dodání.

Použijte příznaky funkcí

Některé funkce nejsou úplně dokončené pro nasazení sprintu, ale můžou být stále přínosné z testování v produkčním prostředí. Týmy můžou tento kód sloučit a nasadit pomocí příznaků funkcí , aby tuto funkci zapnuly pro konkrétní uživatele, jako je vývojový tým nebo malý segment počátečních uživatelů. Přepínače funkcí řídí vystavení bez rizika problémů s celkovou uživatelskou základnou a mohou týmům pomoci určit, jestli a jak tuto funkci dokončit.

Testování v produkčním prostředí

Posunutí testování doprava přímo do produkčního prostředí pomáhá zajistit, aby předprodukční testy byly platné a aby neustále se měnící produkční prostředí bylo připravené ke zpracování nasazení.

Testy přístrojů a metriky

Bez ohledu na to, kde se aplikace nasazuje, je důležité instrumentovat všechno. Instrumentace pomáhá nejen identifikovat a opravit problémy, ale může poskytovat neocenitelný výzkum o využití a o tom, co přidat dále.

Testování vzorů odolnosti

Riziko složitých nasazení je kaskádové selhání, kdy selhání jedné komponenty způsobí selhání závislých komponent a tak dále, dokud se celý systém nerozloží. Je důležité pochopit, kde jsou jednotlivé body selhání (SPOF) a jak se zmírňují, a otestovat procesy zmírnění rizik, zejména v produkčním prostředí.

Výběr správných metrik

Navrhování metrik může být obtížné. Běžnou chybou je zahrnout příliš mnoho metrik, abyste se vyhnuli chybě. To ale může vést k ignorování nebo nedůvěryhodné hodnotě metrik, které nesplňují konkrétní potřebu. Místo toho týmy Microsoftu potřebují čas k určení dat, která potřebují k měření úspěchu. Týmy můžou přidávat nebo měnit metriky, ale pochopení účelu od začátku usnadňuje tento proces.

Kromě základu metriky týmy zvažují, co potřebují k měření metriky. Například rychlost nebo zrychlení uživatelských zisků může být užitečnější metrika než celkový počet uživatelů. Metriky se liší od projektu po projekt, ale nejužitečnější jsou ty, které mají potenciál řídit obchodní rozhodnutí.

Použití metrik k vedení práce

Microsoft zahrnuje metriky do hodnocení na nejvyšších úrovních řízení. Každých šest týdnů prezentují organizace, jak fungují v oblasti zdraví, byznysu, scénářů a telemetrie zákazníků. Organizace probírají metriky s vedoucími pracovníky a jejich týmy.

Týmy v celé organizaci prověřují metriky uživatelů a určují význam jejich funkcí. Týmy nejen dodávají funkce, ale také sledují, zda a jak jsou používány. Týmy tyto metriky používají k úpravě backlogů a určení, jestli funkce potřebují více práce, aby splňovaly cíle.

Pokyny k doručení

• Nikdy to není přímá cesta z A do B, ani není B konec.
• Vždy dojde k problémům a chybám.
• Vnímejte neúspěchy jako příležitosti k učení se změnám taktiky, jak dokončit určenou část procesu.
• V průběhu času se každý tým vyvíjí podle svých postupů DevOps tím, že staví na zkušenostech a přizpůsobí se měnícím se potřebám.
• Klíčem je zaměřit se na poskytování hodnoty, a to jak koncovým uživatelům, tak i samotnému procesu doručování.