Vývoj Microsoftu s Využitím DevOps

Microsoft se snaží používat One Engineering System k vytváření a nasazování všech produktů Microsoftu s pevným procesem DevOps, který je zaměřen na větvení a vydávání verzí Gitu. Tento článek zdůrazňuje praktickou implementaci, jak se systém škáluje z malých služeb na obrovské potřeby vývoje platformy, a poznatky získané z používání systému napříč různými týmy Microsoftu.

Přijetí standardizovaného procesu vývoje je ambiciózním podnikem. Požadavky různých organizací Microsoftu se výrazně liší a požadavky různých týmů v rámci organizací se škálují s velikostí a složitostí. K řešení těchto různých potřeb používá Microsoft strategii větvení založenou na kmeni, která pomáhá rychle vyvíjet produkty, pravidelně je nasazovat a bezpečně dodávat změny do produkčního prostředí.

Microsoft také používá principy přípravy platforem jako součást svého jednoho technického systému.

Microsoft Release Flow

Každá organizace by se měla vyrovnat se standardním procesem vydávání kódu, aby se zajistila konzistence napříč týmy. Tok verze Microsoftu zahrnuje procesy DevOps od vývoje po vydání. Základní kroky toku vydané verze se skládají z větve, nabízení, žádosti o přijetí změn a sloučení.

Pobočka

Pokud chcete opravit chybu nebo implementovat funkci, vývojář vytvoří novou větev mimo hlavní integrační větev. Model zjednodušeného větvení Gitu vytvoří tyto krátkodobé větve témat pro každý příspěvek kódu. Vývojáři se zaznačují včas a vyhýbají se dlouhotrvajícím větvím funkcí pomocí příznaků funkcí.

Nabízené

Až bude vývojář připraven integrovat a odeslat změny do zbytku týmu, odešle svou místní větev do větve na serveru a otevře žádost o přijetí změn. Úložiště s několika stovkami vývojářů pracujících v mnoha větvích používají konvenci pojmenování pro serverové větve ke zmírnění nejasností a šíření větví. Vývojáři obvykle vytvářejí větve s názvem users/<username>/feature, kde <username> je jejich název účtu.

Žádost o přijetí změn

Větev tématu řízení žádostí o přijetí změn se sloučí do hlavní větve a zajistí, aby byly splněny zásady větví. Proces žádosti o přijetí změn sestaví navrhované změny a spustí rychlý test. Sady testů první a druhé úrovně běží přibližně za 60 000 testů za méně než pět minut. Nejedná se o kompletní testovací matici Microsoftu, ale stačí, abyste rychle získali jistotu v žádosti o přijetí změn.

V dalším kroku ostatní členové týmu zkontrolují kód a schválí změny. Kontrola kódu přebírá místo, kde automatizované testy skončily, a je obzvláště užitečná pro sledování problémů s architekturou. Ruční kontroly kódu zajišťují, aby ostatní technici v týmu měli přehled o změnách a že kvalita kódu zůstává vysoká.

Sloučení

Jakmile žádost o přijetí změn splňuje všechny zásady sestavení a revidujícím se odhlásili, větev tématu se sloučí do hlavní integrační větve a žádost o přijetí změn se dokončí.

Po sloučení se spustí další akceptační testy, které dokončení trvá déle. Tyto tradiční testy po kontrole dělají důkladnější ověření. Tento proces testování poskytuje dobrou rovnováhu mezi rychlými testy během kontroly žádosti o přijetí změn a úplným pokrytím testu před vydáním.

Rozdíly mezi službou GitHub Flow

GitHub Flow je oblíbený vývojový tok založený na kmenech, který organizacím umožňuje implementovat škálovatelný přístup ke Gitu. Některé organizace ale zjistí, že s rostoucími potřebami se musí lišit od částí GitHub Flow.

Často přehlédnutá část GitHub Flow je například to, že žádosti o přijetí změn musí být nasazené do produkčního prostředí, aby bylo možné je otestovat, než se budou moct sloučit do hlavní větve. Tento proces znamená, že všechny žádosti o přijetí změn čekají ve frontě nasazení pro sloučení.

