DevOps
DevOps (akronim od Development i Operations) jest kulturą pracy inżynierów oprogramowania, a jednocześnie zbiorem praktyk dążących do zintegrowania procesu rozwoju oraz procesu wdrażania, utrzymania i obsługi produktu w jednym procesie skupiającym się na ciągłym dostarczaniu wartości w produkcie bezpośrednio do klienta. Najważniejszą cechą tego podejścia jest skupienie organizacji na skracaniu czasu od pomysłu na nową funkcjonalność do zainstalowania jej u klienta z zachowaniem odpowiedniej jakości. DevOps umożliwia przedsiębiorstwom świadczącym usługi za pomocą platform internetowych dostarczanie nowych wersji oprogramowania każdego dnia, jednocześnie oferując innym firmom dostarczającym oprogramowanie skorzystanie z nowych możliwości (Lwakatare L.E., Kuvaja P., Oivo M,2015). Hasłem towarzyszącym wprowadzaniu DevOps do organizacji jest Automatyzacja wszystkiego (ang. Automate everything).
TL;DR
DevOps to kultura pracy inżynierów oprogramowania, która integruje procesy rozwoju, wdrażania i obsługi produktu, skupiając się na ciągłym dostarczaniu wartości klientowi. Historia powstania DevOps wynikała z potrzeby sprawnego dostarczania oprogramowania i integracji zespołów deweloperskich z administratorami systemów. DevOps wykorzystuje automatyzację do skrócenia czasu dostarczania oprogramowania i umożliwia firmom świadczącym usługi internetowe dostarczanie nowych wersji każdego dnia. Narzędzia DevOps obejmują planowanie, tworzenie kodu, ciągłą integrację, wdrażanie, monitorowanie i informację zwrotną. DevOps może być traktowane jako narzędzie zarządzania cyklem życia produktu, a zarządzanie jakością w DevOps polega na integrowaniu testerów systemowych z zespołami deweloperskimi.
Historia powstania
Szybki rozwój zwinnych metod tworzenia oprogramowania szybko obnażył słabości organizacyjne wielu firm. Wypracowane metody Ciągłej integracji, Ciągłego Testowania czy Zwinnego planowania pokazały wady innych części organizacji pracujących w sposób klasyczny. W pierwszej kolejności okazało się, że chcąc sprawnie dostarczać oprogramowanie nie można pozwolić sobie na osobne działy zarządzania jakością i należy oddać tą odpowiedzialność w ręce zespołów deweloperskich. Kolejnym problemem jaki napotkali zwolennicy zwinności był dysonans pomiędzy zespołami deweloperskimi, które dostarczały wartość w sposób szybki i iteracyjny, a administratorami systemów. Administratorzy nie chcieli instalować aktualizacji po każdej iteracji, ponieważ była ona zbyt kosztowna i ryzykowna. Uniemożliwiało to bieżące zbieranie informacji zwrotnej na temat wprowadzonych w kodzie zmian.
Andrew Shafer i Patrick Debois, którzy spotkali się na konferencji Agile 2008 w Toronto, przedstawili na tej samej konferencji koncepcję Zwinnej Infrastruktury (Debois P.,2008). Rok później Patrick Debois zorganizował pierwszą konferencję DevOpsDays w Gandawie (Debois P.,2009). Następnie idea spotkała się z gorącym przyjęciem zwłaszcza w dużych korporacjach oferujących usługi oparte na sieciach komputerowych. Dość powiedzieć, iż praktyki DevOps używane są w takich firmach jak Amazon, Netflix, Flickr, IBM, a Microsoft stworzył nawet własną odmianę zwaną WinOps.
Zapytany o genezę nazwy Patrick Debois stwierdził w jednym z wywiadów, iż powstała ona przez przypadek dlatego, że określenie Zwinna Administracja Systemu było zbyt długie i potrzebował czegoś krótszego aby reklamować swoje konferencje.
Idea DevOps
DevOps rozszerza zakres działalności samodzielnych zespołów deweloperskich pracujących z sposób zwinny o możliwość administrowania systemem który tworzą. Wykorzystuje w tym celu paradygmat Ciągłego Wdrażania który mówi, że zespół tworzy i testuje oprogramowanie na środowisku identycznym ze środowiskiem produkcyjnym. Znaczy to, iż każda zmiana wprowadzona i przetestowana przez zespół deweloperski, może potencjalnie zostać zainstalowana u klienta. Wymaga to zastosowania narzędzi, które w sposób ciągły i szybki potrafią zbudować produkt ze zmodyfikowanego kodu, wprowadzić go do systemu którego jest częścią, w sposób automatyczny zainstalować na docelowych urządzeniach, wykonać testy funkcjonalne gotowego rozwiązania, a następnie mieć potencjalną możliwość instalacji u klienta. Znalezienie błędu na którymkolwiek z tych kroków powoduje wycofanie zmiany i dodatkową pracę deweloperów nad usprawnieniami.
W największym skrócie DevOps identyfikuje łańcuch wartości dostarczanej do klienta i sposób jej dostarczania, następnie określa kroki które zachodzą pomiędzy tworzeniem funkcjonalności a dostarczeniem jej do klienta, aby w końcu zautomatyzować cały proces.
Wykorzystanie DevOps może wydawać się kwestią techniczną, jednak w gruncie rzeczy jest problemem biznesowym, wpływającym na kreowanie przewagi konkurencyjnej przedsiębiorstwa. Dzieje się tak ponieważ firma zyskuje możliwość dostarczania wartości dokładnie odpowiadającej oczekiwaniom klienta (dzięki utrzymaniu go w pętli sprzężenia zwrotnego w trakcie rozwoju produktu) oraz wprowadzania technologii na rynek wcześniej niż konkurencja (dzięki skróceniu czasu od pomysłu do produkcji).
Narzędzia DevOps
Funkcjonuje kilka modeli opisujących łańcuch narzędzi wykorzystywanych przez DevOps spośród których można wyróżnić poniższy:
- Planowanie - zwinne planowanie z użyciem narzędzi do śledzenia postępów,
- Tworzenie - tworzenie kodu z wykorzystaniem kontroli wersji,
- Ciągła integracja - automatyczne tworzenie produktu po każdej zmianie w kodzie, testy na poziomie oprogramowania,
- Wdrażanie - automatyczna instalacja oprogramowania w środowisku produkcyjnym lub u klienta,
- Monitoring - automatyczne testy na poziomie systemu lub zbieranie informacji od użytkownika,
- Informacja zwrotna - automatyczna obsługa informacji o koniecznych zmianach (stąd powrót do planowania).
Często są one przedstawiane w graficznej formie pętli symbolizującej ciągły proces zarządzania produktem. Ostatnie trzy punkty mogą się odbywać w laboratorium testowym firmy lub u klienta. Mówi się, że każda firma używająca DevOps musi mieć możliwość Ciągłego Wdrażania (ang. Continous Deployment), jednak nie każda musi, a nawet niektóre nie powinny mieć możliwości Ciągłego Dostarczania (ang. Contionuos Delivery). W przypadku firm świadczących usługi poprzez własne internetowe platformy (np. sklep internetowy) nie ma przeszkód do aktualizowania oprogramowania na serwerze nawet kilka razy dziennie. W innych przypadkach (np. systemy bezpieczeństwa publicznego) należy poprzedzić każdą zmianę długotrwałymi testami we własnym laboratorium w celu zapewnienia nie tylko wysokiej jakości, ale też bezpieczeństwa sieci.
Rola DevOps w zarządzaniu cyklem życia produktu
W świetle coraz szerszego zastosowania DevOps wiele osób zadaje pytanie jak można odnieść te praktyki do klasycznego zarządzania cyklem życia produktu i praktyk takich jak ALM (Aplication Lifecycle Management). Według niektórych źródeł (Fry E.,2017) można potraktować DevOps jako narzędzie ALM, ponieważ klasyczne zarządzanie cyklem życia produktu odnosi się do szerszej perspektywy między innymi do wizji wejścia produktu na rynek i zakończenia jego rynkowej obecności, a w tym kontekście DevOps pełni jedynie rolę pomocniczą.
Zarządzanie jakością w DevOps
DevOps wywodzący się bezpośrednio ze Zwinnego Tworzenia Oprogramowania także odrzuca zarządzanie jakością jako osobny proces oddzielony od tworzenia. Idzie przy tym o krok dalej, ponieważ zespoły Scrumowe często produkowały oprogramowanie w iteracjach "na półkę" natomiast było ono testowane na poziomie systemowym dopiero gdy było gotowe do wypuszczenia na rynek, przez osobny dział zajmujący się Testami Systemowymi. Przy wykorzystaniu DevOps istnienie Testów Systemowych jako osobnej jednostki organizacyjnej pracującej w zupełnie inny sposób staje pod silnym znakiem zapytania. Nie znaczy to jednak, że testerzy systemowi nie są już potrzebni, a wręcz przeciwnie. Znając proces instalacji, konfiguracji i testowania całego systemu stają się kluczowymi osobami odpowiedzialnymi za automatyzację Testów Systemowych. Mogą także stać się częścią zespołów deweloperskich edukując innych inżynierów i wnosząc nowy punkt widzenia w działalność twórczą, wpływając przy tym na podniesienie jakości produktu oraz propagowanie myślenia systemowego wśród inżynierów oprogramowania.
Bibliografia
- Balalaie A., Heydarnoori A., Jamshidi P. (2016), Microservices Architecture Enables DevOps: An Experience Reporton Migration to a Cloud-Native Architecture, IEEE Software Volume: 33 Issue: 3
- Bang S., Chung S., Choh Y., Dupuis M. (2013), A Grounded Theory Analysis of Modern Web Applications - Knowledge, Skills, and Abilities for DevOps, Proceedings of the 2nd annual conference on Research in information technology
- Bass L., Weber I., Zhu L. (2015), DevOps: A Software Architect's Perspective, Pearson Education, Inc
- Debois P. (2008), Agile 2008 Toronto, Agile Conference Toronto
- Dyck A., Penners R., Lichter H. (2015), Towards Definitions for Release Engineering and DevOps, 2015 IEEE/ACM 3rd International Workshop on Release Engineering
- Fry E. (2017), ALM, SDLC, and DevOps: Which Witch is Which?
- Hüttermann M. (2012), DevOps for developers, Apress
- Lwakatare L., Kuvaja P., Oivo M. (2015), Dimensions of DevOps, Springer, XP 2015: Agile Processes in Software Engineering and Extreme Programming
- Strona internetowa: Oryginalna strona konferencji DevOpsDays 2009 Ghent
- Waller J., Ehmke N., Hasselbring W. (2015), Including Performance Benchmarks into Continuous Integration to Enable DevOps, ACM SIGSOFT, Software Engineering Notes archive Volume 40 Issue 2
Autor: Marcin Ziarnik
