Jak firma Microsoft rozwija się za pomocą metodyki DevOps

Firma Microsoft stara się używać One Engineering System do tworzenia i wdrażania wszystkich produktów z solidnym procesem DevOps skoncentrowanym na przepływie rozgałęzień i wydania opartym na Git. W tym artykule opisano praktyczną implementację, sposób skalowania systemu z małych usług do ogromnych potrzeb związanych z programowaniem platformy oraz wnioski wyciągnięte z korzystania z systemu w różnych zespołach firmy Microsoft.

Przyjęcie ustandaryzowanego procesu rozwoju jest ambitnym przedsięwzięciem. Wymagania różnych organizacji firmy Microsoft różnią się znacznie, a wymagania różnych zespołów w ramach organizacji są skalowane z rozmiarem i złożonością. Aby sprostać tym zróżnicowanym potrzebom, firma Microsoft stosuje strategię rozgałęziania opartą na trunku, aby umożliwić szybkie opracowywanie produktów, ich regularne wdrażanie oraz bezpieczne wprowadzanie zmian w środowisku produkcyjnym.

Firma Microsoft używa również zasad inżynierii platformy w ramach swojego systemu inżynieryjnego One Engineering.

Przepływ procesu wydania oprogramowania Microsoft

Każda organizacja powinna uregulować standardowy proces wydawania kodu, aby zapewnić spójność między zespołami. Przepływ wydawniczy firmy Microsoft obejmuje procesy DevOps od rozwoju do wdrożenia. Podstawowe kroki przepływu wydania składają się z rozgałęzienia, przesłania, żądania pobrania i scalania.

Branch

Aby naprawić usterkę lub zaimplementować funkcję, deweloper tworzy nową gałąź poza główną gałęzią integracji. Uproszczony model rozgałęziania git tworzy te krótkotrwałe gałęzie tematów dla każdego współtworzenia kodu. Deweloperzy zatwierdzają wcześnie i unikają długotrwałych gałęzi funkcji, korzystając z flag funkcji.

Przekaż

Gdy deweloper jest gotowy do integracji i wysłania zmian do reszty zespołu, wypchnie swoją gałąź lokalną do gałęzi na serwerze i otworzy żądanie ściągnięcia. Repozytoria z kilkuset deweloperami pracującymi w wielu gałęziach używają konwencji nazewnictwa dla gałęzi serwerów, aby złagodzić zamieszanie i nadmierny rozrost gałęzi. Deweloperzy zwykle tworzą gałęzie o nazwie users/<username>/feature, gdzie <username> to ich nazwa konta.

Prośba o połączenie

Żądania ściągnięcia kontrolują scalanie gałęzi tematycznych z główną gałęzią i zapewniają spełnienie zasad gałęzi. Proces pull request kompiluje proponowane zmiany i uruchamia szybki test. Zestawy testów pierwszego i drugiego poziomu uruchamiają około 60 000 testów w mniej niż pięć minut. Nie jest to kompletna macierz testowa firmy Microsoft, ale jest wystarczająca, aby szybko zwiększać pewność pull requestów.

Następnie inni członkowie zespołu przejrzą kod i zatwierdzą zmiany. Przegląd kodu kontynuuje pracę tam, gdzie skończyły się testy automatyczne, i jest szczególnie przydatny do wykrywania problemów architektonicznych. Ręczne przeglądy kodu zapewniają, że inni inżynierowie w zespole mają wgląd w zmiany i że jakość kodu pozostaje wysoka.

Merge

Gdy pull request spełnia wszystkie wymagania kompilacji i jest zrecenzowany przez wszystkich recenzentów, gałąź tematyczna scala się z główną gałęzią integracji, a pull request zostaje ukończony.

Po połączeniu uruchamiane są inne testy akceptacyjne, co zajmuje więcej czasu. Te tradycyjne testy po zakończeniu procesu check-in przeprowadzają bardziej szczegółową walidację. Ten proces testowania zapewnia dobrą równowagę między szybkimi testami podczas przeglądu żądania pobrania a pełnym pokryciem testowym przed wydaniem.

