Czym nie jest DevOps?

Dla tych, którzy od lat pracują z DevOps i są mocno zaangażowani w tę metodykę, jej rosnąca popularność jest tak ekscytująca, jak dostanie pierwszej pracy zaraz po studiach! No dobrze, może nie aż tak ekscytująca, ale w dalszym ciągu naprawdę super. Coraz więcej firm wszystkich rozmiarów decyduje się na DevOps, wdrażając praktyki związane z metodyką bezpośrednio w podstawowe strategie.

Z jednej strony taka sytuacja daje zespołom wszystko to, czego potrzebują do rozpoczęcia podróży z DevOps lub do rozwoju istniejących zastosowań w większym stopniu. Z drugiej strony, kiedy metoda ta staje się obowiązkowa, pewna część oddolnej pasji dla niej może przygasnąć, ponieważ samo słowo coraz częściej jest nadużywane lub używane w nieodpowiedni sposób.

DevOps obejmuje nową kulturę współpracy, która uwzględnia liczne praktyki, połączone dla metodologii ciągłego wdrażania oprogramowania. Metodologia ta kładzie znaczny nacisk na pętle informacji zwrotnej, współpracę i ciągłą poprawę. Wymaga fundamentalnych zmian w kulturze i obejmuje tak wiele praktyk, że dla tych, którzy dopiero rozpoczynają podróż z tą metodą, może być to przytłaczające.

Zamiast podkreślania wszystkiego, czym jest DevOps, myślę, że dobrze byłoby podkreślić, czym nie jest.

DevOps nie łączy po prostu zespołów programistów i administratorów

Wszyscy to słyszeliśmy, kiedy ktoś zaczyna mówić o DevOps. „Połączmy zespoły administratorów i programistów i voilà! Mamy DevOps!.” Metoda ta łączy zestaw procesów i praktyk, które należy przyjąć w całym procesie dostawy rozwiązania, a także obejmuje wielu interesariuszy. Kilka kluczowych praktyk w przyjęciu metody obejmuje ciągłe wdrażanie (CI) i ciągłe dostarczanie (CD). Proste połączenie tych dwóch zespołów i nazwanie ich DevOps nie realizuje tych praktyk.

DevOps nie jest oddzielnym zespołem

Ustanowienie oddzielnego zespołu to kolejna pułapka, w którą wpada wiele organizacji zaczynających swoją przygodę z tą metodą. Ogólnie rzecz ujmując, nie jestem fanem zespołu DevOps, ponieważ ostatecznie prowadzi on do większej liczby silosów. Zauważyłem również, że tworzenie takich zespołów może prowadzić do dalszych niejasności, jeśli misja nie została wyraźnie określona.

Istnieją przypadki, kiedy tymczasowe zespoły DevOps mają sens – mogą pomóc w uruchomieniu procesów i potencjalnego oprzyrządowania, koniecznego do przyjęcia tych procesów. Kluczowe jest jednak to, żeby sytuacja ta była tymczasowa, co często lepiej sprawdza się w teorii, niż w praktyce. Można znaleźć kilka świetnych blogów, które omawiają zespoły. Jednym z takich blogów jest blog Matthew Skeltona: „Jaka struktura zespołu jest odpowiednia dla rozwoju DevOps?” (ang. What Team Structure is Right for DevOps to Flourish?)

DevOps nie jest narzędziem

Tak naprawdę niezwykle cieszy mnie rosnąca liczba narzędzi, dzięki którym możemy w dalszym ciągu rozwijać zastosowania DevOps. Zauważyłem jednak, że wykorzystanie jednego lub dwóch narzędzi zaczyna prowadzić do sytuacji, w której DevOps postrzegane jest jako narzędzie. Ile razy słyszałeś:

„korzystamy już z DevOps. Mamy narzędzie Ansible.”
„Wykorzystujemy DevOps. Do automatycznego wdrażania wykorzystujemy narzędzie Jenkins.”

Jestem ogromnym fanem narzędzi typu Ansible, Puppet i Jenkins, jednak myślę, że siła DevOps nie jest w pełni wykorzystywana, jeśli porównuje się wykorzystanie pojedynczego narzędzia do automatyzacji z sukcesem. Zastosowanie automatyzacji i oprzyrządowania oczywiście jest częścią DevOps, jednak jest tak wyłącznie w przypadku połączenia z kompleksowymi praktykami zwiększonej współpracy z ciągłą integracją/ciągłym dostarczaniem, zwiększoną pętlą informacji zwrotnej i ciągłą poprawą (a to tylko kilka przykładów)! DevOps to podróż, a podróż może rozpocząć się od narzędzia. Cel powinien polegać jednak na uprzednim zidentyfikowaniu strategii, a następnie na znalezieniu narzędzia lub łańcucha narzędzi, które ten cel spełnią.

DevOps nie jest strategią, która pasuje do wszystkiego

Ponieważ istnieje tak wiele sił napędzających biznes i technologii, które należy wziąć pod uwagę przy ustalaniu ogólnej strategii dotyczącej przyjęcia metody DevOps, a także identyfikacji łańcucha narzędzi dla tej metodologii, ważne jest zastosowanie tych samych zasad DevOps w strategii związanej z tą metodą. Zaakceptuj zmianę, zbierz metryki, zrozum feedback, szybko ponoś porażkę i prędko wróć na prawidłowy kurs. Przykładowo, jeśli początkowo identyfikujesz narzędzie, które nie sprawdza się już dla danej technologii i środowiska, porzuć je i kontynuuj dalsze działania. Tylko dlatego, że wykorzystałeś je we wcześniejszym projekcie, nie znaczy, że doskonale sprawdzi się przy następnym. Musimy najpierw zrozumieć obecną strategię i środowisko, a następnie odpowiednio reagować.

DevOps nie jest automatyzacją

Takie stwierdzenie mogło przyciągnąć uwagę kilku osób, dlatego wyjaśnię: DevOps nie jest wyłącznie automatyzacją. Automatyzacja stanowi absolutnie ogromną część tej metody, jednak nie jedyną. Wdrożenie pewnego stopnia automatyzacji często stosuje się wymiennie z DevOps. Myślę, że zrozumienie kluczowych praktyk związanych z DevOps stanowi doskonały początek dla zagwarantowania, że metoda ta postrzegana jest jako coś więcej, niż po prostu automatyzacja. Zrozumienie głównych zasad DevOps to klucz do zrozumienia prawdziwych korzyści, jakie płyną z przyjęcia tej metodyki.

DevOps to wiele aspektów – myślę, że moja ogromna pasja dla tej metody nie jest odosobniona. Istnieje również wiele aspektów, którymi DevOps nie jest, lub którymi nie jest wyłącznie. Jeśli dopiero rozpoczynasz swoją podróż z tą metodą lub rozwijasz istniejący już model, upewnij się, że wszystkie osoby w zespole mają podstawową wiedzę na ten temat i są świadomi tego, że strategia związana z DevOps jest kluczowa dla Twojego projektu. Ogromne znaczenie ma pomaganie wszystkim innym w zrozumieniu tego, jak wiele aspektów uwzględnia DevOps. I jak wiele nie uwzględnia.