DevOps oznacza, że ​​programiści biorą teraz odpowiedzialność za infrastrukturę i wydanie - ale jakie są przyczyny tej zmiany?

DevOps oznacza, że ​​programiści biorą teraz odpowiedzialność za infrastrukturę i wydanie - ale jakie są przyczyny tej zmiany?

Odłożę moje karty na stół: jestem programistą i pracowałem zarówno w „DevOps”, jak i poza kulturami. Konieczność martwienia się infrastrukturą, wydaniami, kontrolą jakości i związaną z tym ceremonią to wielka odwaga od pisania dobrego kodu.

Ale branża zmierza w tym kierunku, więc jakie są tego przyczyny? Jakie problemy zrodził „stary” model specjalizacji ról?

Głównym powodem jest chmura.

Kiedyś kod był wysyłany na dyskietkę, a następnie na CD, a następnie wdrażany na serwerze, a następnie wdrażany na dwóch serwerach (w celu zapewnienia odporności) ... Całe to wdrożenie można wykonać ręcznie przez człowieka, więc ludzie zostali przeszkoleni w tym zakresie.

Dzisiaj twój kod często trafia na dziesiątki lub setki serwerów. Inicjowanie, konfigurowanie i wdrażanie na tych serwerach nie może być realistycznie wykonane ręcznie przez człowieka. Potrzebujesz od administratorów sys wystarczającej wiedzy na temat skryptów, aby zautomatyzować ten proces, ponieważ teraz używasz szefa kuchni lub jego krewnych. Ale szczerze mówiąc, nie było wystarczającej liczby administratorów systemu, którzy mogliby to zrobić. Więc deweloperzy zostali wciągnięci, aby podnieść luz.

I tak, dodanie większej liczby umiejętności do stale rosnących wymagań deweloperów w naturalny sposób zmniejszy ich kompetencje w innym miejscu. Pomysłem jest to, że pozwala na wgląd w proces dev build / release, mogą przewidywać problemy lepiej, czy mają autonomię, aby ją poprawić. Chodzi o to, że jakość wszystkiego rośnie, odkąd wygrana wersja wyprzedza straty związane z pisaniem kodu.

Jestem sceptycznie nastawiony do tego, że kompromis jest tego warty tak często, jak się to wydaje.

Istnieje wiele różnych powodów, dla których różne organizacje przechodzą na DevOps.
Spróbuję wymienić te, które często się pojawiają.

Skróć czas na zmianę cyklu
Często zdarza się długi czas między złożeniem wniosku o zmianę a faktycznym wdrożeniem i użyciem w organizacji. Najpierw jest planowany przez programistów w jednym z cykli programistycznych, a po dostarczeniu planowany w jednym z cykli wydawniczych. Oba cykle obejmują testowanie, aw przypadku wykrycia problemów oba cykle resetują się. Integrując działy rozwoju i operacji, możemy usprawnić oba procesy.

Oprogramowanie a problemy sprzętowe
Pamiętasz kreskówkę Królik Bugs, w której Bugs i Daffy kłócą się, czy to sezon na kaczki, czy na sezon królika? Teraz wyobraź sobie, że zamiast tego zrobiliśmy to z programistami i operacjami, w których programiści twierdzą, że jest to problem sprzętowy, a operacje twierdzą, że jest to problem z oprogramowaniem. Dla użytkownika końcowego jest to rozróżnienie bez różnicy. Chcą tylko to naprawić.
Łącząc programistów i operacje, będą musieli rozwiązać problemy. I może się okazać, że był to problem z oprogramowaniem i sprzętem.

My kontra ich
W wielu firmach odległość między testerami a programistami rosła, ponieważ były to oddzielne działy, a cykl rozwoju był coraz bardziej sformalizowany i ustandaryzowany.
Wraz z pojawieniem się Agile, programiści i testerzy zaczęli bliżej współpracować i zaczęliśmy wzajemnie postrzegać swój punkt widzenia na temat cyklu rozwoju, a może nawet go szanować.
Coś podobnego musi się wydarzyć między programistami a operacjami, ponieważ wraz z dojrzewaniem obu pól i dalszymi formalizacjami i standaryzacją procesów rośnie odległość między tymi działami. Tak więc jednym z problemów tradycyjnego modelu jest to, że wydaje się, że „my” kontra „oni” zarówno dla programistów, jak i operacji. Obie nie do końca rozumieją trudność obowiązków drugiej osoby.

