Automatyzacja i informacje zwrotne: Zamknięcie pętli DevOps
4 min czytania

W Rozdziale 5: Gałęzie a ciągłe wdrażanie omówiliśmy, jak krótkotrwałe gałęzie i zcentralizowana platforma ciągłego wdrażania (CD) pomogły nam przyspieszyć dostarczanie oprogramowania i zmniejszyć problemy z integracją. Zmiany te drastycznie usprawniły przepływ kodu do środowiska produkcyjnego – aby jednak w pełni domknąć pętlę zwrotną metodyki DevOps, potrzebowaliśmy czegoś więcej.

Rozdział 6, ostatni element naszej serii DevOps for the Win, zagłębia się w ostatni, ale kluczowy filar naszej transformacji: automatyzację i informacje zwrotne. O ile ciągłe wdrażanie pomagające nam szybciej publikować zmiany, o tyle automatyzacja i informacje zwrotne pomogły nam szybciej się uczyć, umożliwiając ciągłe doskonalenie z pełnym zaufaniem.

Dlaczego automatyzacja i informacje zwrotne mają znaczenie

W każdej transformacji DevOps szybkość bez bezpieczeństwa to przepis na katastrofę. W miarę wzrostu częstotliwości wdrażania potrzeba automatycznych kontroli i informacji zwrotnych w czasie rzeczywistym stała się kluczowa – nie tylko dla zapewnienia jakości, ale także dla wzmocnienia pozycji zespołów i podejmowania decyzji.

Systemy automatyzacji i informacji zwrotnych zapewniają zespołom:

  • Wczesne wykrywanie problemów, zanim dotrą one do środowiska produkcyjnego
  • Pewność co do wprowadzanych zmian dzięki powtarzalnej i niezawodnej walidacji
  • Wnikliwe wskaźniki pozwalające zrozumieć kondycję systemu i jego wpływ na użytkowników

To różnica między lotem na ślepo a lotem z pełnym panelem wskaźników.

Po poprawie dynamiki rozwoju kolejnym krokiem było zidentyfikowanie wąskich gardeł w pętli informacji zwrotnej, gdy zespół programistyczny oznaczył pracę jako „ukończoną”. W tym przypadku główną miarą przepływu była szybkość, z jaką ukończona praca mogła zostać wdrożona do środowiska produkcyjnego.

Czas realizacji zmian (Lead Time for Change) oraz częstotliwość wdrażania to kluczowe wskaźniki mierzące efektywność przepływu pracy w systemie. W naszym przypadku praca gromadziła się na etapie systemowego zapewnienia jakości (SQA), co tworzyło wąskie gardło w gotowości do wdrożenia.

Wąskie gardło w systemowym zapewnieniu jakości

W większości obszarów, w tym w naszym, wymagania regulacyjne narzucają szereg działań walidacyjnych mających na celu zapewnienie jakości oprogramowania. Obejmuje to:

  • Testy integracyjne
  • Testy na poziomie systemu
  • Testy niefunkcjonalne (np. weryfikacja sieci, testy wydajnościowe)
  • Artefakty walidacyjne → Raporty z testów systemowych, IQ (Kwalifikacja Instalacji), OQ (Kwalifikacja Operacyjna) oraz PQ (Kwalifikacja Procesu)

Zadania te muszą być wykonywane w kontrolowanych środowiskach, oddzielnych od środowiska programistycznego, aby zapewnić zgodność z przepisami. Z tego powodu zespół ds. systemowego zapewnienia jakości działa niezależnie, a testy mogą się rozpocząć dopiero po zakończeniu prac przez zespół programistyczny.

Nasze panele wskaźników pokazywały, że czas potrzebny na przeniesienie ukończonej pracy do statusu gotowości produkcyjnej rósł, a coraz więcej zadań czekało na rozpoczęcie testów przez SQA. Zgodnie z naszym fundamentalnym podejściem do poprawy przepływu, był to problem, którym musieliśmy się zająć, zanim jakiekolwiek dalsze optymalizacje DevOps mogły przynieść realną wartość.

Kluczowe wyzwania w przepływie pracy od etapu programowania do SQA

W usprawnianiu przepływu pracy z działu programistycznego do systemowego QA napotkano dwa główne wyzwania:

  1. Opóźnienie w rozpoczynaniu zadań SQA
  2. Tempo, w jakim można przeprowadzać walidację systemu

Jeśli testowanie SQA ma charakter głównie manualny, może ono rozpocząć się dopiero wtedy, gdy kod zostanie w pełni napisany i wdrożony w kontrolowanych środowiskach. Decyduje to zarówno o tym, kiedy testy mogą się zacząć, jak i o tym, ile czasu zajmie ich ukończenie. W tym modelu SQA może co najwyżej przygotować skrypty testowe z wyprzedzeniem i czekać na osiągnięcie kryteriów ukończenia (ang. Definition of Done – DoD) przez zespół programistyczny przed przystąpieniem do wykonywania testów.

Automatyzacja SQA: zmiana strategii testowania