Różnice względem GitHub Flow

Usługa GitHub Flow to popularny przepływ wydania deweloperskiego oparty na magistrali , który umożliwia organizacjom zaimplementowanie skalowalnego podejścia do usługi Git. Jednak niektóre organizacje uważają, że wraz ze wzrostem ich potrzeb muszą one odbiegać od części usługi GitHub Flow.

Na przykład często pomijana część usługi GitHub Flow polega na tym, że żądania ściągnięcia muszą zostać wdrożone w środowisku produkcyjnym na potrzeby testowania, zanim będą mogły zostać scalone z gałęzią główną. Ten proces oznacza, że wszystkie pull requesty oczekują w kolejce wdrożeniowej do scalenia.

Niektóre zespoły mają kilkaset deweloperów pracujących stale w jednym repozytorium, którzy mogą ukończyć ponad 200 pull requestów do głównej gałęzi na dzień. Jeśli każde pull request wymaga wdrożenia w wielu centrach danych Azure na całym świecie do testowania, programiści spędzają czas czekając na scalenie gałęzi, zamiast pisać oprogramowanie.

Zamiast tego zespoły firmy Microsoft kontynuują rozwijanie w gałęzi głównej i zgrupowują wdrożenia w przygotowane do czasowych wydań, zwykle zgodne z trzytygodniowym cyklem sprintu.

Szczegóły implementacji

Poniżej przedstawiono niektóre szczegóły kluczowe implementacji procesu wydania firmy Microsoft.

Strategia repozytorium Git

Różne zespoły mają różne strategie zarządzania repozytoriami Git. Niektóre zespoły przechowują większość kodu w jednym repozytorium Git. Kod jest podzielony na składniki, z których każdy znajduje się we własnym folderze na poziomie głównym. Duże składniki, zwłaszcza starsze składniki, mogą mieć wiele podskładników, które mają oddzielne podfoldery w składniku nadrzędnym.

Repozytoria uzupełniające

Niektóre zespoły zarządzają także repozytoriami pomocniczymi. Na przykład kompilowanie i wydawanie agentów i zadań, rozszerzenie programu VS Code i projekty typu open source są opracowywane w usłudze GitHub. Zmiany konfiguracji są ewidencjonowane w osobnym repozytorium. Inne pakiety, od których zależy zespół, pochodzą z innych miejsc i są używane za pośrednictwem narzędzia NuGet.

Repozytorium mono lub wiele repozytoriów

Podczas gdy niektóre zespoły wybierają jedno monolityczne repozytorium, repozytorium monolityczne, inne produkty firmy Microsoft używają podejścia obejmującego wiele repozytoriów . Skype, na przykład, ma setki małych repozytoriów, które łączą się w różnych kombinacjach w celu utworzenia wielu różnych klientów, usług i narzędzi. Zwłaszcza dla zespołów, które wykorzystują architekturę mikrousług, podejście z wieloma repozytoriami może być właściwe. Zazwyczaj starsze produkty, które rozpoczęły jako monolity, uważają podejście mono-repozytorium za najłatwiejsze przejście na Git, a ich organizacja kodu to odzwierciedla.

Gałęzie wydania

Przepływ wydań Microsoft utrzymuje główną gałąź w stanie możliwym do kompilowania przez cały czas. Deweloperzy pracują w krótkotrwałych gałęziach tematycznych, które scalają się z main. Gdy zespół jest gotowy do wydania, niezależnie od tego, czy na końcu sprintu, czy na potrzeby aktualizacji głównej, rozpoczynają nową gałąź wydania od gałęzi głównej. Gałęzie wydania nigdy nie scalają z powrotem do gałęzi głównej, więc mogą wymagać cherry-picking ważnych zmian.

Na poniższym diagramie przedstawiono krócej żyjące gałęzie w kolorze niebieskim oraz gałęzie wydaniowe w kolorze czarnym. Jedna gałąź z zatwierdzeniem, które wymaga cherry-pickingu, pojawia się na czerwono.

