Automatyzacja i informacje zwrotne: Zamykanie pętli DevOps
4 min read

W Rozdział 5: Rozgałęzianie i ciągłe wdrażaniezbadaliśmy, w jaki sposób krótkotrwałe gałęzie i scentralizowana platforma ciągłego wdrażania (CD) pomogły us przyspieszyć dostarczanie i zmniejszyć tarcia związane z integracją. Zmiany te znacznie poprawiły przepływ kodu do produkcji - ale aby naprawdę zakończyć pętlę sprzężenia zwrotnego DevOps, potrzebowaliśmy czegoś więcej.

Rozdział 6, ostatni segment naszej serii DevOps for the Win, poświęcony jest ostatniemu, ale kluczowemu filarowi naszej transformacji: Automatyzację i informacje zwrotne. Jeśli ciągłe wdrażanie pomogło us szybciej wydawać, to automatyzacja i informacje zwrotne pomogły us szybciej się uczyć, umożliwiając us ciągłe doskonalenie z pewnością siebie.

Dlaczego automatyzacja i informacje zwrotne mają znaczenie

W każdej transformacji DevOps szybkość bez bezpieczeństwa jest receptą na katastrofę. Wraz ze wzrostem częstotliwości naszych wdrożeń, potrzeba zautomatyzowanych kontroli i informacji zwrotnych w czasie rzeczywistym stała się krytyczna - nie tylko dla zapewnienia jakości, ale także dla wzmocnienia zespołu i podejmowania decyzji.

Automatyzacja i systemy informacji zwrotnej zapewniają zespołom:

  • Wczesne wykrywanie problemów, zanim reach produkcji
  • Pewność zmian dzięki powtarzalnej, wiarygodnej walidacji
  • Wnikliwe metryki pozwalające zrozumieć kondycję systemu i wpływ na użytkownika

To różnica między lataniem na ślepo a lataniem z deską rozdzielczą.

Po wprowadzeniu ulepszeń w zakresie szybkości rozwoju, skupiliśmy się na zidentyfikowaniu wąskich gardeł w pętli sprzężenia zwrotnego, gdy zespół programistów oznaczył pracę jako "wykonaną". W tym przypadku główną miarą przepływu było to, jak szybko ukończona praca mogła zostać wdrożona do produkcji.

Czas wprowadzania zmian (Lead Time for Change) i częstotliwość wdrożeń (Deployment Frequency) to kluczowe wskaźniki mierzące, jak sprawnie praca przechodzi przez system. W naszym przypadku praca gromadziła się na etapie QA systemu (SQA), tworząc wąskie gardło w gotowości do wdrożenia.

Wąskie gardło QA systemu

W większości dziedzin, w tym w naszej, wymagania regulacyjne narzucają szereg działań walidacyjnych w celu zapewnienia jakości oprogramowania. Obejmuje to:

  • Testowanie integracji
  • Testowanie na poziomie systemu
  • Testowanie niefunkcjonalne (np. weryfikacja sieci, testowanie wydajności)
  • Artefakty walidacji → Raporty z testów systemu, IQ (kwalifikacja instalacji), OQ (kwalifikacja operacyjna) i PQ (kwalifikacja wydajności)

Zadania te muszą być wykonywane w kontrolowanych środowiskach, oddzielonych od rozwoju, aby zapewnić zgodność. Z tego powodu zespół QA systemu działa niezależnie, a testowanie może rozpocząć się dopiero po zakończeniu pracy przez zespół programistów.

Nasze pulpity nawigacyjne pokazywały, że czas potrzebny na przeniesienie ukończonej pracy do stanu gotowości produkcyjnej wydłużał się, a więcej pracy czekało na rozpoczęcie testów przez SQA. Zgodnie z naszym podstawowym podejściem do poprawy przepływu, była to kwestia, którą musieliśmy się zająć, zanim jakiekolwiek dalsze optymalizacje DevOps mogły przynieść rzeczywistą wartość.

Kluczowe wyzwania w przepływie od Dev do SQA

Istniały dwa główne wyzwania związane z poprawą przepływu pracy z działu rozwoju do QA systemu:

  1. Opóźnienie w rozpoczęciu zadań SQA
  2. Szybkość, z jaką można przeprowadzić walidację systemu

Jeśli testowanie SQA jest głównie ręczne, może rozpocząć się dopiero po pełnym opracowaniu kodu i wdrożeniu go w kontrolowanych środowiskach. Określa to zarówno czas rozpoczęcia testów, jak i czas ich trwania. Najlepsze, co SQA może zrobić w tym modelu, to przygotować skrypty testowe z wyprzedzeniem, czekając na osiągnięcie przez zespół programistów definicji ukończenia (DoD) przed wykonaniem testów.

Automatyzacja SQA: Zmiana strategii testowania

