4 min read
Wiedza jest cenna, ale jej prawdziwa siła tkwi w tym, jak ją wykorzystujemy. W Freyr znaliśmy DevOps, związane z nim praktyki i sposób, w jaki może ono przekształcić naszą organizację w wysokowydajną potęgę w zakresie rozwoju produktów, zdolną do dostarczania wysokiej jakości produktów i rozwiązań naszym klientom z branży nauk przyrodniczych. Kiedy rozpoczynaliśmy naszą podróż, nasze wysiłki położyły solidne fundamenty, ale aby naprawdę stać się potęgą w zakresie rozwoju, wiedzieliśmy, że musimy przyjąć bardziej strategiczne i elastyczne podejście.
Podstawowym wyzwaniem w przekładaniu wiedzy na działania jest wiedza, kiedy podjąć właściwe kroki. Ponieważ działania mają wpływ na wiele osób w organizacji, podejmowanie właściwych działań we właściwym czasie zależy od tego, gdzie jesteśmy jako organizacja, naszych obecnych procesów i praktyk oraz umiejętności i możliwości naszych pracowników.
Był to punkt zwrotny w naszej transformacji. Jako portfolio dostawców oprogramowania specjalizujących się w rozwiązaniach niestandardowych, mieliśmy dedykowany zespół, który dokładał wszelkich starań, aby osiągać wyniki. Dostrzegliśmy jednak możliwość poprawy jakości, zwiększenia wydajności i przyspieszyć wymagań biznesowych w konkretne wyniki. Zamiast skupiać się na poprawkach wprowadzanych w ostatniej chwili, postanowiliśmy przejść od reaktywnego rozwiązywania problemów do proaktywnych innowacji, tworząc skalowalne rozwiązania o dużym wpływie.
Mieliśmy wizję tego, gdzie chcemy być - jak chcemy pracować, rozwijać, testować, wdrażać i wydawać oprogramowanie. Wiedzieliśmy jednak, że osiągnięcie tych celów wymaga przemyślanej strategii, ciągłego uczenia się i zaangażowania w doskonalenie.
Przenieśmy się do dnia dzisiejszego: w ciągu ostatniego roku wydaliśmy ponad 100 aktualizacji, niemal bez żadnych błędów we wdrażaniu, i osiągnęliśmy niemal pełną automatyzację wprowadzania zmian. Ponadto odnotowaliśmy znaczny wzrost przychodów, usprawniliśmy i zwiększyliśmy elastyczność zespołów oraz ogólnie zbliżyliśmy się do realizacji naszej wizji, aby stać się potęgą w dziedzinie oprogramowania, rozwiązań i usług. Chociaż zawsze jest jeszcze coś do osiągnięcia, jesteśmy przekonani, że stworzyliśmy solidne podstawy i jesteśmy gotowi do przyspieszyć.
Idąc naprzód, poświęcamy chwilę, aby zastanowić się nad naszą transformacją - co zadziałało, co nie i czego się nauczyliśmy. Dzieląc się naszą podróżą, mamy nadzieję wspierać innych w podobnych zmianach.
Ta seria blogów ma głównie charakter empiryczny, dzieląc się tym, co zrobiliśmy, jednocześnie łącząc nasze działania z najlepszymi praktykami i zaleceniami z różnych zasobów DevOps i Agile.
Robienie właściwych rzeczy we właściwym czasie
Jednym z kluczowych aspektów naszej transformacji było określenie właściwych działań we właściwym czasie. Przy wielu możliwych inicjatywach potrzebowaliśmy ustrukturyzowanego podejścia, aby zapewnić znaczący postęp.
Patrząc wstecz, możemy pogrupować te działania w trzy kategorie: Narzędzia i Procesy, Architektura Oprogramowania i Ludzie. Kategorie te są ze sobą ściśle powiązane, a zmiany w jednej z nich mają wpływ na pozostałe. Możliwe było jednak stopniowe wprowadzanie zmian w każdej kategorii i mierzenie postępów w realizacji naszych ogólnych celów.
Inicjatywy w tych kategoriach często zależały od siebie nawzajem. Zmiany w jednym obszarze otwierały możliwości dalszych ulepszeń w innym.
Pierwsze kroki
Aby stworzyć solidne podstawy, skupiliśmy się na trzech głównych inicjatywach:
- Integracja naszych baz kodu źródłowego z SonarQube w celu pomiaru jakości kodu.
- Przeniesienie wszystkich zespołów do wspólnego narzędzia do zarządzania wymaganiami, kodem źródłowym i planami testów - w naszym przypadku Azure DevOps.
- Struktura zespołów z jasno określonymi obowiązkami w celu zwiększenia odpowiedzialności.
Te trzy inicjatywy pozwoliły us uzyskać us w:
- Wykonywana praca (wymagania i zadania).
- Jakość kodu (metryki SonarQube).
- Zaangażowane osoby (obowiązki zespołu).
Wśród nich największym wyzwaniem było zdefiniowanie jasnych obowiązków zespołu. Początkowo struktury zespołów były płynne, a ludzie przemieszczali się między projektami w zależności od potrzeb. Przejście na dedykowane zespoły z odrębnymi obszarami funkcjonalnymi było koniecznym krokiem, choć skomplikowanym przez naszą istniejącą architekturę produktu, która nie była w pełni zaprojektowana do wspierania jasnej odpowiedzialności.
Rola architektury oprogramowania
Szybko zdaliśmy sobie sprawę, że architektura produktu była jednym z najbardziej krytycznych obszarów wymagających zmian. Modułowa architektura była niezbędna do umożliwienia niezależnym zespołom wzięcia odpowiedzialności za swoją pracę. Bez tego nasze wysiłki zmierzające do stworzenia odpowiedzialności zespołowej miały ograniczony wpływ.
Zmiana architektury naszego portfolio była złożonym procesem. Obejmował on pełne przejście do chmury i rozpoczęcie tworzenia natywnych aplikacji w chmurze przy użyciu architektury mikrousług. Temat ten zostanie omówiony w przyszłym wpisie. Kluczowym wnioskiem jest jednak to, że zmiany są stopniowe, a niektóre kroki muszą poprzedzać inne, aby odblokować korzyści i dalszy postęp.
Metryki i ciągłe doskonalenie
Po rozpoczęciu prac nad rearchitekturą (które są w toku), skupiliśmy się na monitorowaniu wskaźników i ustalaniu celów:
- Wskaźniki jakości kodu w SonarQube.
- Metryki integracji kodu w Azure DevOps.
- Wskaźniki przepustowości funkcji dla poszczególnych zespołów.
- Przyjęcie usług natywnych dla chmury.
Cele te nie były twardymi nakazami, ale celami przewodnimi, które miały pomóc zespołom w dostosowaniu ich wysiłków.
Wzmacnianie pozycji ludzi
Po wprowadzeniu metryk stało się oczywiste, że zespoły potrzebują wsparcia, aby osiągnąć te cele. Na przykład, podczas gdy ustalenie celów dotyczących pokrycia testami jednostkowymi i automatyzacji testów API było proste, ich osiągnięcie stanowiło wyzwanie, zwłaszcza w przypadku starszego kodu, który nie został zaprojektowany pod kątem testowalności.
Aby temu zaradzić, my:
- Ustaw niższe cele dla starszego kodu.
- Organizował warsztaty i praktyczne szkolenia z pisania wysokiej jakości testów jednostkowych i projektowania testowalnego kodu.
- Udzielono wskazówek dotyczących tworzenia odgałęzień do testowania API.
- Prowadzenie przeglądów testów jednostkowych przez starszych architektów.
Trójkąt narzędzi, architektury i ludzi
Dobrym przykładem interakcji między tymi kategoriami było zarządzanie kodem i repozytorium. Integracja z SonarQube, która stanowi ulepszenie narzędzi, ujawniła niskie pokrycie testami jednostkowymi, co wskazywało na kwestie architektoniczne ograniczające testowalność. Ulepszenia w architekturze i umiejętnościach zespołu doprowadziły do lepszej jakości testów jednostkowych, ale nie były one wykonywane regularnie z powodu złych praktyk rozgałęziania. Rozwiązaliśmy ten problem poprzez standaryzację strategii rozgałęziania i zapewnienie regularnej integracji kodu z główną gałęzią, umożliwiając potokom CI uruchamianie wszystkich testów.
Właściwa sekwencja zmian
Jednym z podejść do transformacji jest bezkrytyczne wdrażanie najlepszych praktyk. Chociaż może to przynieść korzyści, wyniki często nie uzasadniają wysiłku, co prowadzi do frustracji.
Zastosowaliśmy inne podejście, oparte na zasadzie przepływu: analizujemy end-to-end , identyfikujemy wąskie gardła i stopniowo je eliminujemy.
Każde ulepszenie ujawniało nowe wąskie gardła, wymagające dalszych działań. Nie była to gra w "bierki", ale celowy proces robienia właściwych rzeczy we właściwym czasie.
Na przykład nakazanie pokrycia testami jednostkowymi bez poprawy projektu kodu doprowadziłoby do frustracji i "teatru pokrycia" (powierzchownych testów napisanych w celu spełnienia metryk). 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 pojedynczej dużej zmianie - chodzi o mądre, dobrze zaplanowane decyzje, które napędzają ciągły postęp. Cieszymy się, że możemy podzielić się naszą podróżą i spostrzeżeniami, aby pomóc innym w poruszaniu się po ich własnej ścieżce do skalowalnych zmian o dużym wpływie.
W kolejnych wpisach z serii „DevOps dla zwycięstwa” omówimy każdy etap naszej transformacji w trójkącie DevOps – narzędzia, architektura i ludzie – które pomogły us trwały efekt.
