Jak firma Microsoft dostarcza oprogramowanie za pomocą metodyki DevOps

Firma Microsoft ma wieloletnie doświadczenie w dostarczaniu wysoce skalowalnych usług w środowiskach produkcyjnych. W miarę rozwoju usług i środowisk firmy Microsoft ich praktyki dostarczania również ewoluowały wraz z upływem czasu. Wielu klientów firmy Microsoft przyjęło również te efektywne praktyki dostarczania i skorzystało z nich. Następujące podstawowe zasady i procesy Metodyki DevOps mogą mieć zastosowanie do wszelkich nowoczesnych działań związanych z dostarczaniem oprogramowania.

Aby wdrożyć procesy dostarczania metodyki DevOps, firma Microsoft przyjęła następujące inicjatywy:

• Skup się na mentalności organizacyjnej i rytmie dostarczania.
• Twórz autonomiczne, odpowiedzialne zespoły, które są właścicielami, testują i dostarczają funkcje.
• Przeprowadź testy i monitoruj systemy w środowisku produkcyjnym.

Skoncentrowanie się na dostarczaniu

Szybsze dostarczanie to oczywista korzyść, którą organizacje i zespoły mogą łatwo mierzyć i doceniać. Typowy rytm DevOps obejmuje krótkie cykle sprintu z regularnymi wdrożeniami w środowisku produkcyjnym.

Obawiając się braku stabilności produktu z krótkimi sprintami, niektóre zespoły skompensowały to okresami stabilizacji na końcu swoich cykli sprintu. Inżynierowie chcieli dostarczyć jak najwięcej funkcji podczas sprintu, więc ponieśli dług testowy, który musieli spłacić podczas stabilizacji. Zespoły, które zarządzały swoim długiem podczas sprintu, musiały wspierać zespoły, które nawarstwiły dług. Dodatkowe koszty są uwzględniane w potokach dostarczania i w środowisku produkcyjnym.

Usunięcie okresu stabilizacji szybko poprawiło sposób, w jaki zespoły zarządzały swoim długiem. Zamiast przesunąć kluczowe prace konserwacyjne do okresu stabilizacji, zespoły, które zbudowały dług, musiały poświęcić następny sprint, by nadrobić zaległości względem swoich zadań związanych z długiem technicznym. Zespoły szybko nauczyły się zarządzać długiem testowym podczas sprintów. Funkcje są dostarczane, gdy są sprawdzone i warte kosztu wdrożenia.

W pełni automatyzowanie potoków

Wiele zespołów do spraw usprawnień może od razu wiele zyskać, poprzez pełną automatyzację potoków z repozytorium kodu do środowiska produkcji. Automatyzacja obejmuje potoki wydań z ciągłą integracją(CI), zautomatyzowane testowanie i ciągłe dostarczanie (CD).

Zespoły mogą uniknąć wdrażania, ponieważ jest to trudne, ale im rzadziej wdrażają, tym trudniej jest. Im więcej czasu między wdrożeniami, tym więcej problemów się gromadzi. Jeśli kod nie jest świeży, istnieje dług wdrożeniowy.

Łatwiej jest pracować w mniejszych fragmentach, dzięki częstemu wdrażaniu. Ten pomysł może wydawać się oczywisty z perspektywy czasu, ale w tym czasie może wydawać się sprzeczne. Częste wdrożenia motywują również zespoły do określania priorytetów tworzenia bardziej wydajnych i niezawodnych narzędzi wdrażania i potoków.

Korzystanie z narzędzi w firmie

Microsoft używa systemu zarządzania wydaniami, który sami opracowali, i dostarcza go klientom. Pojedyncza inwestycja zwiększa produktywność zespołu i produkty firmy Microsoft. Użycie systemu pomocniczego spowoduje zmniejszenie tempa rozwoju i efektywności dostarczania.

Autonomia zespołu i odpowiedzialność

Nie istnieją konkretne kluczowe wskaźniki wydajności (KPI), które mierzą produktywność lub efektywność zespołu ani postęp funkcji. Zespoły powinny móc zarządzać własnymi planami i listami zaległości, jednocześnie znajdować sposób na dostosowanie się do celów organizacji.

Ważne jest, aby komunikować się bezpośrednio z zespołami w celu śledzenia postępu. Narzędzia powinny ułatwić komunikację, ale konwersacja jest najbardziej przejrzystym sposobem komunikowania się.

Określanie priorytetów funkcji

Ważnym celem jest skupienie się na dostarczaniu funkcji. Harmonogramy mogą ocenić, ile zadań zespoły i osoby mogą rozsądnie ukończyć w danym okresie czasu, ale niektóre funkcje będą dostarczane wcześniej, a niektóre pojawią się później. Zespoły mogą określać priorytety pracy, aby najważniejsze funkcje trafiły do produkcji.

Korzystanie z mikrousług