Některé týmy mají několik stovek vývojářů, kteří neustále pracují v jednom úložišti, kteří můžou dokončit více než 200 žádostí o přijetí změn do hlavní větve za den. Pokud každá žádost o přijetí změn vyžaduje nasazení do několika datových center Azure po celém světě pro účely testování, vývojáři tráví čas čekáním na sloučení větví místo psaní softwaru.

Místo toho týmy Microsoftu budou pokračovat ve vývoji v hlavní větvi a dávkové nasazování do časových verzí, obvykle v souladu se třítýdenním tempem sprintu .

Podrobnosti implementace

Tady je několik klíčových podrobností implementace toku verze Microsoftu:

Strategie úložiště Git

Různé týmy mají různé strategie správy úložišť Git. Některé týmy udržují většinu svého kódu v jednom úložišti Git. Kód je rozdělený na komponenty, z nichž každý je ve své vlastní kořenové složce. Velké komponenty, zejména starší komponenty, můžou mít více dílčích komponent, které mají samostatné podsložky v nadřazené komponentě.

Doplňková úložiště

Některé týmy také spravují doplňková úložiště. Například sestavení a vydávání agentů a úloh, rozšíření VS Code a opensourcových projektů se vyvíjejí na GitHubu. Změny konfigurace se přihlásí do samostatného úložiště. Další balíčky, na které tým závisí, pocházejí z jiných míst a využívají se prostřednictvím NuGetu.

Mono úložiště nebo více úložiště

Zatímco některé týmy se rozhodnou mít jedno monolitické úložiště, mono-úložiště, jiné produkty Microsoftu používají přístup s více úložišti . Skype má například stovky malých úložišť, která spojují dohromady různé kombinace a vytvářejí mnoho různých klientů, služeb a nástrojů. Zejména pro týmy, které přijímají mikroslužby, může být správným přístupem více úložiště. Starší produkty, které začaly jako monolitické, obvykle najdou přístup k monolitickému úložišti jako nejjednodušší přechod na Git a jejich organizace kódu to odráží.

Větve vydaných verzí

Tok verze Microsoftu udržuje hlavní větev vždy sestavitelnou. Vývojáři pracují v krátkodobých větvích témat, které sloučí s main. Když je tým připravený k odeslání, ať už na konci sprintu nebo hlavní aktualizace, spustí novou větev vydané verze mimo hlavní větev. Větve vydané verze se nikdy nesloučí zpět do hlavní větve, takže můžou vyžadovat výběr důležitých změn.

Následující diagram znázorňuje krátkodobé větve v modrých a vydaných větvích v černé barvě. Jedna větev s potvrzením, které vyžaduje výběr třešní, se zobrazí červeně.

Zásady a oprávnění větví

Zásady větví Gitu pomáhají vynucovat strukturu větve vydané verze a udržovat hlavní větev čistou. Například zásady větví můžou zabránit přímému nasdílení změn do hlavní větve.

Pokud chcete udržovat hierarchii větví v přehledu, týmy používají oprávnění k blokování vytváření větví na kořenové úrovni hierarchie. V následujícím příkladu můžou všichni vytvářet větve ve složkách, jako jsou uživatelé, funkce nebo týmy/. Pouze správci verzí mají oprávnění vytvářet větve v rámci vydaných verzí/ a některé nástroje pro automatizaci mají oprávnění k integraci nebo složce.

Pracovní postup úložiště Git

Vývojáři v rámci struktury úložiště a větví dělají svou každodenní práci. Pracovní prostředí se výrazně liší podle týmu a jednotlivých. Někteří vývojáři dávají přednost příkazovému řádku, ostatním, jako je Visual Studio, a jiní pracují na různých platformách. Struktury a zásady zavedené v úložištích Microsoftu zajišťují solidní a konzistentní základ.

Typický pracovní postup zahrnuje následující běžné úlohy:

Vytvoření nové funkce

Vytvoření nové funkce je jádrem úlohy vývojáře softwaru. Součástí procesu bez Gitu je pohled na telemetrická data, návrh a specifikace a zápis skutečného kódu. Vývojář pak začne pracovat s úložištěm tak, že se synchronizuje s nejnovějším potvrzením main. Hlavní větev je vždy sestavitelná, takže je zaručeno, že bude dobrým výchozím bodem. Vývojář si prověří novou větev funkcí, provede změny kódu, potvrzení, nasdílí na server a spustí novou žádost o přijetí změn.