Jedynym sposobem na poprawę tego przepływu jest mocne postawienie na automatyzację. Nie chodzi tu jednak wyłącznie o automatyzację samego wykonywania testów – wymaga to fundamentalnej zmiany w podejściu do testowania. Obejmuje to:

  • Ponowne zdefiniowanie i dostosowanie celów systemowego QA.
  • Przeanalizowanie na nowo sposobu przeprowadzania walidacji, aby spełnić zarówno wymogi dotyczące prędkości, jak i przepisy regulacyjne.
  • Spojrzenie z nowej perspektywy na narzędzia i struktury niezbędne do skutecznego wspierania automatyzacji.

Jedną z kluczowych zmian w sposobie myślenia było przejście od testowania potwierdzającego, że opracowane oprogramowanie działa, do testowania ukierunkowanego na wspieranie procesu tworzenia oprogramowania.

Oznaczało to tworzenie, automatyzację i uruchamianie skryptów testowych w środowisku, do którego kod programistyczny jest regularnie przesyłany, jeszcze zanim funkcja osiągnie kryteria DoD. W tym przypadku niepowodzenia testów nie oznaczają defektu, lecz dają wczesny wgląd w to, które elementy funkcjonalności nie zostały jeszcze zaimplementowane lub w pełni ukończone.

Dzięki wdrożeniu potoków ciągłego dostarczania i udoskonalonej strategii tworzenia gałęzi (gdzie gałęzie funkcji są często łączone z gałęzią główną i wdrażane w chmurze), skonfigurowaliśmy dedykowane środowisko, w którym te zautomatyzowane testy systemowe mogły działać w sposób ciągły.

Szybsza informacja zwrotna dzięki zautomatyzowanemu testowaniu

Takie podejście pozwoliło systemowemu QA na wcześniejsze rozpoczęcie walidacji, dzięki czemu testowanie stało się szybsze, a zespół programistyczny otrzymywał informacje zwrotne w krótszym czasie. Zamiast czekać, aż funkcja zostanie oznaczona jako ukończona, testy są obecnie przeprowadzane równolegle z procesem programowania, dając zespołom bieżący wgląd w to, co działa, a co wymaga jeszcze dokończenia.

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

  • Odejście od automatyzacji opartej na interfejsie użytkownika na rzecz priorytetowego traktowania testów API.
  • Przejście na programowanie sterowane zachowaniem (BDD) – tworzenie skryptów testowych równolegle z historiami użytkowników, tak aby były one częścią kryteriów akceptacji.

Chociaż pełne wdrożenie BDD od samego początku tworzenia historii użytkownika jest nadal w toku, poprawiliśmy współpracę między SQA a zespołami programistycznymi, uzgadniając ich działania na wczesnym etapie procesu.

Dopasowanie SQA do procesów programistycznych: wpływ koncepcji Team Topologies

Aby to osiągnąć, zastosowaliśmy podejście oparte na zespołach specjalistycznych z koncepcji Team Topologies, wyznaczając zespół SQA jako zespół wspierający. Zamiast funkcjonować jako osobna jednostka testowa na dalszym etapie, członkowie zespołu SQA zostali ściśle powiązani z działem programistycznym, aby zapewnić, że tworzenie automatycznych przypadków testowych zaczyna się wcześnie i trwa nieprzerwanie w miarę pisania kodu.

Kluczowym warunkiem wstępnym dla takiego podejścia jest posiadanie środowiska testowego typu Cloud-based do uruchamiania testów na poziomie systemu przed przejściem do środowisk kontrolowanych. Choć wiąże się to z dodatkowymi kosztami infrastruktury, znacznie usprawnia przepływ pracy od etapu programowania do SQA, sprawiając, że kod jest gotowy do wdrożenia znacznie szybciej.

Podsumowanie

To udoskonalenie wzmacnia podstawową zasadę DevOps – podejście do transformacji poprzez uwzględnienie kompetencji w zakresie narzędzi, architektury i ludzi przy jednoczesnym skupieniu się na przepływie. Dzięki automatyzacji systemowego QA, wcześniejszej integracji testów w cyklu życia projektu oraz skuteczniejszemu dopasowaniu zespołów udało nam się znacznie ograniczyć wąskie gardło między programowaniem a walidacją systemu, co przyspieszyło pętle informacji zwrotnej i ułatwiło wdrażanie.

Podsumowanie serii

Kończąc naszą serię DevOps for the Win, podsumowujemy drogę od chaosu narzędziowego i procesów manualnych do bardziej spójnej, zautomatyzowanej i samorzutnej organizacji. Od zdefiniowania naszego trójkąta DevOps w rozdziale 1 po ustanowienie nauki opartej na informacjach zwrotnych w rozdziale 6 – każdy rozdział stanowił kontynuację poprzedniego, napędzając istotną transformację.

Oto krótkie podsumowanie naszej serii:

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

Dziękujemy za śledzenie tej drogi wraz z nami. Mamy nadzieję, że nasza historia zainspiruje Waszą własną ewolucję DevOps.

Bądźcie ciekawe/-i. Działajcie iteracyjnie. I co najważniejsze, pozostańcie w kontakcie.

Subskrybuj bloga Freyr