Oczekiwania / zalety
W DevOps obie specjalizacje nauczą się niektórych umiejętności tradycyjnie wykonywanych przez drugą. Nikt nie spodziewa się, że administrator systemu zostanie inżynierem oprogramowania, a programista inżynierem sieci, ale oboje powinni wziąć na siebie część obowiązków drugiej osoby. Oznacza to, że gdy naprawdę potrzebujesz dodatkowych rąk, są one dostępne.

Są też pewne pozytywne strony dla programistów: teraz masz większą kontrolę nad swoimi środowiskami testowymi, łatwiej będzie Ci wdrożyć oprogramowanie dla użytkowników i mieć więcej osób w organizacji, z którymi możesz dzielić się swoją miłością do rzemiosła.

Pisanie kodu jakości to po prostu za mało. Jesteś częścią problemu lub częścią rozwiązania.

Dla wielu programistów piszesz oprogramowanie, za które płaci pewien użytkownik końcowy. Pisanie kodu jakości jest dobrą rzeczą, ale klienci / menedżerowie zakładają, że zawsze powinieneś robić szybko. To tak, jakby stolarz dokładnie wycinał deski, ale czy rzeczywiście budujesz coś, za co ktoś chce zapłacić?

DevOps daje programistom większą kontrolę i mam nadzieję, że zmusza ich kod do zgodności z wynikiem końcowym. Kto najlepiej nadaje się do automatyzacji procesu operacyjnego? Zadowolenie użytkownika końcowego jest głównym miernikiem. Nie tylko musisz pisać kod jakości, ale musi on zadowolić klienta. Przepraszamy, ale nikt nie wraca do używania wierszy kodu. Nie obchodzi ich, czy zbudowałeś własną strukturę ORM od zera, tak jak przeciętny nabywca domu nie dba o to, czy ściąłeś drzewo i stworzyłeś własne deski. Czy ktoś chce powtórzyć wszystkie swoje pliki konfiguracyjne, ponieważ „uaktualnienie” przywraca je do wartości domyślnych?

Chcesz pochwalić się swoimi programistami? Twórz coś, co ludzie chcą kupić, a to obejmuje całe doświadczenie użytkownika. Wspaniale jest, że piszesz kod jakości, ale niestety możesz nie otrzymać premii, jeśli nie zostanie on zwolniony dla satysfakcjonującego klienta. Nie wahaj się obwiniać za kontrolę jakości, ale Twoja firma wciąż nie ma wystarczających środków, aby zapłacić więcej.

Jest to coś, co szło w parze z Agile & Scrum. Nie ma już jasno określonych ról na stanowiskach - każdy jest „programistą”.

I to nie tylko operacje. Programiści często muszą zajmować się analizami biznesowymi, testowaniem, administrowaniem bazami danych i budowaniem menedżerów - lista jest długa.

W centrum problemu leżało coś, co można nazwać odejściem . Wraz ze wzrostem liczby różnych ról zaangażowanych w projekt, tym więcej było spotkań, nieporozumień i starć o zasoby. Szybkie uzyskanie oprogramowania przed użytkownikami jest grą końcową i wszystko, co może przeszkodzić, nieco odeszło.

To nie jest całkiem zła rzecz. Twój przeciętny programista rozwija swoje umiejętności, chociaż dżem staje się teraz bardzo cienki. Dowodzi również argumentów między programistami i administratorami serwerów, którzy określają, gdzie leżą problemy, gdy wdrożenia przebiegają jak gruszka. Deweloperzy często chcą wypychać rozwiązania za pomocą najnowocześniejszych technologii, a administratorzy serwerów często nie mają pojęcia, co to oznacza z POV administratora, dopóki nie zostaną zaprezentowani z zestawem instalacyjnym.

Jaśniejsze i bardziej przyszłościowe firmy w końcu zaczynają zdawać sobie sprawę, że ludzie w kształcie litery T to dobra rzecz. Istnieje jednak różnica między myśleniem, że są dobrą rzeczą a oczekiwaniem, że tak się stanie w magiczny sposób w miejscu, w którym wcześniej przyjęto tradycyjną kulturę.

