Czym jest DevOps?

Dziś na warsztat bierzemy często używane w ostatnim czasie, “modne” słowo – DevOps. Spróbujemy odpowiedzieć na pytania, kiedy możemy posłużyć się tym terminem, co on dokładnie oznacza i jak DevOps ma się do projektów zwinnych. Przecież o nich, między innymi, jest ten blog.

 

Znaczenie DevOps

Pisząc o DevOps, podobnie jak pisząc o metodykach Agile, nie będziemy w stanie scharakteryzować go przy użyciu jednego prostego zdania. Próbując odpowiedzieć na pytanie, czym jest DevOps powinniśmy utożsamiać ten termin z kombinacją filozofii, narzędzi a także praktyk. Pojęcie to zostało zaproponowane i zaprezentowane po raz pierwszy w 2009 przez Patricka Debois podczas konferencji DevOpsDays w Gandawie.

Najtrafniej będzie powiedzieć, że DevOps zespala dwa nurty obecne w każdym projekcie informatycznym: nurt rozwoju oprogramowania (Dev) oraz nurt odpowiedzialny za utrzymanie go, eksploatację (Ops).

Pojęcie DevOps określane jest niekiedy również metodyką. Czy to dobrze? Zgodnie z definicją terminu, metodyka powinna określać zestaw metod. I faktycznie, za DevOps stoją konkretne rozwiązania, których implementacja ma spowodować lepsze efekty pracy naszego projektu.

 

Założenia DevOps

Podstawowym założeniem tego podejścia jest ścisła współpraca ludzi należących do obu wymienionych powyżej nurtów. Pisząc o ścisłej współpracy mam na myśli likwidację silosów i osobnych zespołów odpowiedzialnych za rozwój oprogramowania i jego późniejsze utrzymanie po wdrożeniu.

Czym może skończyć się sytuacja, w której osoby tworzące oprogramowanie nie muszą go następnie utrzymywać? Czy nie doprowadzi to do powstania kodu niskiej jakości, bo przecież “nie ja później będę poprawiał błędy”?

Ścisła współpraca czy zespolenie, o którym mowa powyżej, nie wymusza na nas konieczności utworzenia jednego dużego zespołu (np. 30 osobowego), który pracując wspólnie osiągnie założone cele. Jak pisaliśmy już w artykule o wielkości zespołu, taki twór nie będzie w stanie pracować efektywnie. Kluczem do dobrego zrozumienia terminu ścisłej współpracy będzie komunikacja. Słowo, które odmieniane jest przez wszystkie przypadki w metodykach zwinnych, zarówno tych “podstawowych” jak i skalowalnych.

 

Filozofia…

Zmiana sposobu funkcjonowania naszej firmy i naszych projektów na model DevOps wymaga wdrożenia nowego sposobu myślenia, nowej filozofii. Powinniśmy usunąć wszelkie bariery pomiędzy wspomnianymi nurtami rozwoju i utrzymania oprogramowania, umożliwiając tym samym członkom tych zespołów na swobodną pracę i nieskrępowaną komunikację.

Pracując wspólnie, zespoły te będą w stanie optymalizować wartość dostarczanego oprogramowania zarówno na poziomie jakości wytwarzanego kodu, jak również późniejszego jego utrzymania. Co więcej, ani jakość wytwarzanego kodu, ani późniejsze utrzymanie funkcjonalności nie będą wzajemnie na siebie wpływały. Działając jako jeden zespół wszyscy jego członkowie mają wspólny cel.

DevOps biorą pełną odpowiedzialność za wytwarzane przez siebie oprogramowanie. Stawiają również sobie za cel komunikację z klientem końcowym (odbiorcą naszego projektu) w zakresie identyfikacji jego wymagań i potrzeb, a także sposobu implementacji ich w przygotowywanym rozwiązaniu.

 

Praktyki i… narzędzia

DevOps zawiera szereg kluczowych praktyk, których wdrożenie pozwoli na osiągnięcie innowacyjności i szybsze dostarczanie rozwiązania do klienta. Część z nich pokrywa się z zaleceniami Agile Manifesto.

