Automatyzacja i informacja zwrotna: Zamykanie pętli DevOps
4 minuty czytania

W Rozdziale 5: Rozgałęzianie i ciągłe wdrażanie zbadaliśmy, w jaki sposób krótkotrwałe gałęzie i scentralizowana platforma ciągłego wdrażania (CD) pomogły nam przyspieszyć dostarczanie i zmniejszyć tarcie integracyjne. Zmiany te dramatycznie poprawiły przepływ kodu do produkcji – ale aby naprawdę zamknąć pętlę sprzężenia zwrotnego DevOps, potrzebowaliśmy więcej.

Rozdział 6, ostatni segment naszej serii DevOps dla Zwycięstwa, zagłębia się w ostatni, lecz kluczowy filar naszej transformacji: Automatyzację i Informację Zwrotną. Jeśli ciągłe wdrażanie pomogło nam szybciej wprowadzać produkty, to automatyzacja i informacja zwrotna pomogły nam szybciej się uczyć, umożliwiając nam ciągłe doskonalenie z pewnością siebie.

Dlaczego automatyzacja i informacja zwrotna mają znaczenie?

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

Systemy automatyzacji i informacji zwrotnej zapewniają zespołom:

  • Wczesne wykrywanie problemów zanim trafią do produkcji
  • Pewność co do zmian, dzięki powtarzalnej i wiarygodnej walidacji
  • Wnikliwe metryki do zrozumienia stanu systemu i wpływu na użytkowników

To różnica między lataniem na ślepo a lataniem z panelem kontrolnym.

Po usprawnieniu szybkości rozwoju, naszym kolejnym celem było zidentyfikowanie wąskich gardeł w pętli informacji zwrotnej, gdy zespół deweloperski oznaczył pracę jako „ukończoną”. Główną miarą przepływu było to, jak szybko ukończona praca mogła zostać wdrożona do produkcji.

Czas realizacji zmian i częstotliwość wdrożeń to kluczowe wskaźniki do mierzenia efektywności przepływu pracy w systemie. W naszym przypadku praca piętrzyła się na etapie kontroli jakości systemu (SQA), tworząc wąskie gardło w gotowości do wdrożenia.

Wąskie gardło Systemu QA

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

  • Testowanie integracyjne
  • Testowanie na poziomie systemu
  • Testy niefunkcjonalne (np. weryfikacja sieci, testy wydajności)
  • Artefakty walidacyjne → Raporty z testów systemowych, IQ (Kwalifikacja Instalacyjna), OQ (Kwalifikacja Operacyjna) i PQ (Kwalifikacja Wydajnościowa)

Te zadania muszą być wykonywane w kontrolowanych środowiskach, oddzielnie 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ół deweloperski.

Nasze pulpity nawigacyjne pokazały, że czas potrzebny na przeniesienie ukończonej pracy do statusu gotowości produkcyjnej wydłużał się, a coraz więcej pracy czekało na rozpoczęcie testów przez SQA. Zgodnie z naszym fundamentalnym podejściem do poprawy przepływu, był to problem, który musieliśmy rozwiązać, zanim dalsze optymalizacje DevOps mogłyby przynieść rzeczywistą wartość.

Kluczowe wyzwania w przepływie od Dev do SQA

Istniały dwa główne wyzwania w usprawnieniu przepływu pracy od etapu rozwoju do QA systemu:

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

Jeśli testowanie SQA jest głównie manualne, może rozpocząć się dopiero po pełnym opracowaniu i wdrożeniu kodu w kontrolowanych środowiskach. To określa zarówno to, kiedy testowanie może się rozpocząć, jak i ile czasu zajmie jego ukończenie. Najlepsze, co SQA może zrobić w tym modelu, to przygotować skrypty testowe z wyprzedzeniem, czekając na osiągnięcie Definicji Ukończenia (DoD) przez zespół deweloperski przed wykonaniem testów.

Automatyzacja SQA: Zmiana w strategii testowania

