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.