Najważniejszą z nich jest praca iteracyjna umożliwiających częste wydawanie małych zmian. Nie trzeba nikogo przekonywać, że taka praca powinna spowodować szybszą reakcję na potrzeby klienta, jak również zmniejszenie ryzyka związanego z jakością oprogramowania.

Kolejnym ważnym, ale nie obowiązkowym, elementem DevOps jest architektura systemu oparta o tzw. mikroserwisy, czyli zestaw “modułów” składających się na całość aplikacji. Takie rozwiązanie daje nam możliwość wydzielenia zespołów do obsługi każdej z części aplikacji, jak również możliwość pracy z nimi w oderwaniu od całości aplikacji.

Dobrymi praktykami wymienianymi w kontekście DevOps są również Continuous Integration oraz Continuous Delivery. Są to jednak na tyle ciekawe i duże tematy, że doczekają się one osobnych artykułów na blogu #białko.

Nie byłoby DevOps bez narzędzi pozwalających na usprawnienie i automatyzację prac zespołu. Narzędzia, o których mowa powyżej mają na celu podniesienie jakości wytwarzanego oprogramowania co w prost przełoży się ma na zwiększenie naszej wiarygodności i możliwości do zaspokojenia potrzeby innowacyjności naszego klienta.

 

DevOps, a zwinne podejście

Czytając o założeniach, filozofii i praktykach DevOps widzimy analogię do zwinnego podejścia do tworzenia oprogramowania. Założenia mojego ulubionego Scruma, wprost adresują kwestie DevOps w następujący sposób:

“Zespół Deweloperski złożony jest z profesjonalistów, których zadaniem jest dostarczenie, na zakończenie każdego Sprintu, „Ukończonego” i gotowego do potencjalnego wydania Przyrostu (ang. Increment) produktu” – Scrum Guide

“Zespoły Deweloperskie są międzyfunkcjonalne, w swoim składzie posiadają wszystkie umiejętności niezbędne do wytworzenia Przyrostu produktu” – Scrum Guide.

Przytoczone przeze mnie powyżej definicje jasno wskazują, że zgodnie z metodyką Scrum Zespół Deweloperski powinien posiadać wszelkie kompetencje i umiejętności pozwalające na wytworzenie przyrostu oprogramowania. Na kompetencje te będą składały się zarówno kompetencje analityczne, programistyczne (Dev), jak i realizacyjne (Ops). Co więcej, zgodnie z definicją “wdrażalny przyrost oprogramowania” zawiera już część “Ops”.

Dodając do tego kluczowy aspekt Scrum, pracę w iteracjach zwanych Sprintami, otrzymamy definicję DevOps.

 

Rewolucja czy ewolucja

Pisząc ten artykuł mierzyłem się z pytaniem – czym DevOps różnią się od Scrum w rozumieniu zespołu deweloperskiego? Czy możemy utożsamiać oba te pojęcia i nadać im to samo znaczenie?

Zarówno DevOps, jak i Scrum są metodykami. Zakładają one iteracyjną pracę, częste dostarczanie rozwiązań czy ścisłą współpracę zespołów nad wytwarzaniem i utrzymaniem oprogramowania. Ale czy są tym samym?

Scrum stoi na stanowisku, aby wszystkie kompetencje związane z wytwarzanym oprogramowaniem znajdowały się w jednym zespole deweloperskim. Ewentualne błędy czy nowe wymagania związane z wdrożeniem oprogramowania powinny każdorazowo trafiać do Backlogu Produktu i przechodzić standardową ścieżkę ich opisu, szacowania czy nadawania wartości biznesowej.

DevOps nie mówi “stwórzcie jeden zespół”. Nie wyjaśnia, w jaki sposób mamy podchodzić do realizacji błędów czy nowych wymagań. Podobnie jak Scrum “to tylko framework”.

Scrum według mnie jest metodyką pełniejszą, bardziej kompletną i adresującą więcej aspektów związanych z tworzeniem oprogramowania. Ale DevOps, jako lekka metodyka, zawierająca szereg naprawdę dobrych praktyk, również bardzo mi się podoba.

Łukasz Bręk