Jedynym sposobem na usprawnienie tego przepływu jest skupienie się na automatyzacji. Nie chodzi jednak tylko o automatyzację wykonywania testów - wymaga to fundamentalnej zmiany w podejściu do testowania. Obejmuje to:

  • Przedefiniowanie i dostosowanie celów QA systemu.
  • Ponowna ocena sposobu przeprowadzania walidacji w celu spełnienia zarówno wymogów dotyczących szybkości, jak i wymogów regulacyjnych.
  • Ponowne wyobrażenie sobie narzędzi i ram potrzebnych do skutecznego wspierania automatyzacji.

Jedną z kluczowych zmian w sposobie myślenia było przejście od testowania w celu potwierdzenia, że opracowane oprogramowanie działa → do testowania w celu kierowania rozwojem.

Oznaczało to utworzenie, zautomatyzowanie i uruchomienie skryptów testowych w środowisku, w którym kod programistyczny jest regularnie przesyłany, nawet przed osiągnięciem DoD funkcji. W tym przypadku niepowodzenia testów nie wskazują na defekt, ale raczej zapewniają wczesny wgląd w to, które części funkcjonalności nie zostały jeszcze zaimplementowane lub nie są w pełni funkcjonalne.

Dzięki potokom ciągłego dostarczania i dopracowanej strategii rozgałęziania, w której gałęzie funkcji są często scalane z główną gałęzią i wdrażane w chmurze, skonfigurowaliśmy dedykowane środowisko, w którym te zautomatyzowane testy systemowe mogą działać w sposób ciągły.

Szybsza informacja zwrotna dzięki zautomatyzowanym testom

Podejście to pozwoliło systemowi QA na wcześniejsze rozpoczęcie walidacji, przyspieszając testowanie i dostarczając szybszych informacji zwrotnych zespołowi programistów. Zamiast czekać, aż funkcja zostanie oznaczona jako ukończona, testowanie przebiega teraz równolegle z rozwojem, dając zespołom wgląd w czasie rzeczywistym w to, co działa, a co nadal wymaga ukończenia.

Jednocześnie automatyzacja przypadków testowych wymagała ponownego przemyślenia strategii testowania.

  • Odejście od automatyzacji opartej na interfejsie użytkownika → testowanie API stało się priorytetem.
  • Przejście na Behavior-Driven Development (BDD) → Tworzenie skryptów testowych wraz z historyjkami użytkownika, które zostaną uwzględnione w kryteriach akceptacji.

Podczas gdy pełne przyjęcie BDD od początku tworzenia historii użytkownika jest nadal w toku, poprawiliśmy współpracę między zespołami SQA i programistycznymi, dostosowując je na wczesnym etapie procesu.

Dostosowanie SQA do rozwoju: Wpływ topologii zespołu

Aby to osiągnąć, zastosowaliśmy specjalistyczne podejście zespołowe Team Topologies, tworząc zespół SQA jako zespół wspomagający. Zamiast być oddzielną, niższą funkcją testowania, członkowie zespołu SQA zostali ściśle dostosowani do rozwoju, aby zapewnić, że tworzenie przypadków testowych automatyzacji rozpoczyna się wcześnie i działa w sposób ciągły w miarę rozwoju kodu.

Kluczowym warunkiem wstępnym dla tego podejścia jest posiadanie cloud-based środowiska testowego do przeprowadzania testów na poziomie systemu przed przejściem do kontrolowanych środowisk. Wiąże się to z dodatkowymi kosztami infrastruktury, ale znacznie zwiększa przepływ pracy z działu rozwoju do działu SQA, dzięki czemu wdrożenie jest gotowe znacznie szybciej.

Wnioski

To ulepszenie wzmacnia podstawową zasadę DevOps - podejście do transformacji poprzez uwzględnienie narzędzi, architektury i kompetencji ludzi, przy jednoczesnym skupieniu się na przepływie. Automatyzując QA systemu, integrując testowanie na wcześniejszym etapie cyklu i skuteczniej dostosowując zespoły, znacznie zmniejszyliśmy wąskie gardło między rozwojem a walidacją systemu, przyspieszając pętle informacji zwrotnych i usprawniając wdrożenia.

Zakończenie serii

Kończąc naszą serię DevOps for the Win, zastanawiamy się nad podróżą od chaosu narzędziowego i ręcznych procesów do bardziej połączonej, zautomatyzowanej i wzmocnionej organizacji. Od zdefiniowania naszego trójkąta DevOps w rozdziale 1 po ustanowienie uczenia się opartego na informacjach zwrotnych w rozdziale 6, każdy rozdział opierał się na poprzednim, aby napędzać znaczącą transformację.

Oto krótkie podsumowanie naszej serii:

Ta transformacja trwa - ale dzięki zbudowanym przez nas fundamentom jesteśmy lepiej przygotowani niż kiedykolwiek, aby dostarczać wartość szybciej, bezpieczniej i mądrzej.

Dziękujemy za śledzenie tej podróży. Mamy nadzieję, że nasza historia zainspiruje Cię do ewolucji DevOps.

Bądź ciekawy. Działaj iteracyjnie. A co najważniejsze, pozostań w kontakcie.

Subskrybuj blog Freyr