Jedynym sposobem na usprawnienie tego procesu jest masowe skupienie się na automatyzacji. Jednakże nie chodzi tu tylko o automatyzację wykonywania testów – wymaga to fundamentalnej zmiany w podejściu do testowania. Obejmuje to:

  • Ponowne zdefiniowanie i dostosowanie celów systemowego QA.
  • Ponowna ocena sposobu przeprowadzania walidacji w celu spełnienia zarówno wymagań dotyczących szybkości, jak i regulacyjnych.
  • Przemyślenie na nowo narzędzi i ram wspierających efektywną automatyzację.

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 ukierunkowania rozwoju.

Oznaczało to tworzenie, automatyzowanie i uruchamianie skryptów testowych w środowisku, gdzie kod deweloperski jest regularnie wdrażany, jeszcze zanim osiągnięty zostanie DoD (Definition of Done) funkcji. W tym przypadku błędy testowe nie wskazują na defekt, lecz dostarczają wczesnych informacji o tym, które części funkcjonalności nie zostały jeszcze zaimplementowane lub nie działają w pełni.

Mając wdrożone ciągłe potoki dostarczania i udoskonaloną strategię rozgałęziania, gdzie gałęzie funkcji są często łączone z główną gałęzią i wdrażane w chmurze, stworzyliśmy dedykowane środowisko, w którym te zautomatyzowane testy systemowe mogły działać w sposób ciągły.

Szybsze informacje zwrotne dzięki automatycznym testom

Takie podejście pozwoliło działowi QA systemu na wcześniejsze rozpoczęcie walidacji, co przyspieszyło testowanie i zapewniło szybsze informacje zwrotne zespołowi deweloperskiemu. Zamiast czekać, aż funkcja zostanie oznaczona jako ukończona, testowanie odbywa się teraz równolegle z rozwojem, dając zespołom wgląd w czasie rzeczywistym w to, co działa, a co jeszcze 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 na rzecz testowania API stało się priorytetem.
  • Przejście na rozwój sterowany zachowaniem (BDD) → Tworzenie skryptów testowych wraz z historyjkami użytkownika do włączenia w kryteria akceptacji.

Chociaż pełne wdrożenie BDD od początku tworzenia historyjek użytkownika jest nadal w toku, poprawiliśmy współpracę między zespołami SQA a zespołami deweloperskimi, dostosowując je na wczesnym etapie procesu.

Dopasowanie SQA do rozwoju: Wpływ topologii zespołów

Aby to osiągnąć, zastosowaliśmy podejście zespołu specjalistów z Team Topologies, tworząc zespół SQA jako zespół wspierający. Zamiast być oddzielną, późniejszą funkcją testowania, członkowie zespołu SQA ściśle współpracowali z działem rozwoju, aby zapewnić, że tworzenie automatycznych przypadków testowych rozpoczyna się wcześnie i trwa nieprzerwanie w miarę rozwoju kodu.

Kluczowym warunkiem wstępnym dla tego podejścia jest posiadanie środowiska testowego Cloud-based do przeprowadzania testów na poziomie systemu przed przejściem do środowisk kontrolowanych. Chociaż wiąże się to z dodatkowymi kosztami infrastruktury, znacznie przyspiesza przepływ pracy od etapu rozwoju do SQA, co znacznie szybciej przygotowuje system do wdrożenia.

Podsumowanie

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

Podsumowanie serii

Kończąc naszą serię DevOps dla zwycięstwa, zastanawiamy się nad drogą od chaosu narzędziowego i procesów manualnych do bardziej połączonej, zautomatyzowanej i wzmocnionej organizacji. Od zdefiniowania naszego Trójkąta DevOps w Rozdziale 1 po ustanowienie nauki opartej na informacji zwrotnej w Rozdziale 6, każdy rozdział opierał się na poprzednim, aby napędzać znaczącą transformację.

Oto szybkie podsumowanie naszej serii:

Ta transformacja jest w toku – ale dzięki zbudowanym przez nas fundamentom jesteśmy lepiej przygotowani niż kiedykolwiek, aby dostarczać wartość szybciej, bezpieczniej i inteligentniej.

Dziękujemy za towarzyszenie nam w tej podróży. Mamy nadzieję, że nasza historia zainspiruje Państwa własną ewolucję DevOps.

Bądź ciekawy. Bądź iteracyjny. A co najważniejsze, pozostań w kontakcie.

Subskrybuj blog Freyr