4 min czytania
Wiedza jest cenna, ale jej prawdziwa siła tkwi w tym, jak wprowadzamy ją w czyn. W Freyr Digital znaliśmy metodykę DevOps, powiązane z nią praktyki oraz to, jak może ona przekształcić naszą organizację w wysokowydajne centrum rozwoju produktów – zdolne dostarczać wysokiej jakości produkty i rozwiązania naszym klientom z sektora nauk o życiu. Kiedy rozpoczynaliśmy tę podróż, nasze działania położyły mocne fundamenty, jednak wiedzieliśmy, że aby naprawdę stać się potęgą deweloperską, musimy przyjąć bardziej strategiczne i elastyczne podejście.
Główne wyzwanie w przekładaniu wiedzy na praktykę polega na wiedzy, kiedy podjąć właściwe kroki. Ponieważ działania wpływają na wiele osób w organizacji, robienie właściwych rzeczy we właściwym czasie zależy od tego, w jakim punkcie jako organizacja się znajdujemy, jakie mamy obecne procesy i praktyki oraz jakie są umiejętności i możliwości naszych ludzi.
Oznacza to punkt zwrotny w naszej transformacji. Jako portfolio dostawców oprogramowania specjalizujących się w rozwiązaniach szytych na miarę, mieliśmy oddany zespół, który wkładał dodatkowy wysiłek w osiąganie rezultatów. Dostrzegliśmy jednak możliwość poprawy jakości, zwiększenia wydajności i przyspieszenia konwersji wymagań biznesowych na gotowe rezultaty. Zamiast skupiać się na naprawach w ostatniej chwili, dążyliśmy do przejścia od reaktywnego rozwiązywania problemów do proaktywnych innowacji, tworząc skalowalne rozwiązania o dużym wpływie.
Mieliśmy wizję tego, dokąd chcemy dojść – jak chcemy pracować, tworzyć, testować, wdrażać i publikować oprogramowanie. Wiedzieliśmy jednak, że osiągnięcie tych celów wymaga przemyślanej strategii, ciągłej nauki i zaangażowania w doskonalenie.
Przechodząc do dnia dzisiejszego: w ostatnim roku zrealizowaliśmy ponad 100 wdrożeń z niemal zerowym odsetkiem błędów i osiągnęliśmy prawie pełną automatyzację wprowadzania zmian. Ponadto odnotowaliśmy znaczny postęp w przychodach, szczuplejsze i bardziej zwinne zespoły oraz ogólne przesunięcie w kierunku naszej wizji stania się potęgą w zakresie produktów, rozwiązań i usług programistycznych. Choć zawsze można osiągnąć więcej, jesteśmy pewni, że położyliśmy solidne fundamenty i jesteśmy gotowi przyspieszyć.
Idąc naprzód, zatrzymujemy się na chwilę, aby podsumować naszą transformację – co zadziałało, co nie i jakie wyciągnęliśmy wnioski. Dzieląc się naszą historią, mamy nadzieję pomóc innym, którzy przechodzą przez podobne zmiany.
Ta seria artykułów ma charakter głównie empiryczny – dzielimy się naszymi doświadczeniami, łącząc nasze działania z najlepszymi praktykami i zaleceniami z różnych źródeł dotyczących metodyk DevOps i Agile.
Robienie właściwych rzeczy we właściwym czasie
Jednym z kluczowych aspektów naszej transformacji było wskazanie właściwych działań we właściwym czasie. Mając do dyspozycji wiele potencjalnych inicjatyw, potrzebowaliśmy uporządkowanego podejścia, aby zapewnić realny postęp.
Patrząc wstecz, możemy podzielić te działania na trzy kategorie: narzędzia i procesy, architektura oprogramowania oraz ludzie. Kategorie te są ze sobą ściśle powiązane, a zmiany w jednej wpływają na pozostałe. Mimo to możliwe było wprowadzanie stopniowych zmian w każdej z nich i mierzenie postępów w realizacji naszych ogólnych celów.
Inicjatywy w tych kategoriach często były od siebie zależne. Zmiany w jednym obszarze otwierały drogę do dalszych ulepszeń w innym.
Pierwsze kroki
Aby stworzyć solidne fundamenty, skupiliśmy się na trzech głównych inicjatywach:
- Połączenie naszych baz kodu źródłowego z narzędziem SonarQube w celu śledzenia wskaźników jakości kodu.
- Przeniesienie wszystkich zespołów do wspólnego narzędzia służącego do zarządzania wymaganiami, kodem źródłowym i planami testów – w naszym przypadku była to platforma Azure DevOps.
- Uporządkowanie struktur zespołów i jasne przypisanie odpowiedzialności w celu zwiększenia zaangażowania i poczucia sprawczości.
Te trzy inicjatywy zapewniły nam wgląd w:
- Wykonywana praca (wymagania i zadania).
- Jakość kodu (wskaźniki z programu SonarQube).
- Zaangażowane osoby (odpowiedzialność w zespole).
Spośród nich ustalenie jasnych obowiązków zespołu okazało się największym wyzwaniem. Początkowo struktury zespołów były elastyczne, a członkowie przechodzili między projektami w miarę potrzeb. Przejście na dedykowane zespoły z wydzielonymi obszarami funkcjonalnymi było koniecznym krokiem, choć utrudniała je nasza istniejąca architektura produktu, która nie była w pełni przystosowana do zapewnienia jasnej odpowiedzialności.
Rola architektury oprogramowania
Szybko zorientowaliśmy się, że architektura produktu jest jednym z najważniejszych obszarów wymagających zmiany. Architektura modularna była niezbędna, aby umożliwić niezależnym zespołom przejęcie odpowiedzialności za ich pracę. Bez tego nasze starania na rzecz stworzenia poczucia własności w zespołach przyniosłyby ograniczone efekty.
Przebudowa architektury naszego portfolio była złożonym procesem. Obejmowała ona całkowite przejście do chmury oraz rozpoczęcie tworzenia aplikacji natywnych dla chmury przy użyciu architektury mikrousług. Temat ten zostanie omówiony w przyszłym wpisie. Kluczowym wnioskiem jest jednak to, że zmiany mają charakter ewolucyjny, a pewne kroki muszą poprzedzać inne, aby odblokować korzyści i dalszy postęp.
Metryki i ciągłe doskonalenie
Po rozpoczęciu prac nad przebudową architektury (co jest procesem ciągłym) przenieśliśmy naszą uwagę na monitorowanie metryk i wyznaczanie celów:
- Metryki jakości kodu w programie SonarQube.
- Metryki integracji kodu w usłudze Azure DevOps.
- Metryki wydajności funkcji dla poszczególnych zespołów.
- Wdrażanie usług natywnych dla chmury.
Cele te nie były sztywnymi nakazami, lecz wytycznymi mającymi pomóc zespołom w dostosowaniu swoich działań.
Wspieranie ludzi
Gdy metryki były już ustalone, stało się oczywiste, że zespoły potrzebują wsparcia w osiągnięciu tych celów. Przykładowo, o ile wyznaczenie celów dotyczących pokrycia testami jednostkowymi i automatyzacji testów API było proste, o tyle ich osiągnięcie okazało się trudne, zwłaszcza w przypadku starszego kodu, który nie został zaprojektowany z myślą o testowalności.
Aby temu zaradzić, podjęliśmy następujące kroki:
- Ustanowiliśmy niższe cele dla starszego kodu.
- Zorganizowaliśmy warsztaty i szkolenia praktyczne na temat pisania wysokiej jakości testów jednostkowych oraz projektowania kodu nadającego się do testowania.
- Zapewniliśmy wytyczne dotyczące tworzenia zaślepek (stubów) do testowania API.
- Przeprowadziliśmy przeglądy testów jednostkowych przez starszych architektów.
Trójkąt narzędzi, architektury i ludzi
Dobrym przykładem wzajemnych powiązań między tymi kategoriami było zarządzanie kodem i repozytorium. Integracja z programem SonarQube, będąca ulepszeniem narzędziowym, ujawniła niskie pokrycie testami jednostkowymi, co wskazywało na problemy architektoniczne ograniczające testowalność. Usprawnienia w architekturze i umiejętnościach zespołów doprowadziły do lepszej jakości testów jednostkowych, jednak nie były one wykonywane regularnie z powodu niewłaściwych praktyk tworzenia gałęzi. Rozwiązaliśmy ten problem, standaryzując strategie gałęzi i zapewniając regularną integrację kodu z główną gałęzią, co umożliwiło potokom CI uruchamianie wszystkich testów.
Właściwa sekwencja zmian
Jednym ze sposobów podejścia do transformacji jest bezkrytyczne wdrażanie najlepszych praktyk. Choć może to przynieść korzyści, wyniki często nie uzasadniają włożonego wysiłku, prowadząc do frustracji.
Zastosowaliśmy inne podejście, oparte na zasadzie przepływu: przeanalizować proces End-to-End, zidentyfikować wąskie gardła i rozwiązywać je stopniowo.
Każde udoskonalenie ujawniało nowe wąskie gardła, co wymagało dalszych działań. Nie była to gra w „whack-a-mole”, lecz przemyślany proces robienia właściwych rzeczy we właściwym czasie.
Przykładowo, narzucenie wymogu pokrycia testami jednostkowymi bez poprawy projektu kodu doprowadziłoby do frustracji oraz „teatru pokrycia” (powierzchniowych testów pisanych wyłącznie pod metryki). Zajmując się najpierw architekturą i umiejętnościami, zapewniliśmy znaczący postęp.
Patrząc w przyszłość
Prawdziwa transformacja nie polega na jednej wielkiej zmianie, ale na mądrych, dobrze zaplanowanych decyzjach, które napędzają ciągły postęp. Cieszymy się, że możemy podzielić się naszą drogą i spostrzeżeniami, aby pomóc innym w przejściu własnej ścieżki do skalowalnych i wywierających duży wpływ zmian.
W kolejnych artykułach z tej serii – DevOps na wagę złota – szczegółowo opisujemy każdą fazę naszej transformacji w obrębie trójkąta DevOps (narzędzia, architektura i ludzie), która pomogła nam osiągnąć trwałe rezultaty.
