DevOps to popularna metoda na organizację pracy związanej z produkcją oprogramowania. Pojęcie DevOps bywa różnie rozumiane i już właściwie z tym pierwszym zdaniem jest pewien problem. Niektórzy traktują DevOps bardziej jako filozofię lub „mindset” charakteryzujący ludzi współpracujących nad projektem, inni z kolei skupiają się na szerokim zakresie technologii, który musi zostać opanowany przez inżyniera DevOps, jeszcze inni kojarzą DevOps z narzędziami pracy jak np. Jira, PipeLines albo procesami build & deployment.
I rzeczywiście najlepiej jest traktować DevOps jako zbiór: zachowań i kultury współpracujących programistów i inżynierów, procesów, w ramach których oni pracują oraz technologii i narzędzi z jakich korzystają. W zależności od firmy, większa waga będzie przyłożona do tego lub innego elementu składowego, ale każdy z nich w jakimś stopniu musi występować.
Gdyby nikt nie wymyślił pojęcia DevOps, to pewnie nazwalibyśmy go ekstremalną automatyzacją w programowaniu, bo przecież celem pracy programisty i inżyniera jest szybkie tworzenie kodu, testowanie go i dostarczanie do klienta. Ma być nie tylko szybko, ale jeszcze dobrze pod względem jakości, a co poniekąd z tego wynika – może nie tanio, ale ekonomicznie, a przyjęło się sądzić, że to niemożliwe żeby było szybko, dobrze i tanio. Jak to jest osiągane?
- Programista, jak to programista – zamienia kofeinę i pizzę w kod. Tak jak zwykle to robił, wysyła swój kod do repozytorium kodu (GitHub, GitLab, etc). I tu zaczyna się akcja. Programista chciałby prędko swój kod zobaczyć w akcji i przetestować go. Dlatego…
- Po przesłaniu kodu uruchamia się proces, który automatycznie buduje rozwiązanie, np. w zależności od potrzeb kompiluje go, umieszcza gdzie trzeba…
- Wykonuje serię automatycznych testów, które potwierdzają, czy kod jest dobry czy wadliwy. Jeśli wszystko się udało, to…
- Dostarcza go do docelowego środowiska – tam testom podlega już nie pojedynczy komponent, ale cała aplikacja. Jeśli wszystko poszło dobrze – programista dostaje łyk coli
Sęk w tym, że ten automatyczny proces trzeba umieć zbudować. Dlatego może i mniej programista, ale bardziej inżynier musi zbudować ów potok zdarzeń, utrzymać go, zrozumieć aplikację i jej wymogi. A wymogi aplikacji są różne.
Mamy setki języków programowania, baz danych, metod uwierzytelnienia, mechanizmów zabezpieczających itp. Z tego wynika konieczność znajomości wielu różnych technologii. Nie wystarczy już świetnie znać system operacyjny. Trzeba umieć poskładać całą aplikację! Nie zapominajmy przy tym, że obecnie aplikacja, to coraz rzadziej jeden plik exe, który gdzieś należy wgrać. Aplikacja zwykle korzysta z kilku serwerów, baz, interfejsów łączących tą aplikację z innymi systemami itp. Dlatego w DevOps triumfują również języki pozwalające budować tą wymaganą infrastrukturę, jak np. Terraform.
A jeśli do tego dodamy, że praca jest skomplikowana i wymaga rozwiązywania pojawiających się problemów zespołowo, to okaże się, że konieczne jest użycie narzędzi pozwalających na sprawną organizację pracy. Na szczęście w DevOps nie stosuje się typowego gigantycznego narzędzia do dokumentowania pracy. Zamiast tego wybiera się bardziej intuicyjne metody jak Kanban, czy Jira Boards. Łatwiej przecież zamknąć sprawę przekładając karteczkę z części „Working on” do części „Done”, niż zamknąć ticket wypełniając dziesiątki nikomu do niczego niepotrzebnych pól.
Nie ma co ukrywać – żadne narzędzie nie ogarnie pracy, jeśli ludzie nie chcą współpracować, a żaden Project Manager zwany tu często Scrum Masterem nie zrozumie o co w tym chodzi, jeśli sam nie jest doświadczonym DevOps inżynierem. Dlatego koniec końców cała odpowiedzialność i tak spada na specjalistów technicznych, którym mówi się, że pracują w modelu „shared responsibility”. I coś w tym jest! Zespoły DevOpsowe z założenia mają być bardziej otwarte i komunikatywne. Błąd jest po prostu naturalnym krokiem w kierunku zdobywania doświadczenia, dlatego , mimo konieczności ciągłej nauki, poznawania nieznanych technologii, pracy w intensywnie zmieniającym się środowisku, DevOps daje poczucie pracy w całkiem innej kulturze. Kulturze wzajemnego zrozumienia, otwartości, komunikacji – a to ważne elementy redukujące charakteryzujące dobre stanowisko pracy.
