Jak firma Microsoft dostarcza oprogramowanie za pomocą metodyki DevOps

Firma Microsoft ma wieloletnie doświadczenie w dostarczaniu wysoce skalowalnych usług w środowiskach produkcyjnych. Wraz z rozwojem usługi firmy Microsoft i środowisk 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 myślenia organizacyjnego i cyklu dostarczania.
• Tworzą autonomiczne, rozliczane zespoły, które są właścicielami, testować i dostarczać funkcje.
• Przenieś w prawo do systemów testowych i monitorowych w środowisku produkcyjnym.

Skoncentrowanie się na dostarczaniu

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

Obawiając się braku stabilności produktu z krótkimi przebiegami, niektóre zespoły zrekompensowały okresy stabilizacji na końcu cykli sprintu. Inżynierowie chcieli wysłać jak najwięcej funkcji podczas przebiegu, więc ponieśli dług testowy, że musieli zapłacić podczas stabilizacji. Zespoły, które zarządzały swoim długiem podczas sprintu, musiały wspierać zespoły, które zbudował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 odepchnąć kluczową pracę konserwacyjną do okresu stabilizacji, zespoły, które zbudowały dług, musiały wydać następny sprint nadrobić zaległości do swoich celów zadłużenia. Zespoły szybko nauczyły się zarządzać długiem testowym podczas przebiegów. Funkcje są dostarczane, gdy są sprawdzone i warte kosztu wdrożenia.

W pełni automatyzowanie potoków

Większość zespołów usprawnień może natychmiast zyskać, to w pełni zautomatyzować potoki z repozytorium kodu do środowiska produkcyjnego. 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. Tym więcej czasu między wdrożeniami, tym więcej problemów się stosuje. Jeśli kod nie jest świeży, istnieje dług wdrożeniowy.

Łatwiej jest pracować w mniejszych fragmentach, często wdrażając. 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

Firma Microsoft korzysta z kompilowania systemu zarządzania wydaniami i dostarcza go klientom. Pojedyncza inwestycja zwiększa produktywność zespołu i produkty firmy Microsoft. Użycie systemu pomocniczego spowoduje wyłączenie rozwoju i szybkości dostarczania.

Autonomia zespołu i odpowiedzialność

Nie ma konkretnych kluczowych wskaźników postępu (KPI) mierzą produktywność lub wydajność zespołu lub czy funkcja jest na dobrej drodze. Zespoły muszą mieć możliwość zarządzania własnymi planami i listami prac, jednocześnie znajdując sposób dopasowania 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 zespołów i osób może rozsądnie ukończyć w danym okresie czasu, ale niektóre funkcje będą dostarczane wcześniej, a niektóre z nich pojawią się później. Zespoły mogą określać priorytety pracy, dzięki czemu najważniejsze funkcje sprawiają, że są one przeznaczone do środowiska produkcyjnego.

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 używali do pracy w oddzielnych gałęziach. 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 pracują teraz w głównej gałęzi. Jednym z wielkich powodów przejścia do usługi Git było uproszczone rozgałęzianie ofert 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ł używany do integracji, jest teraz wlewany do dostawy.

Używanie flag funkcji

Niektóre funkcje nie są całkowicie gotowe do wdrożenia przebiegu, ale nadal mogą korzystać z testowania 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 produkcji

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 uważają, czego potrzebują do mierzenia metryki. 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.

Praca przy użyciu metryk

Firma Microsoft zawiera metryki z przeglądami na najwyższych poziomach 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

• Nigdy nie jest to prosta linia, aby dostać się z A do B, ani b koniec.
• Zawsze będą niepowodzenia i błędy.
• Wyświetlanie zwrotów jako możliwości uczenia się zmian taktyki ukończenia danego 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.