Jestem pewien, że istnieje więcej niż kilka dobrych powodów deweloperom także zarządzania operacjami i kontroli jakości (czasami). Oto trzy z nich:

• Zainteresowanie
  Niektórzy programiści naprawdę chcą pracować ze wszystkimi aspektami produktu. Jeśli są w tym dobrzy i wypełniają pustkę w zespole lub zapewniają dobre wsparcie istniejącym członkom zespołu w innych rolach, może nie być żadnego powodu, aby ich powstrzymać.
• Koszt
  Duże firmy mogą sobie pozwolić na wyspecjalizowanych pracowników. Małe firmy czasami nie mogą. Niektóre z tych miejsc mogą zatrudnić 1, a może 2 lub 3 programistów, którzy muszą mieć dostęp do gotowych rozwiązań.
• Rozmiar projektu
  Nie każdy projekt jest projektem wieloosobowym. Jeśli budujesz „małą” aplikację, może to być przesada, aby więcej niż jedna osoba pracowała nad nią do końca. Co więcej, małe projekty, w których wiele osób pełniących określone role są przerażające . Nikt nie ma dość pracy do wykonania - nawet jeśli możesz sobie pozwolić na trzymanie ich dookoła i kiwanie kciukami przez 6 miesięcy, dobre nie zostaną. Jeśli się nie nudzą, przestraszą się, albo uświadomisz sobie, że sporo płacisz za nic. Tak czy inaczej, twoi dobrzy pracownicy będą odchodzić i każą wszystkim trzymać się z daleka od ciebie.

... I inne powody, jestem tego pewien.

„Konieczność martwienia się infrastrukturą, wydaniami, kontrolą jakości i związaną z tym ceremonią jest ogromną rozrywką od pisania dobrego kodu”

Wydaje mi się, że DevOps mówi, że martwiąc się infrastrukturą i wydaniami oraz QA, pisze dobry kod.

W poprzednich rolach działających w kulturach innych niż DevOps miałem wiele problemów, którym zapewne mogłaby zapobiec kultura DevOps; problemy z wydajnością związane z kodem opracowanym na niereprezentatywnych platformach, problemy z kodowaniem znaków, w których programiści nie znają kodowania znaków używanego przez klienta, instrukcje wdrażania, które zostały ręcznie zakodowane i niewystarczające dla zespołu operacyjnego bez pewnego odgadnięcia -praca.

Teraz możesz argumentować, że zwiększona specjalizacja zarówno po stronie deweloperów, jak i operatorów pozwala nam przezwyciężyć niektóre z nich, ale wciąż wiele problemów można rozwiązać tylko poprzez dzielenie się wiedzą i pracą między naszymi zespołami.

DevOps nie musi oznaczać „Dev teraz robi także operacje”. Termin pierwotnie oznaczał „ Ludzie Dev i Ops ściśle ze sobą współpracują w jednym zespole”. Oznacza to, że ludzie Ops muszą stać się bardziej podobni do Devów, ponieważ automatyzacja wymaga pewnego rodzaju programowania, a stary ręczny sposób go nie ogranicza (zobacz inne odpowiedzi na bardziej szczegółowe opracowanie na ten temat).

Z Wikipedii :

DevOps (obcięty związek rozwoju i operacji) to kultura, ruch lub praktyka, która kładzie nacisk na współpracę i komunikację zarówno twórców oprogramowania, jak i innych specjalistów w dziedzinie technologii informatycznych (IT), jednocześnie automatyzując proces dostarczania oprogramowania i zmiany infrastruktury

Tak więc, moim zdaniem, jeśli jako deweloper masz te same stare obowiązki, a dodatkowo teraz obowiązki operacyjne, wydaje się to błędne obliczenie po stronie zarządzania. Automatyzując rzeczy, jest całkiem możliwe, że będziesz potrzebować mniej ludzi Ops, a więc faktycznie zaoszczędzisz koszty. Ale DevOps z pewnością nie oznacza „Pozbądźmy się wszystkich ludzi Ops i pozwól Devs dodatkowej pracy”.

Jak to często bywa z modnymi powiedzonkami, zdarza się Semantyczna dyfuzja i nagle ludzie myślą: „Pozwólmy Devs również robić Ops, i myślę, że możemy zaoszczędzić pieniądze ...”