MENU

DevOps, czyli wspólna praca developerów i administratorów nad produktem

12 września 2013Polecane tematy, Project Managerowie

Z Wojciechem Ehrenfeldem, dyrektorem Departamentu Publicznych Usług IT w Grupie Onet.pl rozmawiamy o zmianie w sposobie zarządzania pracami nad rozwojem i utrzymaniem produktów w Onet.pl, wdrożeniu metody DevOps, wadach i zaletach tego podejścia.

Wojciech Ehrenfeld Onet3

Jak można najkrócej streścić założenia metodyki DevOps? Które jej założenia są w praktyce najważniejsze?

DevOps to wspólna praca developerów i administratorów nad rozwojem i utrzymaniem produktu.

Kluczowy w tym podejściu jest właśnie produkt, którego rozwój jest planowany w sposób iteracyjny, zgodnie z podejściem SCRUM i CONTINOUS INTEGRATION, ale z jednoczesnym uwzględnieniem zachowania wysokiej jakości i niezawodności działania.

Podejście DevOps, w którym ten sam zespół odpowiada za całość procesów w swoim produkcie powoduje zmniejszenie niepotrzebnej biurokracji.

Czym DevOps różni się od ITIL’a? W czym jest lepszy, w czym gorszy?

ITIL i DevOps nie są przeciwstawne. ITIL to zbiór zdroworozsądkowych, dobrych praktyk, które oczywiście mają identyczne zastosowanie w świecie DevOps, jak i w świecie silosów „Operation” i „Development”. Zespoły DevOps usuwają awarie, rozwiązują problemy, planują maksymalną wydajność i raportują jakość działania własnych usług. Posiadają też „zbiór standardów”, według których powinny działać poszczególne procesy. Jednak podejście, w którym sam zespół odpowiada za całość procesów w swoim produkcie powoduje zmniejszenie niepotrzebnej biurokracji.

Jak wygląda modelowe wdrożenie DevOps, jako metody zarządzania produkcją, rozwojem i utrzymaniem oprogramowania?

Kluczem jest stworzenie produktów, z którymi ludzie się identyfikują. Jeśli to się uda to reszta jest już zdecydowanie prostsza, choć wymaga wysokiej dojrzałości osób pracujących w takich zespołach.

Najważniejsze zalety i wady DevOps?

Wśród najważniejszych zalet wymieniłbym: wzrost zaangażowania i identyfikacja pracowników z produktem, a co za tym idzie z firmą!

Jest wśród nich też elastyczność – możliwość decydowania na bieżąco o różnej intensywności rozwoju i utrzymania w zależności od cyklu życia produktu. Przykładowo, jeśli produkt ma problemy z jakością to decyzją zespołu jest zatrzymanie jego rozwoju i ustabilizowanie produkcji lub odwrotnie, kiedy przygotowywana jest duża, nowa funkcjonalność zespół może podjąć decyzję o zwiększeniu ryzyka związanego np. z dostępnością usługi.

Kluczem do wprowadzenia DevOps w organizacji jest stworzenie produktów, z którymi ludzie się identyfikują. Jeśli to się uda to reszta jest już zdecydowanie prostsza, choć wymaga wysokiej dojrzałości osób pracujących w takich zespołach.

Wśród zalet można wymienić też: „chmurowatość” IT, tzn. różne zespoły pracują nad swoimi produktami niezależnie, ale są one ze sobą połączone znanymi wszystkich zasadami – API. Produkty dzięki temu mogą udostępniać innym „własne” usługi i korzystać z innych. Dodatkowym bonusem planowanie pracy – dość precyzyjnie wiemy, czego możemy oczekiwać w kolejnym dniu, tygodniu, maksymalnie miesiącu.

Najważniejszym zagrożeniem jest zaś – szczególnie w okresie początkowym – brak dojrzałości pracowników w zespołach DevOps, których przerasta wzięcie na swoje barki dużej odpowiedzialności i brak możliwości obarczania swoich niepowodzeń narzucanymi procesami IT. Może to skutkować obniżeniem jakości tworzonych produktów. Potrafię sobie wyobrazić środowiska, gdzie wyżej wymieniona elastyczności będzie niedopuszczalna.

Dlaczego Onet.pl zdecydował się na to podejście? Jakie są najważniejsze korzyści w Waszym przypadku?

To przede wszystkim skrócenie czasu tworzenia nowych produktów oraz konieczność pracy w środowisku cloud computing, gdzie technologia – a co za tym idzie zespoły je rozwijające udostępniają swoje usługi – w XaaS.

Świat usług cloud computing powoduje zacieranie się różnic między Dev i Ops. Przykładowo, jeśli infrastruktura jest zwirtualizowana i zautomatyzowana, to liczba zadań ‚administracyjnych’ maleje powodując szansę na zwiększenie czasu na budowę aplikacji.

Czy DevOps faktycznie powoduje zmniejszenie ryzyka projektowego i usprawnienie komunikacji między różnymi grupami uczestników prac?

Zdecydowanie zmniejsza ryzyko w krótkim terminie. Natomiast wymaga bardzo dobrego planowania terminowego. Tutaj nic się nie zmienia w porównaniu do „tradycyjnego” podejścia. Jednak budowa produktów iteracyjnie daje szanse na lepszy monitoring postępu prac i możliwość podejmowania decyzji w odpowiednim czasie.

W jakim kierunku zmierza, lub w jakim powinien zmierzać rozwój metod DevOps?

W zasadzie świat usług cloud computing powoduje zacieranie się różnic między Dev i Ops. W świecie gdzie infrastruktura jest zwirtualizowana i zautomatyzowana, to liczba zadań ‚administracyjnych’ maleje dając szansę na zwiększenie czasu na budowę aplikacji.

Więcej na ten temat na 6. Kongresie itSMF (19 września, Warszawa), na którym mają być prezentowane inne przykłady zastosowania DevOps w Polsce. ITwiz objął patronat nad Kongresem.

The following two tabs change content below.
Adam Jadczak

Adam Jadczak

O IT w biznesie pisze od 23 lat. Specjalizuje się w zagadnieniach związanych z rynkiem IT oraz informatyką w zastosowaniach biznesowych. Od września 2013 roku redaktor naczelny serwisu ITwiz.pl, od kwietnia 2014 roku redaktor naczelny magazynu ITwiz. Pomysłodawca raportu ITwiz Best 100 „Dwa oblicza IT”, wydanego w czerwcu 2015 roku.

Podobne tematy:

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *

« »