Współcześnie jedną z najbardziej rozchwytywanych profesji w IT jest osoba nazywana potocznie DevOps. Ofert pracy jest multum, jednak w przeciwieństwie do wielu innych specjalizacji nie dają one same w sobie informacji o tak ważnych sprawach, jak wymagania w zakresie języków programowania, frameworków, znajomości baz danych, narzędzi konteneryzacji albo wirtualizacji.

Oczywiście zazwyczaj sprawy te są doprecyzowane w szczegółach ofert, ale niedoświadczonym oraz osobom, które chcą rozpocząć pracę w IT hasło DevOps może niewiele mówić. Jednocześnie DevOps nie bez powodu określa się mianem najgorętszego zawodu w całej branży – trąbi się o tym temacie na blogach, na YouTube, TikToku i w innych mediach społecznościowych i to nie od wczoraj. Jest z tym tylko jeden problem – DevOps to nie jest zawód.

DevOps to standard pracy

Gdy ktoś określa się jako programista DevOps lub gdy napotykasz taką ofertę pracy, oznacza to tylko tyle, że chodzi o programistę, który nauczył się pracować w kulturze DevOps. Trzeba więc w pierwszej kolejności odpowiedzieć na pytanie, czym ona jest, a to nie należy do najłatwiejszych zadań w teorii, jeśli ktoś nie miał z nią w praktyce do czynienia. Kwestia ta jest dość obszerna i łatwiej wskazać zespół pracujący zgodnie z zasadami DevOps, niż teoretyzować.

Jest jednak kilka rzeczy, bez których o DevOps nie może być mowy. Ważne, żeby zauważyć, że są one ściśle i wzajemnie powiązane. Można powiedzieć, że wynikają z siebie i są nierozerwalne. Pierwszą z czynników składających się na DevOps z prawdziwego zdarzenia jest przyjęcie ciągłej integracji i ciągłego (CI/CD) wdrażania zmian w oprogramowaniu. Dzięki niemu powstaje szereg etapów, dzięki którym zmiany są na bieżąco sprawdzane i pozwalają uniknąć błędów w kodzie produkcyjnym. Budowanie oprogramowania z użyciem CI/CD trudno sobie wyobrazić bez systemów kontroli wersji, z których najpopularniejszym jest git. Całość procesów porządkuje metodologia pracy Scrum, a przestrzenią pracy najczęściej jest środowisko chmurowe.

Omówimy teraz szerzej każdy z tych elementów, trzeba jednak odnotować, że o ile są one fundamentalne dla DevOps, to nie są jedyne. W każdej firmie produkującej oprogramowanie DevOps może oznaczać odrobinę coś innego. Są też sytuacje, kiedy wiele mówi się o DevOps, a w sumie niewiele się robi w kierunku, by przyjąć ten – nazwijmy to na nasze potrzeby – standard bądź kulturę pracy.

Continuous Integration/Continuous Delivery

Problemem w pisaniu oprogramowania jest to, że zazwyczaj konieczne jest łączenie efektów pracy wielu osób. Każdy w dajmy na to 10-osobowym zespole wprowadza swoje modyfikacje, pracuje nad swoimi zmianami, uprawia swój ogródek. Ale wszystkie to ścieżki trzeba w końcu spiąć w jedno, tak by powstał końcowy program. Jeśliby jednak pozwolić na to, a było tak w historii, poszczególne zmiany pochodzące od różnych deweloperów, okazały się skonfliktowane, wówczas konieczny byłby jeszcze ogrom pracy już po zakończeniu kodowania. Po momencie spięcia jedno mogłoby się okazać, że nic nie działa.

Aby pozbyć się ryzyka wystąpienia takich sytuacji opracowano ciągła integrację (CI). W tym reżimie poszczególni programiści mogą w sposób ciągły, na bieżąco sprawdzać kompatybilność efektów swojej pracy. Współtworzą oni repozytorium, czyli miejsce gdzie przechowywana jest całość kodu programu. Tam zapisują swoje zmiany, dokonując w ten sposób integracji. Gdy wystąpią jakieś problemy, mogą zidentyfikować ich pochodzenie na zasadzie zwykłej chronologii i wycofać wchodzące w konflikt zmiany, a programista może poprawić błędy w kodzie.

