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 niestandardowych rozwiązaniach, mieliśmy oddany zespół, który dokładał wszelkich starań, aby dostarczać wyniki. Dostrzegliśmy jednak możliwość podniesienia jakości, zwiększenia produktywności i przyspieszenia konwersji wymagań biznesowych na dostarczane produkty. Zamiast skupiać się na poprawkach w ostatniej chwili, chcieliśmy przejść od reaktywnego rozwiązywania problemów do proaktywnych innowacji, budując skalowalne, skuteczne rozwiązania.
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.
Przejdźmy do dnia dzisiejszego: w ciągu ostatniego roku dokonaliśmy ponad 100 wydań z niemal zerową liczbą błędów wdrożeniowych i osiągnęliśmy niemal pełną automatyzację wprowadzania zmian. Ponadto odnotowaliśmy znaczący postęp w zakresie przychodów, odchudziliśmy i usprawniliśmy zespoły, a także ogólnie przesunęliśmy się w kierunku naszej wizji stania się potęgą w zakresie produktów, rozwiązań i usług związanych z oprogramowaniem. Chociaż zawsze jest więcej do osiągnięcia, jesteśmy przekonani, że położyliśmy mocne fundamenty i jesteśmy gotowi do przyspieszenia.
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: przeanalizuj cały proces, zidentyfikuj wąskie gardła i zajmij się nimi stopniowo.
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.
