DevOps – jak dobrze wytłumaczyć, na czym polega? Czy stosując podejście DevOps znikną bariery komunikacyjne i organizacyjne? – tłumaczą eksperci Deloitte.
Warto zacząć od książkowej definicji pojęcia DevOps, która mówi, że jest to filozofia prowadzenia rozwoju oprogramowania, której główne założenie brzmi: Ścisła współpraca pomiędzy wszystkimi zespołami zaangażowanymi w rozwój oprogramowania (np. deweloperzy, testerzy, administratorzy itd.) jest motorem wzrostu wydajności.
Równie prawdziwe jest stwierdzenie, że DevOps to metodyka stawiająca na budowę wspólnego środowiska pracy dla wszystkich członków zespołu i wspierająca automatyzację powtarzalnych kroków oraz promująca stopniowe osiąganie założonych wcześniej celów. Ktoś mógłby również powiedzieć, że DevOps to kultura, w której wszystkie role wymagane do wytworzenia danego produktu informatycznego, ściśle ze sobą współpracują oraz wspierają się w osiągnięciu wspólnego celu. Podsumowując, można pokusić się na sformułowanie, że stosując podejście DevOps znikają bariery komunikacyjne i organizacyjne, a na pierwszym miejscu stawiany jest bezpośredni kontakt i zaufanie. W dalszej części artykułu, przedstawimy DevOps oraz zwinność organizacji, czyli Agile.
Krótka historia czasu (umówmy się, że jest to przestrzeń dekady) w przypadku jednej z dużych firm telekomunikacyjnych wygląda następująco:
- Firma buduje rozwiązania lokalnie, bo twierdzi, że duże systemy od znanych dostawców są drogie i są to rozwiązania sprawdzające się jedynie na zachodzie.
- Po pewnym czasie firma dochodzi do wniosku, że lokalne rozwiązania są równie kosztowne, a na dodatek wdrożenia są skomplikowane i często się nie udają.
- W rezultacie firma decyduje się na zakup i wdrożenie renomowanego systemu od znanego, zachodniego dostawcy.
- Wdrożenie się powiodło, budżet i terminy zostały przekroczone dwu lub trzy krotnie, ale firma odnosi sukces.
Wszystkie zespoły po takim wdrożeniu zorganizowane są w sposób maksymalnie wspierający cykl życia systemu, który oparty jest na metodyce waterfall.
Jak to działa? Zespoły w przypadku systemu klasy enterprise są ściśle wyspecjalizowane w danej dziedzinie:
- Zespół analityków systemowych – opisuje wymagania biznesowe, na podstawie których deweloperzy będą budować rozwiązanie,
- Zespół „Dev” – wytwarza oprogramowanie, a sam kod pakowany jest w paczki i gotowy do wdrożenia na inne środowiska
- Zespołów „Release Management” – odpowiada za przenoszenie kodu wytworzonego przez zespół rozwoju pomiędzy środowiskami, przy zachowaniu odpowiedniej kolejności,
- Zespół „Tech Team” – odpowiedzialny jest za stawianie środowisk i ich techniczną konfigurację,
- Zespoły testowe (testy systemowe, testy integracyjne, testy użytkownika) – wykonują testy na dedykowanych środowiskach.
Każdy zespół wyspecjalizowany w danej dziedzinie, ma ograniczone pojęcie o tym, jak działają pozostałe. Dlatego też powstały silosy wiedzy (nie mylmy z silosami funkcjonalnymi) oraz setki procedur komunikacji. Przykładowo – deweloper przygotowuje paczkę oprogramowania oraz zlecanie migracji paczki, zespół „Release Management” na podstawie takiego zlecenia przeprowadza migrację w najbliższym oknie czasowym. Oczywiście takie okno czasowe ma termin zgłaszania paczek, paczki zgłoszone po tym terminie wchodzą w następne okno. Deweloper może spodziewać się wizyty. „Release Managera”, jeżeli nagminnie zgłasza paczki po terminie. Niestety „Release Managera” nie będzie interesować to, dlaczego deweloper nie wyrabia się ze swoją pracą. Oczywiście każdy punkt styku musi być opomiarowany – tak, aby centralnie monitorować i sterować całym cyklem wytwórczym.
Widzimy tu szereg czynności towarzyszących, które członkowie danych zespołów muszą wykonywać, zamiast skupić się nad swoimi głównymi celami. Dodatkowo muszą oni zabezpieczać się w taki sposób, aby nie być posądzonym o opóźnienia. Aby tym zarządzić, konieczny jest cały zespół, który monitoruje, estymuje, „motywuje” i raportuje.mOczywiście organizacja po pewnym czasie osiągnęła pewną wprawę i biegłość w tych wszystkich procedurach, jednak daleko tym działaniom było do zwinności w dzisiejszym tego słowa rozumieniu. Często zaczęły pojawiać się pytania, dlaczego rozwój trwa długo i jest tak drogi? Biznes narzekał, że nie może być konkurencyjny przy takich interwałach wdrożeń. Czy przyczyną nie jest czasem narzut organizacyjny, skomplikowanie systemu i oligopol dostawców? Czy jest coś, co można zrobić, żeby temu zaradzić?
Może moglibyśmy powoli wyciągać główne funkcjonalności z systemu i pisać je lokalnie od nowa mniejszymi bardziej zwinnymi zespołami? Aby to osiągnąć musielibyśmy wybrać fragment funkcjonalny, który można wydzielić z istniejącego monolitu. Trzeba by było zrobić to na tyle umiejętnie, aby samo wydzielenie nie było projektem czysto technicznym. Musiałoby ono mieć też realną wartość biznesową. Gdy w końcu udało się wybrać fragment funkcjonalny. Powołano interdyscyplinarny zespół, który był odpowiedzialny za nowy produkt. W skład zespołu weszli architekci rozwiązania, analitycy biznesowi, deweloperzy, testerzy oraz inżynierowie techniczni.
Przyjęto założenie, że zespół będzie działać w metodyce Agile, jednak całe pozostałe otoczenie dalej będzie prowadzić swoje wydania według starego, sprawdzonego sposobu. Zespół od razu przystąpił do działania. Okazało się, że zniesienie barier komunikacyjnych, określenie wspólnego celu oraz zacieśnienie współpracy pomiędzy różnymi rolami szybko przyniosło wymierne efekty.
Zespół na początku skupił się na dwóch aspektach:
- Czym powinna cechować się pierwsza wersja produktu, która zostanie udostępniona użytkownikom końcowym (czyli w nomenklaturze Agile – MVP – Minimum Viable Product).
- Jakich narzędzi potrzebujemy, aby efektywnie skupić się na produkcie i wyeliminować wąskie gardła?
Początki były trudne, gdyż okazało się, że wdrożenie nowego produktu wymaga synchronizacji z releasami monolitu. Pozostała organizacja „Waterfall” wymagała od zespołu raportowania i planowania prac, co odciągało kluczowych graczy od głównych celów. Oczywiście takie podejście nie może zostać określone jako zwinne. Po pewnym czasie, zdecydowano się przyznać zespołowi pełną autonomię i określono długoterminowe cele.
Zespół od razu położył nacisk na wypracowaniu docelowej architektury rozwiązania oraz na kwestiach związanych z tym, w jaki sposób analitycy biznesowi powinni opisywać wymagania (historyjki), tak aby deweloperzy nie mieli wątpliwości co do powierzonych im zadań. W ramach prac merytorycznych określono kluczowe funkcjonalności wraz z ich priorytetami.
Zespół deweloperów wraz z testerami i administratorami skupił się na wypracowaniu podwalin pod automatyzację w obszarach:
- zarządzania kodem źródłowym,
- przenoszenia paczek oprogramowania na poszczególne środowiska,
- testów,
- wdrożeń na produkcję.
Proces analizy wspierany był przez narzędzie JIRA, repozytorium Enterprise Architect oraz Confluence. Wszystkie one zostały powiązane w jedno środowisko, łączące cechy dobrego kombajnu analitycznego, który służył zarówno architektom i analitykom, ale także product ownerowi i deweloperom.
Jasna definicja tego, co powinno zostać wykonane oraz jakie są kryteria sukcesu bardzo ułatwiły pracę deweloperom, którzy korzystając z klarownych opisów historyjek w Confluence byli w stanie optymalnie tworzyć kod, którego wersje były kontrolowane za pomocą narzędzia GIT. Następnie kod był automatycznie budowany i wdrażany na środowisko testowe, na którym odbywały się automatyczne testy. Po przejściu ścieżki testowej paczka trafiała albo do poprawki – w przypadku wykrycia błędów, albo była wdrażana na środowisko integracyjne, na którym sprawdzano czy interakcje pomiędzy aplikacją a środowiskiem zewnętrznym zachowują się we wcześniej przewidziany sposób.
Zespół nie pracował w odosobnieniu. Budowane rozwiązania działały przecież w ściśle zintegrowanym środowisku, w którym pozostałe systemy były wdrażane metodyką kaskadową. Ważną rolę w synchronizacji produkcji odgrywali architekci, którzy zapewniali, że wytwarzane oprogramowanie spina się z pozostałymi projektami. Na jedno duże wdrożenie „kaskadowe”, którego cykl wynosił około ośmiu miesięcy, przypadało około 16 mniejszych wdrożeń realizowanych w trybie zwinnym. W ramach tych małych wdrożeń wytwarzano funkcjonalności, które wymagały zmian od innych systemów. W związku z tym, że zmiany te wprowadzane były metodyką kaskadową, po stronie systemu zwinnego funkcjonalności miały opcje wygaszenia, czy też ukrycia. Były testowane z wykorzystaniem symulacji zachowania systemów legacy, natomiast ostatnie wdrożenie zwinne było zsynchronizowane z kaskadowym go-live, w którym pozostałe systemy dostarczały wymagane funkcjonalności. Z perspektywy zespołu ostatnie wdrożenie polegało w głównej mierze na testach integracyjnych i włączeniu wygaszonych funkcjonalności.
Oczywiście, początki działań polegały na testowaniu poszczególnych narzędzi i sprawdzaniu czy się nadają. Na tym etapie, można było zauważyć, że wiele rozwiązań się nie sprawdza i trzeba zastosować inne. Początki były trudne, ale widać było zmianę systemową w działaniu zespołu. Ludzie byli skupieni na wspólnym rozwiązywaniu problemów, dążyli do osiągnięcia wspólnego celu. Po pewnym czasie poszczególne trybiki maszynerii zaczęły ze sobą współpracować, np. udało się zautomatyzować podstawowe testy integracyjne. I tak krok po kroku zespół pracował nad docelowym produktem, skupiając się na zoptymalizowaniu swoich działań, czyli zaczął działać zgodnie z przytoczonymi definicjami DevOps. Oczywiście nie obyło się bez trudnych chwil spowodowanych czynnikami niemożliwymi do przewidzenia. Na szczęście zespół był w stanie wyciągnąć z nich wnioski w taki sposób, aby nie popełniać tych samych błędów w przyszłości – co jest kluczową umiejętnością w dzisiejszych czasach.
Na tym etapie warto wspomnieć, co oznacza sama nazwa DevOps – pochodzi ona od skrótów dwóch angielskich słów: development i operations. Skróty tych słów są celowo połączone, odzwierciedlając synergię zespołów w filozofii DevOps. Patrząc z perspektywy czasu na przytoczoną historię można odnieść wrażenie, że DevOps jest naturalnym etapem rozwoju metodyk wytwórczych stosowanych w IT. Rozwój DevOps doprowadził do powstania nowych ról (np. inżyniera DevOps), ale przede wszystkim wprowadził zmianę w kulturze pracy zespołów rozwojowych i utrzymaniowych (a właściwie zniósł ten podział).
W organizacjach DevOps nie można już „przerzucać piłeczki” w nadziei, że wszelkie błędy zostaną rozwiązane po wdrożeniu. W organizacji DevOps osoba rzucająca i łapiąca taką „piłeczkę” to często ta sama osoba. A w najlepszym przypadku łapiącym będzie kolega z biurka obok, który nie będzie wykorzystywał korporacyjnych ścieżek eskalacyjnych do przekazania informacji zwrotnej o słabej jakości kodu, lecz zrobi to w sposób bardziej bezpośredni.
Konkludując całą historię, pomimo tego, że DevOps nie jest już czymś nowym, w wielu organizacjach pozostaje jeszcze bardzo dużo do zrobienia. Wdrożenie DevOps nie jest zwykłą zmianą organizacyjną i musi być przeprowadzone z uwagą i delikatnie. W końcu żaden dyrektor IT nie chciałby widzieć pod swoimi drzwiami rozwścieczonego tłumu informatyków.
W dzisiejszych czasach firmy żyją zmianami. Nowe kanały, nowi klienci, nowe produkty, to wszystko wymaga ciągłego dostosowywania narzędzi IT. Nasz zespół postawił sobie jeden cel – sprawić, żeby nasi klienci nie tylko przeszli przez te zmiany niepoturbowani, ale by jak najlepiej wykorzystywali technologie do realizacji swoich celów biznesowych.
Pomagamy liderom IT oraz ich zespołom w procesie przemian technologicznych:
- Opracowujemy nowe modele operacyjne, procesy i struktury.
- Wspieramy w uruchamianiu praktyk architektonicznych i planujemy wspólnie z nimi mapy drogowe rozwoju systemów.
- Prowadzimy również organizacje poprzez zwinne transformacje, wspierając w uruchomieniu wcześniej wypracowanych koncepcji strategicznych.
Najnowszy numer
Najnowszy numer