Kolejnym etapem jest ciągłe dostarczanie. Tutaj chodzi o przenoszenie kodu z pierwotnego repozytorium na tzw. produkcję. Czyli do tego programu, który trafi użytkowników. Dzięki CD przyjmuje się, że lepiej dostarczać zmiany w mniejszych, ale częstszych porcjach. Cały proces jest w dużej części automatyczny, ale nie całkowicie automatyczny, co różni go od Continuous Deployment. W pierwszym przypadku konieczne jest zatwierdzenie ostatniego etapu łączenia zmian z główną gałęzią produkcyjną, a w przypadku Continuous Deployment po przeprowadzeniu wszystkich testów są one łączone z nią bez czyjegokolwiek udziału.

CI/CD dla wielu jest synonimem DevOps, ale obu tych terminów nie należy mylić. DevOps jest czymś szerszym, choć jak już sobie wyjaśniliśmy, nie istniałby, gdyby nie CI/CD.

git

Z kolei CI/CD nie istniałoby, gdyby nie system kontroli wersji. Współcześnie najpopularniejszy jest git i raczej szybko się to nie zmieni. Przy omawianiu CI/CD poruszyliśmy kwestię repozytorium – najpopularniejszym dostawcą takich usług jest dzisiaj GitHub, który swoją nazwę wziął właśnie od gita, co pokazuje jakim zainteresowaniem się cieszy. Nie cieszy się jednak zbytnią sympatią samych programistów. Wielu twierdzi, że jego obsługa jest zbyt skomplikowana. Ale czym w ogóle jest system kontroli wersji? Najprościej mówiąc, jest to narzędzie pozwalające na śledzenie wszystkich zmian dokonywanych w kodzie. Dzięki temu widoczne są wszystkie operacje przeprowadzane na kodzie.

Jeśli kiedyś słyszałeś coś o pull requestach lub merge’ach to mowa była właśnie o gicie. Są to jedne z operacji, jakie przeprowadza się w procesie CI/CD, a zarazem w standardzie DevOps. Co ważne, git jest rozproszonym systemem kontroli wersji, działa na zasadzie P2P i każda z osób pracujących nad danym programem przechowuję swoją instancję i później je synchronizuje. Ważną rzeczą podczas posługiwania się gitem jest kultura należytego opisywania wszystkich poleceń, tak aby były one czytelne dla pozostałych członków zespołu pracującego nad programem. Najczęściej kwestia ta wypracowywana jest indywidualnie wewnątrz danej firmy czy zespołu, choć nie brakuje w Internecie licznych tekstów opisujących najlepsze praktyki.

Scrum

Skoro jesteśmy już przy kulturze pracy, to trzeba omówić Scruma. Scrum wiążę się bardziej z biznesową, organizacyjną stroną produkcji programowania, niż z techniczną. Jest to takie podejście do organizowania projektów, aby dzielić je na mniejsze, następujące etapy nazywane sprintami. Poprzedzone są one jednak tzw. Product Backlogiem, to jest ustaleniem wszelkich początkowych założeń, oczywiście z uwzględnieniem potrzeb klienta, dla którego pisze się oprogramowanie. Potem następują sprinty, w których te założenia są realizowane. Po zakończeniu projektu organizuje się jeszcze Sprint retrospektywny podsumowujący sukcesy i porażki poczynione podczas realizacji projektu.