Použití zásad a kontrol větví

Při vytváření žádosti o přijetí změn automatizované systémy kontrolují, že nové sestavení kódu nic neporuší a neporuší žádné zásady zabezpečení ani dodržování předpisů. Tento proces neblokuje paralelně probíhající další práci.

Zásady a kontroly větví můžou vyžadovat úspěšné sestavení , včetně úspěšných testů, odhlašování od vlastníků jakéhokoli kódu, kterých se dotkne, a několik externích kontrol pro ověření firemních zásad před dokončením žádosti o přijetí změn.

Integrace s Microsoft Teams

Mnoho týmů konfiguruje integraci s Microsoft Teams, která oznamuje novou žádost o přijetí změn členům týmu vývojářů. Vlastníci jakéhokoli kódu, který se dotkne, se automaticky přidají jako revidujícím. Týmy Microsoftu často používají volitelné revidujícím kód, na který se mnoho lidí dotkne, jako je generování klienta REST a sdílené ovládací prvky, aby se na tyto změny dívalo experty.

Nasazení pomocí příznaků funkcí

Jakmile jsou kontroloři, vlastníci kódu a automatizace spokojení, vývojář může žádost o přijetí změn dokončit. Pokud dojde ke konfliktu při sloučení, vývojář dostane pokyny k synchronizaci s konfliktem, jeho opravě a opětovnému nasdílení změn. Automatizace se znovu spustí v pevném kódu, ale lidé se nemusí znovu odhlásit.

Větev se sloučí do maina nový kód se nasadí v dalším sprintu nebo hlavní verzi. To neznamená, že se nová funkce hned zobrazí. Microsoft odděluje nasazení a vystavení nových funkcí pomocí příznaků funkcí.

I když funkce potřebuje ještě trochu víc práce, než bude připravená k předvednění, je bezpečné přejít na main to, jestli se produkt sestaví a nasadí. mainJakmile se kód stane součástí oficiálního buildu, kde je znovu testován, potvrzeno splnění zásad a digitálně podepsáno.

Přesunutím doleva zjistíte problémy včas.

Tento pracovní postup Gitu nabízí několik výhod. Za prvé, práce z jedné hlavní větve prakticky eliminuje slučovací dluh. Za druhé tok žádosti o přijetí změn poskytuje společný bod pro vynucení testování, kontroly kódu a detekce chyb v rané fázi kanálu. Tato strategie posunu vlevo pomáhá zkrátit cyklus zpětné vazby vývojářům, protože může detekovat chyby v minutách, nikoli hodinách nebo dnech. Tato strategie také dává jistotu pro refaktoring, protože všechny změny se testují neustále.

V současné době může produkt s 200+ žádostmi o přijetí změn vytvářet 300+ buildy kontinuální integrace za den a 500+ testovací běhy každých 24 hodin. Tato úroveň testování by byla nemožné bez pracovního postupu větvení a vydávání na základě kmene.

Vydání v milníkech sprintu

Na konci každého sprintu vytvoří tým větev vydané verze z hlavní větve. Například na konci sprintu 129 vytvoří tým novou větev vydané verze releases/M129. Tým pak nasadí větev sprintu 129 do produkčního prostředí.

Po větvi vydané verze zůstane hlavní větev otevřená pro vývojáře, aby změny sloučili. Tyto změny se nasadí o tři týdny později v dalším nasazení sprintu.

Vydané opravy hotfix

Někdy musí změny rychle přejít do produkčního prostředí. Microsoft obvykle nepřidá nové funkce doprostřed sprintu, ale někdy chce rychle přinést opravu chyb, aby odblokoval uživatele. Problémy můžou být menší, například překlepy nebo dostatečně velké, aby způsobily problém s dostupností nebo incident živého webu.

Oprava těchtoproblémůch Vývojář vytvoří větev z main, získá zkontrolovaný kód a dokončí žádost o přijetí změn, aby ji sloučil. Proces vždy začíná provedením změny v main prvním. To umožňuje rychle vytvořit opravu a místně ji validovat, aniž byste museli přepnout na větev vydané verze.