Zasady i uprawnienia oddziału

Zasady dotyczące gałęzi Git pomagają w egzekwowaniu struktury gałęzi wydawniczej oraz w zachowaniu porządku na gałęzi głównej. Na przykład zasady gałęzi mogą uniemożliwiać bezpośrednie wypychanie do gałęzi głównej.

Aby zachować porządek hierarchii gałęzi, zespoły używają uprawnień do blokowania tworzenia gałęzi na poziomie głównym hierarchii. W poniższym przykładzie każdy może tworzyć gałęzie w folderach, takich jak użytkownicy/, funkcje/i zespoły/. Tylko menedżerowie wersji mają uprawnienia do tworzenia gałęzi w wersjach/, a niektóre narzędzia automatyzacji mają uprawnienia do integracji/ folderu.

Przepływ pracy repozytorium Git

W strukturze repozytorium i gałęzi deweloperzy wykonują swoją codzienną pracę. Środowiska robocze różnią się w dużym stopniu w zależności od zespołu i poszczególnych osób. Niektórzy deweloperzy wolą wiersz poleceń, inni preferują Visual Studio, a jeszcze inni pracują na różnych platformach. Struktury i zasady wprowadzone w repozytoriach firmy Microsoft zapewniają solidną i spójną podstawę.

Typowy przepływ pracy obejmuje następujące typowe zadania:

Tworzenie nowej funkcji

Tworzenie nowej funkcji jest podstawą zadania dewelopera oprogramowania. Części procesu inne niż Git obejmują przeglądanie danych telemetrycznych, tworzenie projektu i specyfikacji oraz pisanie rzeczywistego kodu. Następnie deweloper rozpoczyna pracę z repozytorium, synchronizując się z najnowszym commitem w main. Gałąź główna jest zawsze kompilowalna, więc gwarantuje to dobry punkt wyjścia. Deweloper pobiera nową gałąź funkcjonalności, wprowadza zmiany kodu, zatwierdza, wypycha na serwer i uruchamia nowe żądanie zatwierdzenia.

Korzystanie z zasad gałęzi i kontroli

Po utworzeniu żądania przeniesienia zautomatyzowane systemy sprawdzają, czy kompilacja nowego kodu powstaje prawidłowo, niczego nie psuje i nie narusza żadnych reguł bezpieczeństwa ani zgodności. Ten proces nie blokuje równoległego wykonywania innych zadań.

Zasady gałęzi i kontrole mogą wymagać pomyślnej kompilacji , w tym zakończonych pomyślnie testów, wylogowania się przez właścicieli dowolnego kodu, a także kilku kontroli zewnętrznych w celu zweryfikowania zasad firmowych przed ukończeniem żądania ściągnięcia.

Integracja z usługą Microsoft Teams

Wiele zespołów konfiguruje integrację z usługą Microsoft Teams, która ogłasza nowy pull request członkom zespołu deweloperów. Właściciele dowolnego zmodyfikowanego kodu są automatycznie dodawani jako recenzenci. Zespoły firmy Microsoft często używają opcjonalnych recenzentów w kodzie, z którym ma styczność wiele osób, takich jak generowanie klientów REST i współużytkowane kontrolki, dzięki czemu zmiany te zostaną ocenione przez specjalistów.

Wdrażanie przy użyciu flag funkcji

Gdy recenzenci, właściciele kodu i automatyzacja będą zadowoleni, deweloper może ukończyć żądanie ściągnięcia. Jeśli występuje konflikt scalania, deweloper otrzymuje instrukcje dotyczące synchronizacji z konfliktem, jego rozwiązania oraz ponownego przesłania zmian. Automatyzacja jest uruchamiana ponownie w stałym kodzie, ale ludzie nie muszą ponownie się wylogować.