Oprócz tego Scrum zakłada także inne elementy kultury pracy. Na przykład zespół wykonujący dany sprint sporządza Sprint Backlog, czyli listę rzeczy, które deklaruje, że w danym sprincie zrobi. Jest jeszcze Daily Scrum, czyli spotkanie zespołu, najczęściej przeprowadzane podczas rozpoczynania dnia pracy, w którym każdy dzieli się z resztą swoimi dokonaniami i załatwia sprawy bieżące. Scrum to praktyczna realizacja tzw. zwinnego (agile) podejścia do pracy i produkcji programów – całość ma bazować na powtarzalności sprintów, dzielenia procesów na części i w ten sposób sprawniejszego rozwiązywania problemów i dostarczania produktów klientowi zgodnie z jego potrzebami.

Chmura

Wiemy już trochę o części Dev z terminu DevOps. Czas zając się drugim członem, czyli sprawami operacyjnymi. DevOps jako nowoczesny standard pracy odchodzi od stosowania infrastruktury lokalnej, przy której konieczne jest samodzielne utrzymywanie na przykład serwerów i sieci przez firmę produkującą oprogramowania. Zamiast tego wykorzystywane są usługi chmurowe, które pozwalają pokonać trudności operacyjne i organizacyjne. Bardzo często jest jednak tak, że projekty wymagają modelu łączącego lokalną infrastrukturę (on-premise) i usług zewnętrznych, co jednak nie zmienia faktu, że przy DevOps konieczne jest w 99% poleganie choćby częściowo na zewnętrznych usługach. Na niewiele się tu zdadzą dowcipy, że chmura to po prostu komputer, tylko czyjś, co zresztą jest samą prawdą.

Kwestie operacyjne w IT w ostatnich latach bardzo szybko się zmieniają. Pojawiają się coraz to nowe produkty, ale dostarczane w formie usług. Kolejne platformy programistyczne (PaaS) przenoszą się do chmury, a komputery, z których korzystają programiści, same w stanowią tylko okno na chmurę i terminal pozwalający uzyskać do niej dostęp. Nie inaczej jest w standardzie DevOps, o którym można powiedzieć, że w dużej mierze stał się kołem zamachowym zachodzących bardzo szybko w infrastrukturze zmian. Od lat zaczyna to już przecież nie tylko IT, ale także osób zupełnie niezwiązanych z branżą, czego przykładem jest oprogramowanie dostarczane jako usługa (SaaS), które w całości lub częściowo działają w chmurze.

To kim jest ten DevOps?

Standard DevOps zakłada łączenie wielu różnych elementów o zróżnicowanym typie: oczywiście w pierwszej kolejności technicznym, ale tez biznesowym oraz (czego w żadnym wypadku nie należy pomijać) kulturowym. Programista DevOps to zatem taki deweloper, który potrafi pracować zgodnie z CI/CD, stosuje określoną kulturę pracy i potrafi wykorzystywać wszystkie narzędzia niezbędne do realizacji takich celów. Nie można zakładać, że chodzi wyłącznie o znajomość jakiegoś języka programowania czy frameworku – te sprawy zależą od danej firmy, zespołu, a najczęściej samego projektu. To pod jego kątem powinno dobierać się właśnie narzędzia programistyczne, a nie odwrotnie. W uproszczeniu można powiedzieć, że DevOps to sposób na pracę, a nie sama praca.

Pojawia się jeszcze pytanie: dlaczego tak dużo się o nim mówi? Wszystko wskazuje, że DevOps zyskał swoją popularność, bo zwyczajnie działa. Pozwala ograniczyć występowanie błędów i konieczność kosztownego ich naprawiania, można dzięki niemu lepiej i szybciej odpowiadać na potrzeby klienta, oszczędzać czas i pieniądze i pokonywać ograniczenia operacyjne. Dzięki DevOps każdy programista wie, co robi sam, co robi jego kolega z teamu i ma dostęp do czytelnych informacji o zachodzących w produkcie zmianach. W tak szybko zmieniającej się branży jak IT trudno coś przewidywać ze stuprocentową pewnością, ale nie zapowiada się, by popularność DevOps miała zmaleć. Wręcz przeciwnie, to raczej wszystkie zespoły, które dotąd nie stosują tego standardu, wkrótce zmienią zdanie.