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. Verzovací tok Microsoftu zahrnuje procesy DevOps od vývoje až po vydání. Základní kroky procesu vydávání se skládají z vytvoření větve, odeslání, pull requestu a sloučení.

Branch

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 provádějí rané commity a vyhýbají se dlouhotrvajícím větvím funkcí pomocí feature flags.

Posunout

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

Žádosti o přijetí změn kontrolují sloučení tematických větví do hlavní větve a zajišťují, že jsou dodrženy 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ě spouští přibližně 60 000 testů za méně než pět minut. Nejedná se o kompletní testovací matici Microsoftu, ale postačí k rychlému získání jistoty při příkazech k 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á.

Merge

Jakmile žádost o přijetí změn splňuje všechny zásady sestavení a hodnotící ji schválili, branch tématu je sloučena do hlavní integrační větve a žádost o přijetí změn je dokončena.

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í odchýlit od některých prvků postupu 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ě pro nasazení a 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 pokračují ve vývoji v hlavní větvi a seskupují nasazení do plánovaných verzí, obvykle v souladu se třítýdenním cyklem sprintu.

Podrobnosti implementace

Zde jsou některé klíčové podrobnosti implementace procesu vydání 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 zapisují 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 repo nebo multi repo

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 multi-repo přístup správným přístupem. Starší produkty, které začaly jako monolity, obvykle považují monorepo přístup za nejjednodušší způsob přechodu na Git a jejich organizace kódu to odráží.

Vydávací větve

Tok verze Microsoftu udržuje hlavní větev vždy sestavitelnou. Vývojáři pracují v krátkodobých větvích zaměření, které jsou slučovány do main. Když je tým připraven k vydání, ať už na konci sprintu nebo při hlavní aktualizaci, vytvoří novou větev vydání z hlavní větve. Vydávací větve se nikdy nespojí zpět s hlavní větví, takže mohou vyžadovat c0>cherry-pick důležitých změn.

Následující diagram znázorňuje krátkodobé větve modře a vydávací větve černě. 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í Git pomáhají vynucovat strukturu větve vydání a udržovat hlavní větev čistou. Například zásady větví můžou zabránit přímému pushování do hlavní větve.

Týmy používají oprávnění k blokování vytváření větví na kořenové úrovni hierarchie, aby udržely pořádek v hierarchii větví. V následujícím příkladu můžou všichni vytvářet větve ve složkách, jako users/, features/, a teams/. Pouze správci verzí mají oprávnění vytvářet větve v releases/, a některé nástroje pro automatizaci mají oprávnění k integrations/ 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ší týmem a osobou. 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 odhlásí novou větev funkcí, provede změny kódu, commituje, pushne na server a spustí nový pull request.

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

Při vytvoření žádosti o přijetí změn automatizované systémy kontrolují, že nový kód se úspěšně sestaví, nezpůsobí žádné chyby a neporuší žádné bezpečnostní ani regulační zásady. 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ů, schválení vlastníky jakéhokoli kódu, kterých se dotkne, a několik externích kontrol k ověření firemních zásad před dokončením žádosti o přijetí změn.

Integrace s aplikací 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 upraveného kódu se automaticky přidají jako revizoři. Týmy Microsoftu často používají volitelné recenzenty pro kód, který používá mnoho lidí, jako je generování klienta REST a sdílené ovládací prvky, aby se na tyto změny podívali odborníci.

Nasazení pomocí feature flagů

Jakmile jsou kontroloři, vlastníci kódu a automatizace spokojení, vývojář může pull request dokončit. Pokud dojde ke konfliktu při sloučení, vývojář dostane pokyny, jak se s konfliktem synchronizovat, jak ho opravit a jak změny znovu odeslat. 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ředvedení, je bezpečné přejít na main, pokud 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é, pull request proces poskytuje společný bod pro vynucení testování, kontroly kódu a detekce chyb v rané fázi procesu. 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 kmenového větvení a vydávání.

Vydání při milnících sprintu

Na konci každého sprintu vytvoří tým větev pro vydání 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 odvětvení z vydávací větve zůstane hlavní větev otevřená pro vývojáře, aby mohli změny slučovat. Tyto změny se nasadí za tři týdny během dalšího nasazení ve sprintu.

Uvolnit hotfixy

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.

Řešení těchto problémů začíná běžným pracovním postupem. Vývojář vytvoří větev z main, nechá si zkontrolovat kód a dokončí pull request pro sloučení. Proces vždy začíná provedením změny jako první v main. 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 v release větvi bez toho, aby se změna vrátila zpět do main, by představovala, že se chyba objeví znovu během příštího nasazení, když se release odvětví z main během sprintu 130. Během zmatení a stresu, které mohou vzniknout během výpadku, je snadné zapomenout aktualizovat main . Přenesení změn do main nejprve znamená, že změny jsou vždy jak v hlavní větvi, tak ve větvi pro vydání.

Funkce Gitu umožňuje tento pracovní postup. Pokud chce vývojář okamžitě přenést změny do produkčního prostředí, může po sloučení pull requestu do main použít stránku pull requestu k výběru změn do vydané větve. 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 cherry-pick se rychle otevře pull request, který poskytuje sledovatelnost a spolehlivost politik větví. Cherry-picking může probíhat přímo na serveru bez nutnosti stahovat větev vydání 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 mohou provádět úpravy přímo z textového editoru založeného na prohlížeči nebo prostřednictvím rozšíření konfliktů při sloučení pull requestů 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ě nasazuje opravu pro 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 uvolňovací větev releases/M130 z main a nasadí ji.

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

Úprava změny pomocí hotfixu uprostřed nasazení může vyžadovat dvě různé hotfixy, release sprintu 129 a release sprintu 130. Tým portuje a nasadí opravu hotfix do obou větví verzí určených k vydání. Větev 130 se znovu nasadí s opravou hotfix na okruhy, které již byly upgradovány. Větev 129 se znovu nasadí hotfixem na vnější okruhy, které ještě nebyly upgradovány na verzi dalšího sprintu.

Jakmile jsou všechny okruhy nasazeny, je stará větev sprintu 129 opuštěna, protože všechny změny přenesené do větve sprintu 129 jako oprava typu hotfix byly provedeny také ve 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 za účelem poskytování online služeb. 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 jim umožňuje 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 aktualizace hotfix do produkčního prostředí.