14 lat doświadczenia w IT, 7 lat doświadczenia w Scrum, PSM, PSPO, Scrum Master zespołów zwinnych, Product Owner, analityk biznesowy, trener Scrum

Click Here to Leave a Comment Below

Michał - 12 czerwca 2019

Przeglądając bloga Białko natknąłem się na ten wpis i z przykrością muszę stwierdzić, że autor nie odrobił pracy domowej 🙁
– DevOps ma swoją oficjalną definicję zaproponowaną przez DevOps Institute – jest określane jako “ruch społeczny o charakterze kulturowym i profesjonalnym podkreślający komunikację, współpracę oraz integrację ludzi, procesów i technologii w całym strumieniu
wartości, automatyzujący proces dostarczania oprogramowania i zmian w infrastrukturze.”
– nie wspomniałeś o 3 drogach DevOps
– nie wymieniłeś wartości DevOps (CALMS)
– porównanie DevOps i SCRUM nie ma większego sensu – SCRUM to framework służący do wytwarzania produktów, a DevOps to pewna filozofia działania i zbiór praktyk oraz metod obejmujący cały cykl życia systemów informatycznych (obejmujących utrzymanie, bezpieczeństwo itd).
– SCRUM nie nadaje się do utrzymywania systemów informatycznych – dłuższy wywód i nie na komentarz – wystarczy jednak zastanowić się, jak przeprocesować fixowanie błędów typu P1/P2 na produkcji zgodnie z frameworkiem SCRUM, żeby dojść do wniosku, że to nie ma sensu – lepszym rozwiązaniem jest tutaj Kanban
Łukasz – zachęcam do lektury książek “Project Fenix” oraz “DevOps Handbook”.

Reply
    Łukasz Bręk - 17 czerwca 2019

    Cześć Michał,
    Dzięki za komentarz.

    – Faktycznie, post nie zagłębia się w szczegóły metodyki. Robię to jednak z prostego powodu – jako praktyk zwinnych metodyk postępuje zgodnie z ideą pragmatyzmu. Nie wszystko da się opisać w 600-700 słowach, a taka właśnie długość posta gwarantuje jego poczytność. Ten konkretny wpis i tak został przez nas rozszerzony! Reagujemy jednak na “potrzeby rynku”, dlatego jeśli jest potrzeba (a Twój komentarz świadczy o tym, że jest) będziemy kontynuować temat DevOps w drugiej odsłonie tematu. Zachęcam Cię gorąco do lektury!
    – Co do definicji zaproponowanej przez DevOps Institute – jest to jeden z wielu dostępnych wariantów. Podoba mi się, choć ten dostępny na Wikipedii zawiera wg mnie mniej “wodotrysków”. Mam tylko problem ze stwierdzeniem, że DevOps nazywamy “ruchem społecznym”? Czy słusznie?
    – Porównanie DevOps i Scrum, mimo, że na pierwszy rzut oka nie ma sensu jest działaniem celowym. Wiele osób nie ma pojęcia czym jest DevOps, a porównanie tej metodyki do najbardziej rozpowszechnionej daje im pewien punkt odniesienia.
    – Fixowanie błędów w Scrum nie jest możliwe? Dlaczego? Zgodzę się z Tobą, że Kanban jest wręcz stworzony do tego, ale odpowiednio zestrojony Scrum poradzi sobie z tym zadaniem tak samo dobrze!

    Pozdrawiam
    Łukasz

    Reply
      Michał - 28 czerwca 2019

      Hej Łukasz – dzięki za odpowiedź na mój komentarz. Co do nazywania DevOps ‘ruchem społecznym’ to też mam pewne wątpliwości – zacytowałem dokładnie definicję z DOI. Równie dobrze można DevOps określić mianem filozofii, metodyki, czy zbiorem dobrych praktyk. Każdy będzie miał po części rację 🙂 Na pewno DevOps (podobnie jak Agile) staje się też produktem, na którym niektórzy chcą zarabiać pieniądze …
      Odnośnie wykorzystania Scrum w projektach utrzymaniowych, to jak pisałem dłuższy temat – próbuję napisać o tym artykuł – jak skończę to się podzielę 🙂
      Czołem, Michał

      Reply
Leave a Reply: