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 Microsoft a prostředí 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í.
• Form autonomní a zodpovědné týmy, které vlastní, testují a poskytují funkce.
• Přechod doprava k testování a monitorování systémů v produkčním prostředí

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

Doprava je zřejmé, že organizace a týmy můžou snadno měřit a ocenit. Typická četnost DevOps zahrnuje krátké cykly sprintů s pravidelnými nasazeními do produkčního prostředí.

Strach z nedostatku stability produktů s krátkými sprinty, některé týmy vykompenzovaly stabilizační období na konci svých sprintových cyklů. 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, které se hrály prostřednictvím kanálů doručení a do produkčního prostředí.

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

Plně automatizovat kanály

Většina týmů pro zlepšení může získat okamžitě, je plně automatizovat kanály z úložiště kódu do produkčního 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í, je tu dluh za nasazení.

Je jednodušší pracovat v menších blocích nasazením často. Tato myšlenka se může zdát zjevná v zpětném pohledu, ale v době, kdy se může zdát 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 sifonoval vývoj a rychlost doručování.

Nezávislost a odpovědnost týmu

Žádné konkrétní klíčové ukazatele průběhu (KPI) měří produktivitu nebo výkon týmu nebo jestli je funkce na cestě. Týmy musí být schopny spravovat vlastní plány a backlogy a současně najít způsob, jak sladit cíle 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 týmů a jednotlivců může být v daném časovém období přiměřeně dokončeno, ale některé funkce budou doručovat dříve a některé budou 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 pro vlastnictví 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 zvyklí pracovat v samostatných větvích. Sloučení dluhu na každé větvi vzrostlo, dokud se inženýr pokusil integrovat svou větev do hlavní 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 jednoduché větvení nabídek Gitu. Výhodou interního inženýrství bylo odstranění hierarchie hlubokých větví a jeho plýtvání. Celou dobu, kterou jsme strávili integrací, se teď přelévá do doručení.

Použití příznaků 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říznaky funkcí řídí vystavení bez rizika problémů s celkovou uživatelskou základnou a můžou týmům pomoct určit, jestli a jak tuto funkci dokončit.

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

Přesunutí doprava na testování v produkčním prostředí pomáhá zajistit, aby předprodukční testy byly platné a aby neustále se měnící produkční prostředí byly připravené ke zpracování nasazení.

Instrumentace testů a metrik

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 s recenzemi na nejvyšší úrovni vedení. Každé šest týdnů předvádějí organizace, jak fungují v oblasti stavu, firmy, 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í. Teams nejen dodává funkce, ale podívejte se, jestli je lidé používají a jak je používají. 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í

• Není to nikdy přímka, která by se dostala z A do B, ani není konec B.
• Vždy dojde k chybám a chybám.
• Prohlédněte si zpětná nastavení jako příležitosti ke změně taktiky pro dokončení dané části 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í.