Následující proces také zaručuje, že se změna dostane do main, což je důležité. Oprava chyby ve větvi vydané verze bez vrácení změny main zpět by znamenala, že se chyba bude opakovat během dalšího nasazení, když sprint 130 vydané verze větve z main. Během zmatení a stresu, které mohou vzniknout během výpadku, je snadné zapomenout aktualizovat main . Přenesení změn do main prvního znamená, že vždy máte změny v hlavní větvi i ve větvi vydané verze.

Funkce Gitu umožňuje tento pracovní postup. Pokud chcete změny přenést okamžitě do produkčního prostředí, může vývojář po sloučení žádosti o mainpřijetí změn použít stránku žádosti o přijetí změn k výběru změn do větve vydané verze. Tento proces vytvoří novou žádost o přijetí změn, která cílí na větev vydané verze a backportuje obsah, který se právě sloučil do main.

Pomocí funkce výběru třešně se rychle otevře žádost o přijetí změn, která poskytuje sledovatelnost a spolehlivost zásad větví. Výběr třešně se může stát na serveru, aniž byste museli stahovat větev vydané verze do místního počítače. Provádění změn, oprava konfliktů při slučování nebo provádění menších změn kvůli rozdílům mezi těmito dvěma větvemi může na serveru probíhat. Týmy můžou upravovat změny přímo z textového editoru založeného na prohlížeči nebo prostřednictvím rozšíření konfliktů při sloučení žádostí o přijetí změn pro pokročilejší prostředí.

Jakmile žádost o přijetí změn cílí na větev vydané verze, týmový kód ji znovu zkontroluje, vyhodnotí zásady větví, otestuje žádost o přijetí změn a sloučí ji. Po sloučení se oprava během několika minut nasadí na první okruh serverů. Odsud tým postupně nasadí opravu do více účtů pomocí okruhů nasazení. Když se změny nasazují pro více uživatelů, tým sleduje úspěch a ověřuje, že tato změna chybu opravuje, aniž by se vystavily žádné nedostatky nebo zpomalení. Oprava se nakonec nasadí do všech datových center Azure.

Přechod na další sprint

Během následujících tří týdnů tým dokončí přidávání funkcí do sprintu 130 a připraví se k nasazení těchto změn. Vytvoří novou větev releases/M130 vydané verze z maina nasadí ji.

V tomto okamžiku existují ve skutečnosti dvě větve v produkčním prostředí. S kruhovým nasazením, které bezpečně přináší změny do produkčního prostředí, rychlý okruh získá změny sprintu 130 a pomalé vyzváněcí servery zůstanou ve sprintu 129, zatímco nové změny se ověřují v produkčním prostředí.

Oprava hotfix změny uprostřed nasazení může vyžadovat opravu hotfix dvě různé verze, verzi sprintu 129 a verzi sprintu 130. Týmové porty a nasadí opravu hotfix do obou větví vydaných verzí. Větev 130 se znovu nasadí s opravou hotfix na okruhy, které již byly upgradovány. Větev 129 se znovu nasadí s opravou hotfix na vnější kroužky, které ještě neupgradovaly na verzi dalšího sprintu.

Po nasazení všech okruhů je stará větev sprintu 129 opuštěná, protože všechny změny, které se do větve sprintu 129 přenesou jako oprava hotfix, byly provedeny také v main. Tyto změny tedy budou také ve releases/M130 větvi.

Shrnutí

Model toku vydávání verzí je jádrem toho, jak Microsoft vyvíjí s DevOps k poskytování online služby. Tento model používá jednoduchou strategii větvení na základě kmene. Místo toho, aby se vývojáři zasekli ve frontě nasazení a čekali na sloučení změn, microsoft release flow umožňuje vývojářům pokračovat v práci.

Tento model verze také umožňuje nasadit nové funkce napříč datovými centry Azure v pravidelných intervalech, a to i přes velikost základů kódu Microsoftu a počet vývojářů, kteří na nich pracují. Model také umožňuje rychle a efektivně převést opravy hotfix do produkčního prostředí.