Mikrousługi oferują różne korzyści techniczne, które usprawniają i upraszczają dostarczanie. Mikrousługi zapewniają również naturalne granice własności zespołu. Gdy zespół ma autonomię w zakresie inwestycji w mikrousługę, może określić priorytety sposobu wdrażania funkcji i zarządzania długiem. Zespoły mogą skupić się na planach, takich jak przechowywanie wersji, niezależnie od ogólnych usług, które zależą od mikrousługi.

Praca w głównej

Inżynierowie kiedyś pracowali w oddzielnych dziedzinach. Scalanie długu w każdej gałęzi rosło, aż inżynier próbował zintegrować swoją gałąź z gałęzią główną. Im więcej zespołów i inżynierów tam było, tym większa stała się integracja.

Aby integracja stała się szybsza, bardziej ciągła i w mniejszych fragmentach, inżynierowie teraz pracują w głównej gałęzi. Jednym z głównych powodów przejścia na Git było lekkie rozgałęzianie oferowane przez Git. Korzyścią dla inżynierii wewnętrznej było wyeliminowanie hierarchii gałęzi głębokiej i jej odpadów. Cały czas, który był przeznaczony na integrację, jest teraz przeznaczony na realizację.

Używanie flag funkcji

** Niektóre funkcje nie są całkowicie gotowe do wdrożenia sprintu, ale mogą nadal zyskać na testowaniu w środowisku produkcyjnym. Zespoły mogą scalać i wdrażać ten kod z flagami funkcji , aby włączyć funkcję dla określonych użytkowników, takich jak zespół deweloperów lub mały segment wczesnych użytkowników. Flagi funkcji kontrolują ekspozycję bez ryzyka problemów z ogólną bazą użytkowników i mogą pomóc zespołom w ustaleniu, czy i jak ukończyć tę funkcję.

Testowanie w środowisku produkcyjnym

Przesunięcie prawa do testowania w środowisku produkcyjnym pomaga zapewnić, że testy przedprodukcyjne są prawidłowe i że stale zmieniające się środowiska produkcyjne są gotowe do obsługi wdrożeń.

Testy instrumentów i metryki

Niezależnie od tego, gdzie aplikacja jest wdrażana, ważne jest, aby instrumentować wszystko. Instrumentacja nie tylko pomaga identyfikować i rozwiązywać problemy, ale może zapewnić nieocenione badania dotyczące użycia i co należy dodać dalej.

Testowanie wzorców odporności

Ryzyko złożonych wdrożeń polega na kaskadowych awariach, w których jedna awaria składnika powoduje awarię składników zależnych, a tak dalej, dopóki cały system nie ulegnie awarii. Ważne jest, aby zrozumieć, gdzie znajdują się pojedyncze punkty awarii (SPOF) i jak są one ograniczane, oraz do testowania procesów ograniczania ryzyka, zwłaszcza w środowisku produkcyjnym.

Wybieranie odpowiednich metryk

Projektowanie metryk może być trudne. Typowym błędem jest uwzględnienie zbyt wielu metryk, aby uniknąć braku czegokolwiek. Może to jednak prowadzić do ignorowania lub niewłaściwego zaufania do wartości metryk, które nie spełniają określonej potrzeby. Zamiast tego zespoły firmy Microsoft zajmują trochę czasu, aby określić dane potrzebne do mierzenia sukcesu. Zespoły mogą dodawać lub zmieniać metryki, ale zrozumienie celu od początku ułatwia ten proces.

Oprócz podstawy metryki, zespoły rozważają, co metryka powinna mierzyć. Na przykład szybkość lub przyspieszenie zysków użytkowników może być bardziej przydatną metryką niż całkowita liczba użytkowników. Metryki różnią się od projektu do projektu, ale najbardziej pomocne są te, które mogą podejmować decyzje biznesowe.

Używaj metryk do kierowania pracą

Microsoft uwzględnia metryki w przeglądach na najwyższym szczeblu przywództwa. Co sześć tygodni organizacje przedstawiają sposób ich działania na temat kondycji, działalności biznesowej, scenariuszy i telemetrii klienta. Organizacje omawiają metryki z kadrą kierowniczą i ich zespołami.

Zespoły w całej organizacji badają metryki użytkowników zaangażowanych, aby określić znaczenie ich funkcji. Zespoły nie tylko wysyłają funkcje, ale patrzą, czy i jak korzystają z nich ludzie. Zespoły używają tych metryk do dostosowywania list prac i określania, czy funkcje wymagają większej ilości pracy w celu osiągnięcia celów.

Wytyczne dotyczące dostarczania

• Droga z punktu A do punktu B nigdy nie jest prosta, a B nie jest końcem.
• Zawsze będą niepowodzenia i błędy.
• Patrz na niepowodzenia jako możliwości do nauki zmiany taktyki ukończenia danego etapu procesu.
• Wraz z upływem czasu każdy zespół rozwija swoje praktyki DevOps, opierając się na doświadczeniu i dostosowując się do zmieniających się potrzeb.
• Kluczem jest skupienie się na dostarczaniu wartości zarówno użytkownikom końcowym, jak i na samym procesie dostarczania.