DevOps – jeden skrót, wiele znaczeń

Choć ostatnio o DevOps jest coraz głośniej, jego znaczenie nadal nie jest tak oczywiste, jak czasem potocznie się uważa i jak mogłoby to wynikać z samej definicji. W tym artykule przedstawię więc różne podejścia do tego zagadnienia.

Będzie to jednak dopiero początek naszej serii. W kolejnych publikacjach skupimy się na tym, jak w Craftware rozumiemy DevOps i jak pracujemy zgodnie z tą metodą. Co oznacza dla nas w praktyce, z technologicznego punktu widzenia? Jakie korzyści biznesowe daje naszym klientom? Zapraszamy do świata DevOps!

 

DevOps Specialist i DevOps Engineer, czyli “człowiek od DevOps”

Jedno z podejść do DevOps nazywamy narzędziowym. Na czym ono polega? Najprościej mówiąc na zatrudnieniu w organizacji lub zespole osoby odpowiedzialnej za narzędzia, z których korzystają developerzy. Zatem jeśli korzystają oni z repozytorium kodu, zadaniem specjalisty DevOps jest to repozytorium przygotować i skonfigurować. Osoba na takim stanowisku jest zazwyczaj specjalistą po części z UNIX, a po części z programowania.

Czemu służy takie podejście? Celem jest oczywiście odciążenie developerów. Jeśli mają oni wsparcie ze strony specjalisty DevOps, mogą zająć się tylko tym, czym – w świetle tego podejścia – powinni, czyli pisaniem kodu i przygotowywaniem kolejnych wersji aplikacji.

Skąd wzięła się taka praktyka? Przede wszystkim stąd, że szersze podejście do DevOps – to, w którym pracujemy w Craftware (o czym więcej w kolejnych artykułach), rozumiane jako połączenie developmentu i operacji – jest trudniejsze w realizacji. Nie każda organizacja i nie każdy zespół są w stanie sobie z tym poradzić i wprowadzić takie podejście do pracy i wytwarzania oprogramowania. Zatrudnia się więc specjalistów DevOps, bo jest to wygodne rozwiązanie: developerom jest łatwiej, mają mniej obowiązków i nie muszą zwiększać zakresu swoich kompetencji. Ale czy przynosi to realne korzyści? I tak i nie – ale o tym w dalszej części artykułu.

 

DevOps, czyli więcej niż narzędzie

DevOps ma więc także wspomniane drugie oblicze, bardziej holistyczne, oznaczające metodę pracy – jednoczesnego wytwarzania nowych funkcjonalności i usprawniania oraz poprawiania tego, co już zostało wdrożone wcześniej.

Zanim organizacje przekonały się do tego podejścia, development i operacje funkcjonowały jako oddzielne byty. Po jednej stronie były nowe releasy, po drugiej – wsparcie produkcji, rozwiązywanie incydentów i błędów. Z czasem okazało się, że przysparza to problemów.

Przekazanie przez developera do zespołu wsparcia nowego wycinka prac łączyło się z transferem wiedzy, czyli logiki zaprojektowania i obsługi danego elementu. Ryzyko, że coś umknie po drodze, było nieuniknione. Dochodziła też dodatkowa kwestia: jak zagwarantować, że poprawki, wprowadzone po stronie operacji, na pewno w odpowiednim czasie trafią do developerów i że w ogóle trafią? Skoordynowanie prac obu zespołów stawało się coraz trudniejsze.

Na bazie tych doświadczeń powstała idea DevOps – jednego zespołu, zajmującego się jednocześnie developmentem i operacjami, wytwarzającego nowe funkcjonalności i naprawiającego błędy.

 

DevOps – korzyści dla zespołu, korzyści dla biznesu

Jak na wprowadzeniu takiego podejścia zyskuje zespół pracujący nad projektem, czyli DevOps Team? To oczywiste – tam, gdzie jest ciągłość komunikacji, nie trzeba skupiać się na koordynacji i pilnowaniu, by nie umknęły nam istotne szczegóły, pracuje się szybciej i efektywniej. Widać, co wdrażamy i w jaki sposób – a to gwarantuje pełną kontrolę nad projektem, poprawę płynności pracy, wyższą jakość produktu.

