Czas czytania: 3 min
W rozdziale 4: Śledzenie tego, co ważne – wskaźniki KPI i pulpity nawigacyjne przyjrzeliśmy się, jak wizualizacja pracy i definiowanie odpowiednich wskaźników KPI pomogły nam dostrzec wąskie gardła i zjednoczyć zespoły wokół dostarczania wartości. Dzięki lepszej widoczności naszej ścieżki wdrożeniowej (DevOps) zaczęliśmy zadawać sobie głębsze pytania – nie tylko o to, gdzie występują opóźnienia, ale dlaczego do nich dochodzi.
W rozdziale 5 omawiamy jedną z najważniejszych zmian technicznych i procesowych w naszej transformacji: udoskonalenie strategii tworzenia gałęzi (branchingu) oraz wdrożenie ciągłego wdrażania. Zmiany te miały kluczowe znaczenie dla wyeliminowania uporczywych opóźnień między etapem tworzenia oprogramowania a środowiskiem produkcyjnym.
Identyfikacja nowego wąskiego gardła
Analiza przepływu pracy i identyfikacja wąskich gardeł, w których gromadzą się zadania, była kluczowym aspektem naszej transformacji DevOps. To skupienie się na przepływie leży u podstaw tego, jak zastosowaliśmy trójkąt DevOps: narzędzia, architekturę i ludzi, aby osiągnąć szybsze i bardziej niezawodne dostarczanie rozwiązań.
W miarę jak robiliśmy postępy w poprawie testowalności wraz ze wzrostem liczby testów jednostkowych i pokrycia testami automatycznymi, zauważyliśmy, że jakość kodu rośnie, jednak wąskie gardło nadal tkwiło w fazie testów scrumowych. Pomimo postępów w automatyzacji testów zadania nadal się piętrzyły, a wąski punkt przesunął się z tworzenia oprogramowania do testów na poziomie systemu. Kluczowe wskaźniki efektywności (KPI) pokazały, że ilość pracy w toku przypadająca na zespół w fazie rozwoju maleje, ale kod nadal utknął w punkcie przejścia do testów systemowych. To opóźnienie ostatecznie uniemożliwiało nam osiągnięcie płynnego przepływu.
Główna przyczyna: strategia gałęzi i opóźnione scalanie
Analiza wykazała, że źródłem problemu była nasza strategia tworzenia gałęzi (branchingu). Programiści i testeri tworzyli gałęzie funkcji z głównej gałęzi (main) w celu realizacji nowych zadań. W miarę postępów prac inżynierowie przesyłali swoje zmiany do zdalnych gałęzi funkcji, aby połączyć je z pracami innych osób. Jednak kod ten nie był wystarczająco często scalany z powrotem z gałęzią główną.
Konfiguracja pogrupowanych potoków CI/CD była powiązana z gałęzią główną, gdzie uruchamiano automatyczne testy i realizowano wdrażanie do chmury, a następnie testy regresyjne. Ponieważ jednak najnowsze zmiany nie były regularnie wysyłane do gałęzi głównej, potoki działały na przestarzałym kodzie, co czyniło je zbędnymi i nieskutecznymi.
Rozwiązanie: krótkotrwałe gałęzie funkcji
Aby to rozwiązać, zrozumieliśmy, że konieczne jest dopracowanie strategii tworzenia gałęzi. Choć różne podejścia do branchingu mają swoje zalety i wady, zdecydowaliśmy się kontynuować korzystanie ze strategii gałęzi funkcji, wprowadzając jednak istotną modyfikację: krótkotrwałe gałęzie funkcji, które są częściej scalane z gałęzią główną.
Strategia krótkotrwałych gałęzi funkcji oferuje szereg zalet, z których najważniejszą jest poprawa przepływu oraz likwidacja wąskich gardeł w cyklu tworzenia oprogramowania. Krótszy czas życia gałęzi sprawia, że scalanie kodu jest łatwiejsze, szybsze i mniej podatne na błędy. Podejście to pozwala również na szybsze uzyskiwanie informacji zwrotnej, co podnosi ogólną jakość i tempo procesu tworzenia.
Ciągłe wdrażanie: wyzwanie związane z potokiem
Konfiguracja stabilnych potoków ciągłego wdrażania to złożone zadanie, które wymaga skupionego, stopniowego podejścia. Z naszego doświadczenia wynika, że zamiast angażować każdy zespół scrumowy z osobna, lepszym rozwiązaniem jest powołanie dedykowanego zespołu platformowego do konfiguracji i utrzymania tych potoków. Choć ostateczna odpowiedzialność za potoki ciągłego dostarczania musi spoczywać na zespołach scrumowych, początkowe zadanie ich skonfigurowania znacznie zyskuje dzięki wsparciu dedykowanego zespołu.
Zespół platformowy: odciążenie poznawcze i skupienie na celu
Szukając inspiracji do struktury naszego zespołu platformowego, sięgnęliśmy po publikację Team Topologies autorstwa Matthew Skeltona i Manuela Paisa. Książka ta 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 tworzeniu funkcji, korzystając jednocześnie ze stabilnej i zestandardizowanej konfiguracji potoków.
Jak czytamy w książce:
„Zespół platformowy odpowiada za budowanie i utrzymywanie wewnętrznej platformy, z której korzystają zespoły zorientowane na strumień wartości w celu realizacji swoich zadań. Zadaniem platformy jest zmniejszenie obciążenia poznawczego tych zespołów, aby mogły one skupić się na dostarczaniu wartości”.
Centralizując odpowiedzialność za potoki, udało nam się stworzyć wspólną, uniwersalną platformę, na której mogły polegać zespoły dostarczające wartość. Pozwoliło nam to zmniejszyć obciążenie poznawcze zespołów deweloperskich, umożliwiając im skupienie się na dostarczaniu wartości zamiast na kwestiach infrastrukturalnych.
Rozwój platformy na rzecz ciągłego doskonalenia
Posiadanie zespołu ds. platformy to nie tylko konfigurowanie potoków, ale także rozwijanie wspólnej infrastruktury i narzędzi w czasie. Dedykowany zespół ds. platformy ma najlepszą pozycję do wprowadzania stopniowych ulepszeń w potoku ciągłego wdrażania, co zapewnia jego zgodność z potrzebami zespołów oraz dostosowanie do naszego rozwoju i skalowania. Ta ciągła ewolucja sprawia, że platforma pozostaje niezawodna, skalowalna i wydajna, co pozwala naszym zespołom pracować jak najlepiej.
Następnie: Automatyzacja i informacje zwrotne
Po usprawnieniu tworzenia gałęzi i wdrożeń przechodzimy do ostatniego etapu naszej podróży z DevOps: automatyzacji i informacji zwrotnych. W kolejnym i ostatnim rozdziale omówimy, jak zamknięcie obiegu za pomocą zautomatyzowanych analiz i szybkich informacji zwrotnych wpłynęło na zmianę sposobu działania naszych zespołów.
Śledź nas na bieżąco!