** Gałąź scala się z main, a nowy kod jest wdrażany w następnym sprincie lub głównym wydaniu. Nie oznacza to, że nowa funkcja pojawi się od razu. Firma Microsoft rozdziela wdrażanie i udostępnienie nowych funkcji przy użyciu flag funkcji.

Nawet jeśli funkcja wymaga nieco więcej pracy, zanim będzie gotowa do pokazania, można bez przeszkód przejść do main, gdy produkt kompiluje się i zostaje wdrożony. Po przejściu do main kod staje się częścią oficjalnej kompilacji, gdzie jest ponownie testowany, potwierdzony jako zgodny z zasadami i podpisany cyfrowo.

Przesunięcie w lewo w celu wczesnego wykrywania problemów

Ten przepływ pracy usługi Git zapewnia kilka korzyści. Po pierwsze, pracując z jedną główną gałęzią, praktycznie eliminuje się dług scalania. Po drugie, przepływ pull request zapewnia wspólny punkt wymuszania testowania, przeglądu kodu i wykrywania błędów na wczesnym etapie potoku. Ta strategia przesunięcia w lewo pomaga skrócić czas uzyskania opinii od deweloperów, ponieważ może wykrywać błędy w ciągu minut, a nie godzin lub dni. Ta strategia zapewnia również pewność refaktoryzacji, ponieważ wszystkie zmiany są stale testowane.

Obecnie produkt z ponad 200 żądaniami ściągnięcia może generować ponad 300 kompilacji w ramach integracji ciągłej każdego dnia, co stanowi ponad 500 przebiegów testowych co 24 godziny. Ten poziom testowania byłby niemożliwy bez przepływu pracy opartego na trunk-based branching i publikacji.

Wydawanie w punktach kontrolnych przebiegu

Na końcu każdego sprintu zespół tworzy gałąź wydania z głównej gałęzi. Na przykład zespół tworzy nową gałąź wydania na końcu sprintu 129 releases/M129. Następnie zespół wdraża wersję sprintu 129 do produkcji.

Po utworzeniu gałęzi z gałęzi wydania, główna gałąź pozostaje otwarta dla deweloperów w celu scalenia zmian. Te zmiany zostaną wdrożone za trzy tygodnie przy wdrożeniu następnego sprintu.

Wypuszczanie szybkich poprawek

Czasami zmiany muszą szybko trafić do środowiska produkcyjnego. Firma Microsoft zwykle nie dodaje nowych funkcji w środku sprintu, ale czasami chce szybko wprowadzić poprawkę błędu, aby umożliwić użytkownikom dalsze korzystanie. Problemy mogą być niewielkie, takie jak literówki, lub na tyle duże, aby spowodować problem z dostępnością albo incydent na stronie działającej na żywo.

Rozwiązywanie tych problemów rozpoczyna się od normalnego przepływu pracy. Deweloper tworzy gałąź z main, przekazuje kod do przeglądu i kończy pull request, aby ją scalić. Proces zawsze rozpoczyna się od wprowadzenia zmiany w main pierwszej kolejności. Umożliwia to szybkie tworzenie poprawki i weryfikowanie jej lokalnie bez konieczności przełączania się do gałęzi wydania.

Po wykonaniu tego procesu gwarantuje się również, że zmiana zostanie zmieniona na main, co jest krytyczne. Naprawienie usterki w gałęzi wydania bez przeniesienia tej zmiany z powrotem do main oznaczałoby, że usterka będzie się powtarzać podczas następnego wdrożenia, gdy gałęzie wydania sprintu 130 będą się rozgałęziać od main. Łatwo zapomnieć o aktualizacji main podczas zamieszania i stresu, które mogą wystąpić podczas awarii. Wprowadzenie zmian w pierwszej kolejności main oznacza, że zmiany są zawsze wprowadzane zarówno w gałęzi głównej, jak i w gałęzi wydania.