A co zyskuje klient, czyli biznes? Przede wszystkim widzi jeden zespół, a to ważny sygnał – że praca idzie bardziej płynnie. Najważniejsze są natomiast oszczędności, które niesie praca w podejściu DevOps, wynikające z tego, że nie trzeba duplikować ról. Dla przykładu: jeśli mamy do dyspozycji jednego testera i potrzebujemy go zarówno w developmencie, jak i w operacjach (gdy funkcjonują jako oddzielne zespoły), oznacza to więcej godzin pracy i generuje większe koszty. W podejściu DevOps jedna osoba łączy obowiązki z obydwu obszarów.

Metoda pracy DevOps nie dotyczy zatem, co pokazuje powyższy przykład, tylko developerów – jak czasem błędnie się przypuszcza – ale różnych osób, które pracują w projekcie. Nasze craftwarowe DevOps Teams, które realizują dla klientów projekty w technologii Salesforce, to właśnie takie wielozadaniowe zespoły, które są odpowiedzialne i za development, i za operacje.

 

DevOps, czyli jeden za wszystkich, wszyscy za jednego

Czasem spotykam się również z takim rozumieniem idei DevOps: zakłada ono pełną wymienność. Uważa się, że zwłaszcza w metodologii Agile zespół DevOps to taki, w którym każdy jest w stanie przejąć rolę każdego.

Moim zdaniem, to za daleko idące oczekiwania, bo choć możliwe do zrealizowania, to tylko w pewnym zakresie. Developer może zająć się testowaniem, ale czy tester zastąpi developera? Niekoniecznie. A co ze zgłoszeniami od użytkowników, dotyczącymi wersji wdrożonych na produkcję? Znowu: teoretycznie developer mógłby zająć się obsługą zgłoszeń. Ale czy świetny developer równie dobrze sprawdzi się w kontakcie z użytkownikiem? Nie każdy ma cechy osobowości predysponujące go na określone stanowisko. Pamiętajmy też, że dziś w cenie jest specjalizacja i najbardziej poszukiwani są eksperci w swojej dziedzinie. Nie oczekuje się, że każdy będzie potrafił wszystko.

Jak zatem budujemy nasze DevOps Teams w Craftware? Jak organizujemy pracę tych zespołów? Łączymy w nich development i operacje, ale nadal w zespołach wydzielone są role i każda osoba ma swój obszar specjalizacji. Przykładem jest wspomniany support, do którego delegujemy osoby z rozwiniętymi umiejętnościami miękkimi. Oczywiście, nasz specjalista od wsparcia, po przyjęciu zgłoszenia od użytkownika, może dokonać prostej zmiany w systemie, ale nie będzie jednocześnie developerem.

Chcesz dowiedzieć się więcej o naszych craftwarowych DevOps Teams i korzyściach, jakie mogą przynieść dla Twojej organizacji? Przeczytaj nasz kolejny wpis: DevOps od podszewki, czyli jak to działa?

Autor
  • Łukasz Pietrzak
  • Co-founder Craftware, Co-CEO Craftware
  • Absolwent wydziału Elektroniki i Technik Informacyjnych Politechniki Warszawskiej. Karierę rozpoczynał jako programista, a później lider zespołu programistów Java. Współzałożyciel firmy Craftware w roku 2009. Od tego czasu nosił wiele „kapeluszy” – analityka, architekta, programisty, partnera zarządzającego.

    Od roku 2011 zaangażowany w rozwój systemów opartych na platformie Salesforce, w której bardzo ceni możliwość szybkiego dostarczania pełnowartościowych rozwiązań oraz bliską pracę z partnerami biznesowymi. Prawdziwy pasjonat tej technologii – kilkukrotny uczestnik największej na świecie konferencji Dreamforce w San Francisco, posiadacz  certyfikatów sprawdzających wiedzę o systemie Salesforce. Współpracował zarówno z korporacjami jak i startupami.

    Prywatnie entuzjasta sportów zespołowych oraz gier typu MMO.

Opracowanie redakcyjne:
Ania Sawicka
Korekta redakcyjna
Aleksandra Pasek
Korekta językowa
Podobał Ci się mój artykuł?

Jeśli tak, zapraszam Cię do grona najlepiej poinformowanych czytelników bloga. Dołącz do naszego newslettera, a nie ominą Cię żadne nowości.