,
3 minuty czytania
W Rozdziale 4: Śledzenie tego, co ważne – KPI i pulpity nawigacyjne, zbadaliśmy, jak wizualizacja przepływu pracy i zdefiniowanie odpowiednich KPI pomogły nam zidentyfikować wąskie gardła i zjednoczyć nasze zespoły wokół dostarczania wartości. Dzięki lepszej widoczności w naszym potoku DevOps, zaczęliśmy zadawać głębsze pytania – nie tylko o to, gdzie występowały wąskie gardła, ale dlaczego się pojawiały.
W Rozdziale 5 zagłębiamy się w jedną z najważniejszych zmian technicznych i procesowych w naszej podróży transformacyjnej: udoskonalenie naszej strategii rozgałęziania i umożliwienie ciągłego wdrażania. Zmiany te były kluczowe w rozwiązywaniu uporczywych opóźnień między rozwojem a produkcją.
Identyfikacja nowego wąskiego gardła
Analiza przepływu pracy i identyfikacja wąskich gardeł, gdzie gromadzi się praca, była kluczowym aspektem osiągnięcia naszej transformacji DevOps. To skupienie na przepływie leży u podstaw tego, jak zastosowaliśmy trójkąt DevOps – narzędzia, architekturę i ludzi – w celu osiągnięcia szybszego i bardziej niezawodnego dostarczania.
W miarę postępów w poprawie testowalności wraz ze wzrostem testów jednostkowych i pokrycia automatyzacją testów, stwierdziliśmy, że jakość kodu się poprawiała, ale wąskie gardło nadal znajdowało się w fazie testowania scrum. Pomimo postępów w automatyzacji testów, praca nadal się piętrzyła, a wąskie gardło przeniosło się z etapu rozwoju na testowanie na poziomie systemu. Kluczowe wskaźniki wydajności (KPI) pokazały, że praca w toku na zespół podczas rozwoju zmniejszała się, ale kod nadal utykał w punkcie przejścia do testowania systemowego. To opóźnienie ostatecznie uniemożliwiło nam osiągnięcie płynnego przepływu.
Główna przyczyna: Strategia rozgałęziania i opóźnione scalenia
Analiza wykazała, że główna przyczyna zaległości tkwiła w naszej strategii rozgałęziania kodu. Deweloperzy i testerzy tworzyli gałęzie funkcji z głównej gałęzi, rozpoczynając prace nad nowymi funkcjami. W miarę rozwoju kodu inżynierowie przesyłali swoje zmiany do zdalnych gałęzi funkcji, aby połączyć swoją pracę z innymi. Jednak ten kod nie był wystarczająco często ponownie łączony z główną gałęzią.
Potoki CI/CD zostały skonfigurowane na głównej gałęzi, uruchamiając zautomatyzowane testy i wdrażając do chmury, a następnie przeprowadzając testy regresyjne. Jednakże, ponieważ najnowsze zmiany nie były regularnie przesyłane do głównej gałęzi, wykonania potoków odbywały się na przestarzałym kodzie, co czyniło je zbędnymi i nieskutecznymi.
Rozwiązanie: Krótkotrwałe gałęzie funkcji
Aby to rozwiązać, zdaliśmy sobie sprawę, że konieczne jest dostosowanie strategii rozgałęziania. Chociaż różne strategie rozgałęziania mają swoje zalety i wady, zdecydowaliśmy się kontynuować strategię gałęzi funkcji, ale z kluczową modyfikacją: krótkotrwałe gałęzie funkcji, które są częściej scalane z główną gałęzią.
Strategia krótkotrwałych gałęzi funkcyjnych oferuje kilka zalet, z których najważniejszą jest poprawiony przepływ i eliminacja wąskich gardeł w cyklu rozwoju. Krótsze gałęzie zapewniają, że łączenie kodu jest łatwiejsze, szybsze i mniej podatne na błędy. Takie podejście umożliwia również szybsze uzyskiwanie informacji zwrotnych, co poprawia ogólną jakość i szybkość procesu rozwoju.
Ciągłe wdrażanie: Wyzwanie związane z potokiem
Ustanowienie solidnych ciągłych potoków wdrażania jest złożonym zadaniem, które wymaga ukierunkowanego, przyrostowego podejścia. Z naszego doświadczenia wynika, że posiadanie dedykowanego zespołu platformowego do tworzenia i utrzymywania tych potoków jest zalecanym podejściem, zamiast powierzać to zadanie każdemu zespołowi scrumowemu indywidualnie. Chociaż ostateczna odpowiedzialność za ciągłe potoki dostarczania musi spoczywać na zespołach scrumowych, to początkowe zadanie ich konfiguracji znacznie zyskuje dzięki dedykowanemu zespołowi platformowemu.
Zespół platformy: Zmniejszanie obciążenia poznawczego i umożliwianie skupienia
W poszukiwaniu inspiracji do strukturyzacji naszego zespołu platformowego sięgnęliśmy po książkę Team Topologies autorstwa Matthew Skeltona i Manuela Paisa. Książka podkreśla znaczenie posiadania dedykowanego zespołu platformowego odpowiedzialnego za konfigurację i zarządzanie infrastrukturą – w naszym przypadku potokami CD. Taka struktura pozwala zespołom scrumowym skupić się na rozwijaniu funkcji, jednocześnie korzystając ze stabilnej i ustandaryzowanej konfiguracji potoków.
Jak podaje książka:
„Zespół platformy jest odpowiedzialny za budowanie i utrzymywanie wewnętrznej platformy, której używają zespoły zorientowane na strumień pracy do realizacji swoich zadań. Celem platformy jest zmniejszenie obciążenia poznawczego dla zespołów zorientowanych na strumień pracy, aby mogły skupić się na dostarczaniu wartości.”
Dzięki scentralizowaniu odpowiedzialności za procesy, udało nam się stworzyć wspólną platformę, na której mogły polegać zespoły zorientowane na strumienie pracy. Pozwoliło nam to zmniejszyć obciążenie poznawcze zespołów deweloperskich, umożliwiając im skupienie się na dostarczaniu wartości, zamiast zajmować się kwestiami infrastruktury.
Udoskonalanie platformy w celu ciągłego doskonalenia
Posiadanie zespołu platformowego to nie tylko kwestia tworzenia potoków; to także rozwijanie współdzielonej infrastruktury i narzędzi w czasie. Dedykowany zespół platformowy jest w najlepszej pozycji do wprowadzania stopniowych ulepszeń w potoku ciągłego dostarczania, zapewniając jego zgodność z potrzebami zespołów i adaptację w miarę skalowania i rozwoju. Ta ciągła ewolucja gwarantuje, że platforma pozostaje niezawodna, skalowalna i wydajna, umożliwiając naszym zespołom pracę na najwyższym poziomie.
Następnie: Automatyzacja i informacje zwrotne
Gdy rozgałęzianie jest usprawnione, a wdrożenia przebiegają płynnie, przechodzimy do ostatniego etapu naszej podróży DevOps: Automatyzacji i Informacji Zwrotnej. W następnym i ostatnim rozdziale zbadamy, jak zamknięcie obiegu dzięki zautomatyzowanym analizom i szybkiej informacji zwrotnej zmieniło sposób działania naszych zespołów.
Bądź na bieżąco!
