3 min read
W Rozdział 4: Śledzenie tego, co ważne - wskaźniki KPI i pulpity nawigacyjnezbadaliśmy, w jaki sposób wizualizacja przepływu pracy i zdefiniowanie odpowiednich wskaźników KPI pomogło us wykryć wąskie gardła i dostosować nasze zespoły do dostarczania wartości. Mając lepszy wgląd w nasz potok DevOps, zaczęliśmy zadawać głębsze pytania - nie tylko o to, gdzie były wąskie gardła, ale dlaczego tak się działo.
W rozdziale 5 zagłębiamy się w jedną z najważniejszych zmian na poziomie technicznym i procesowym w naszej podróży transformacyjnej: udoskonalenie naszej strategii rozgałęziania i umożliwienie ciągłego wdrażania. Zmiany te odegrały kluczową rolę w rozwiązaniu utrzymujących się opóźnień między rozwojem a produkcją.
Identyfikacja nowego wąskiego gardła
Analiza przepływu pracy i identyfikacja wąskich gardeł, w których gromadzi się praca, była kluczowym aspektem naszej transformacji DevOps. To skupienie się na przepływie jest podstawą tego, jak zastosowaliśmy trójkąt DevOps - narzędzia, architekturę i ludzi - w celu osiągnięcia szybszego i bardziej niezawodnego dostarczania.
Gdy poczyniliśmy postępy w zakresie poprawy testowalności poprzez zwiększenie pokrycia testami jednostkowymi i automatyzacją testów, stwierdziliśmy, że jakość kodu poprawiała się, ale wąskie gardło wciąż znajdowało się w fazie testowania scrumowego. Pomimo postępów w automatyzacji testów, praca wciąż się piętrzyła, a wąskie gardło przeniosło się z rozwoju na testowanie na poziomie systemu. Kluczowe wskaźniki wydajności (KPI) pokazywały, że ilość pracy w toku przypadająca na zespół w fazie rozwoju malała, ale kod wciąż utknął w punkcie przejścia do testowania systemu. To opóźnienie ostatecznie uniemożliwiło us osiągnięcie płynnego przepływu.
Przyczyna źródłowa: Strategia rozgałęzień i opóźnione fuzje
Analiza wykazała, że główna przyczyna zaległości leżała w naszej strategii rozgałęziania. Programiści i testerzy tworzyli gałęzie funkcji z głównej gałęzi podczas uruchamiania nowych funkcji. W miarę rozwoju kodu inżynierowie przenosili swoje zmiany do zdalnych gałęzi funkcji, aby scalić swoją pracę z innymi. Kod ten nie był jednak wystarczająco często scalany z główną gałęzią.
Potoki CI/CD zostały skonfigurowane w głównej gałęzi, uruchamiając testy automatyczne i wdrażając je w chmurze, a następnie przeprowadzając testy regresji. Ponieważ jednak najnowsze zmiany nie były regularnie wypychane do głównej gałęzi, potoki wykonywały się na nieaktualnym kodzie, przez co były zbędne i nieefektywne.
Poprawka: krótkotrwałe gałęzie funkcji
Aby temu zaradzić, zdaliśmy sobie sprawę, że konieczne jest dopracowanie strategii rozgałęziania. Chociaż istnieją plusy i minusy różnych strategii rozgałęziania, zdecydowaliśmy się kontynuować strategię gałęzi funkcji, ale z kluczową korektą: krótkotrwałe gałęzie funkcji, które są częściej scalane z powrotem do głównej gałęzi.
Krótkotrwała strategia gałęzi funkcji oferuje kilka korzyści, z których najważniejszą jest poprawa przepływu i zajęcie się wąskimi gardłami w cyklu rozwoju. Krótsze gałęzie zapewniają, że scalanie kodu jest łatwiejsze, szybsze i mniej podatne na błędy. Takie podejście umożliwia również szybsze przekazywanie informacji zwrotnych, co poprawia ogólną jakość i szybkość procesu rozwoju.
Ciągłe wdrażanie: Wyzwanie rurociągu
Konfigurowanie solidnych potoków ciągłego wdrażania jest złożonym zadaniem, które wymaga ukierunkowanego, przyrostowego podejścia. Z naszego doświadczenia wynika, że zalecanym podejściem jest posiadanie dedykowanego zespołu ds. platformy, który konfiguruje i utrzymuje te potoki, zamiast zlecać pracę nad nimi każdemu zespołowi scrumowemu z osobna. Podczas gdy ostateczna własność potoków ciągłego dostarczania musi spoczywać na zespołach scrumowych, początkowe zadanie ich konfiguracji znacznie zyskuje dzięki dedykowanemu zespołowi platformy.
Platform Team: Zmniejszenie obciążenia poznawczego i umożliwienie skupienia uwagi
Aby uzyskać inspirację w tworzeniu struktury naszego zespołu platformowego, zwróciliśmy się do Team Topologies autorstwa Matthew Skeltona i Manuela Paisa. Książka podkreśla znaczenie posiadania dedykowanego zespołu platformy, który jest odpowiedzialny za konfigurację i zarządzanie infrastrukturą - wnaszym przypadku potokami CD. Taka struktura pozwala zespołom scrumowym skupić się na rozwoju funkcji, jednocześnie czerpiąc korzyści ze stabilnej i ustandaryzowanej konfiguracji potoku.
Jak stwierdza książka:
"Zespół ds. platformy jest odpowiedzialny za tworzenie i utrzymywanie wewnętrznej platformy, z której korzystają zespoły pracujące zgodnie ze strumieniami. Celem platformy jest zmniejszenie obciążenia poznawczego zespołów dostosowanych do strumieni, aby mogły skupić się na dostarczaniu wartości".
Centralizując odpowiedzialność za potoki, byliśmy w stanie stworzyć wspólną platformę, na której mogły polegać zespoły zajmujące się strumieniami. Pozwoliło us zmniejszyć obciążenie poznawcze zespołów programistycznych, umożliwiając im skupienie się na dostarczaniu wartości, a nie na rozwiązywaniu problemów związanych z infrastrukturą.
Ewolucja platformy na rzecz ciągłego doskonalenia
Posiadanie zespołu ds. platformy nie polega tylko na konfigurowaniu potoków; chodzi o ewoluowanie wspólnej infrastruktury i narzędzi w czasie. Dedykowany zespół ds. platformy jest w najlepszej pozycji do wprowadzania stopniowych ulepszeń w potoku ciągłego dostarczania, zapewniając, że pozostaje on dostosowany do potrzeb zespołów i dostosowuje się w miarę skalowania i rozwoju. Ta ciągła ewolucja zapewnia, że platforma pozostaje niezawodna, skalowalna i wydajna - umożliwiającnaszym zespołom pracę na najwyższym poziomie.
Następny wpis: Automatyzacja i informacje zwrotne
Z usprawnionym rozgałęzianiem i przepływem wdrożeń, zwracamy się do ostatniej granicy w naszej podróży DevOps: Automatyzacji i informacji zwrotnej. W następnym i ostatnim rozdziale zbadamy, w jaki sposób zamknięcie pętli dzięki zautomatyzowanym spostrzeżeniom i szybkim informacjom zwrotnym zmieniło sposób działania naszych zespołów.
Bądź na bieżąco!