Funkcje usługi Git umożliwiają korzystanie z tego przepływu pracy. Aby natychmiast wprowadzić zmiany w środowisku produkcyjnym, gdy deweloper scali pull request do main, może skorzystać ze strony pull requestu, aby wybrać zmiany do gałęzi wydania. Ten proces tworzy nowe żądanie ściągnięcia, które jest przeznaczone dla gałęzi wydania, co spowoduje przywrócenie zawartości, która właśnie została scalona z gałęzią main.

Korzystanie z funkcji cherry-pick powoduje szybkie otwarcie pull requestu, zapewniając możliwość śledzenia i niezawodność polityki gałązi. Wybieranie zmian może odbywać się na serwerze bez konieczności pobierania gałęzi wydania na komputer lokalny. Wprowadzanie zmian, naprawianie konfliktów scalania lub wprowadzanie drobnych zmian z powodu różnic między dwoma gałęziami można przeprowadzać na serwerze. Zespoły mogą edytować zmiany bezpośrednio z edytora tekstu opartego na przeglądarce lub za pośrednictwem rozszerzenia do rozwiązywania konfliktów przy łączeniu Pull Requestów, dla bardziej zaawansowanego doświadczenia.

Gdy żądanie pobrania będzie dotyczyć gałęzi wydania, zespół ponownie przeanalizuje kod, oceni zasady dotyczące gałęzi, przetestuje żądanie pobrania i scali je. Po scaleniu poprawka jest wdrażana w pierwszym pierścieniu serwerów w ciągu kilku minut. Z tego miejsca zespół stopniowo wdraża poprawkę na większej liczbie kont przy użyciu pierścieni wdrażania. W miarę wdrażania zmian dla większej liczby użytkowników zespół monitoruje powodzenie i sprawdza, czy zmiana naprawia usterkę, nie wprowadzając żadnych niedociągnięć ani spowolnień. Poprawka zostanie ostatecznie wdrożona we wszystkich centrach danych platformy Azure.

Przejdź do następnego sprintu

W ciągu najbliższych trzech tygodni zespół kończy dodawanie funkcji do sprintu 130 i przygotowuje się do wdrożenia tych zmian. Tworzą nową gałąź wydania, releases/M130 z main, i wdrażają tę gałąź.

W tym momencie istnieją faktycznie dwie gałęzie w środowisku produkcyjnym. Dzięki wdrożeniu opartemu na strefach, które umożliwia bezpieczne wprowadzanie zmian w produkcji, szybka strefa otrzymuje zmiany z sprintu 130, a serwery wolnej strefy pozostają na sprincie 129, podczas gdy nowe zmiany są weryfikowane w produkcji.

Poprawka zmiany w środku wdrożenia może wymagać poprawki dwóch różnych wersji, wersji przebiegu 129 i wersji przebiegu 130. Zespół portuje i wdraża poprawkę w obu gałęziach wydania. Gałąź 130 ponownie wdraża poprawkę do pierścieni, które zostały już uaktualnione. Gałąź 129 jest ponownie wdrażana z poprawką do zewnętrznych pierścieni, które jeszcze nie zaktualizowały się do wersji następnego sprintu.

Po wdrożeniu wszystkich pierścieni, stara gałąź sprintu 129 zostaje porzucona, ponieważ wszelkie zmiany wprowadzone jako hotfix do gałęzi sprintu 129 zostały również wprowadzone w gałęzi main. W związku z tym te zmiany zostaną również wprowadzone w gałęzi releases/M130.

Podsumowanie

Model przepływu wydania jest sercem tego, jak firma Microsoft opracowuje rozwiązania DevOps w celu dostarczania usług online. Ten model używa prostej, opartej na głównym pniu strategii rozgałęziania. Zamiast trzymać deweloperów w kolejce wdrażania, czekających na scalenie swoich zmian, Microsoft Release Flow pozwala im kontynuować pracę.

Ten model wydania umożliwia również wdrażanie nowych funkcji w centrach danych platformy Azure w regularnym tempie, pomimo rozmiaru baz kodu firmy Microsoft i liczby deweloperów pracujących w nich. Model umożliwia również szybkie i wydajne wprowadzanie poprawek do środowiska produkcyjnego.