Zrobiłem / stworzyłem wiele prezentacji związanych z SCM, a teraz próbuję „uaktualnić” do następcy DevOps.

To, co zawsze staram się robić w moich prezentacjach, to wymyślić slajd wprowadzający, który w jakiś sposób zawiera przesłanie, które chcę przekazać (i które następnie rozwijam w dalszej części mojej prezentacji). Robiąc to, staram się odpowiedzieć na moje pytanie w stylu „Jakie byłyby od 1 do 3 wyrażeń, których chciałbym użyć, gdybym otrzymał od 10 do 20 sekund (tylko!), Aby wyjaśnić to komuś nowemu? * „.

Myślałem, że wiem, co właściwie oznacza DevOps i o co chodzi. Ale widziałem dziwne zastosowania / konteksty DevOps (nawet na DevOps.SE ...). Zastanawiam się, czy może to, co moim zdaniem jest DevOps, jest całkowicie błędne.

Więc co ogólnie uznaje się za definicję DevOps?

DevOps w pigułce

Z Wikipedii :

Devops (a obcięte związek z „ oprogramowania DEV elopment ” i „ technologia informacyjna OP chłodnika S ”) to termin używany w odniesieniu do zbioru praktyk, które podkreślają współpracę i komunikację zarówno twórców oprogramowania i technologii informatycznych (IT) specjalistów podczas automatyzowania proces dostarczania oprogramowania i zmiany infrastruktury.

Ma na celu stworzenie kultury i środowiska, w którym tworzenie , testowanie i wydawanie oprogramowania może się odbywać szybko, często i bardziej niezawodnie.

Z przeglądu :

Schemat Venna przedstawiający DevOps jako skrzyżowanie rozwoju (inżynierii oprogramowania), operacji i zapewnienia jakości (QA)

Chociaż nie ma jednego „narzędzia” dla DevOps, a raczej zestaw narzędzi, znany również jako łańcuch narzędzi DevOps :

Ilustracja przedstawiająca etapy w zestawie narzędzi DevOps

Ilustracje DevOps

Poniżej znajduje się kilka cytatów z niektórych pytań na DevOps.SE , które wydają się w jakiś sposób pasować / potwierdzać część powyższego opisu DevOps:

• Od „ Jaka jest różnica między SRE a DevOps? „:

  ... DevOps polega na utrzymywaniu kodu ...

• Od ( odpowiedź na) „ Jak zatrudnić dobrego DevOpsa, pasującego do mojej firmy? „:

  ... Powszechnie uważa się, że „DevOps” jest rolą w firmie. Słowo to oznacza jedynie zmianę organizacyjną w firmach programistycznych ...

• Od „ Czy moja organizacja musi przyjąć Agile Soft. Dev. przed przyjęciem DevOps? „:

  ... wciąż istnieją organizacje, które nie praktykują Agile w tworzeniu oprogramowania, które mogą być zainteresowane przyjęciem DevOps ...

DevOps NIE jest rolą

Poniżej znajduje się kilka cytatów z niektórych pytań na DevOps.SE , które wydają się ilustrować, że DevOps NIE jest rolą:

• Od ( odpowiedź na) „ Jaka jest różnica między Sysadmin a DevOps Engineer? „:

  ... DevOps nie jest rolą (w takim przypadku jest bardziej modnym hasłem niż prawdziwą rolą).

• Od ( odpowiedź na) „ Jak zatrudnić dobrego DevOpsa, pasującego do mojej firmy? „:

  ... Powszechnie uważa się, że „DevOps” jest rolą w firmie. Słowo to oznacza jedynie zmianę organizacyjną w firmach programistycznych ...

Od prawie pięciu lat praktykuję i doradzam w DevOps jako konsultant z różnymi klientami, zanim do mojej obecnej pozycji zajmowałem stanowiska w tworzeniu oprogramowania, operacjach sieciowych i administracji systemami. Z mojego osobistego doświadczenia DevOps występuje w wielu smakach.

Wzorce organizacyjne

DevOps Antipatterns:

• NoOps i NoDevs - nie ściśle DevOps w najściślejszym sensie, jednak zespoły te zarówno budują, jak i obsługują oprogramowanie, nie dzieląc linii między Programowaniem a Operacjami. Wyzwania związane z tymi zespołami sprowadzają się do dojrzałości, zespoły programistów mogą być ekspertami w dziedzinie tworzenia oprogramowania, ale nowymi operatorami i odwrotnie.

• DevOps Bridge - tutaj jeden lub więcej zespołów ponosi odpowiedzialność za przejęcie pracy od zespołów programistycznych i „ wyprodukowanie ” go, aby działał . Wyzwanie sprowadza się do tego, że obecnie występują dwa hand-offy, tj. Rozwój → DevOps i DevOps → Operacje.

• Zespół DevOps - może to prawdopodobnie działać, jeśli zespół jest odpowiedzialny za budowanie narzędzi wspierających Model operacyjny z włączonym DevOps, jednak prawdopodobnie powinien być nazywany „zespołem narzędzi” lub „zespołem platform”.

Wzory DevOps:

• Wbudowane DevOps - częściej określane jako Inżynieria Platformy, w ramach której w zespole jest ktoś, kto jest odpowiedzialny, ale nie jest odpowiedzialny za zapewnienie automatyzacji, narzędzi i infrastruktury do dostarczania i wdrażania rozwiązania, czasami także za obsługę oprogramowania - w mojej opinii , to ten ostatni jest faktycznie reprezentatywny dla DevOps.

• Zinstytucjonalizowane DevOps - gdzie zespół projektowy jest odpowiedzialny zarówno za rozwój, jak i działanie pakietu oprogramowania budującego wspólną własność i pozytywne pętle zwrotne.

Praktyki

Rzeczywista praktyka DevOps opiera się na kilku innych praktykach, a mianowicie:

• Zwinna dostawa
• Ciągła integracja
• Ciągła dostawa
• Ciągłe wdrażanie

Każda z powyższych praktyk opiera się na drugiej, można nie stosować się do niej, oznacza to jednak brak ważnego cyklu informacji zwrotnej, który może wskazywać na „utraconą okazję”. Kluczowym rozróżnieniem pomiędzy stosowaniem innych praktyk a DevOps jest działanie oprogramowania w produkcji .

Trzy sposoby

W The Phoenix Project Gene Kim i jego współautorzy opisują trzy sposoby DevOps :

Systemy myślenia

Pierwszy sposób kładzie nacisk na wydajność całego systemu, w przeciwieństwie do wydajności konkretnego silosu pracy lub działu - może to być tak duży dział (np. Dział rozwoju lub IT) lub tak mały jak indywidualny współpracownik (np. , programista, administrator systemu).

Z mojego doświadczenia wynika, że ​​programiści biorą pod uwagę obawy operacyjne i wymagania niefunkcjonalne osiągają ten cel. To bardzo część kulturowych aspektów DevOps.

Wzmocnienie pętli sprzężenia zwrotnego

Drugi sposób polega na tworzeniu pętli sprzężenia zwrotnego od prawej do lewej. Prawie każda inicjatywa doskonalenia procesu ma na celu skrócenie i wzmocnienie pętli sprzężenia zwrotnego, aby można było ciągle wprowadzać niezbędne poprawki.

Zasadniczo osiągam to poprzez ciągłą integrację / dostarczanie / wdrażanie oraz wspólne monitorowanie i alarmowanie, co bardzo dobrze pasuje do komponentu narzędziowego DevOps.

Kultura ciągłego eksperymentowania i uczenia się

Trzecia droga polega na tworzeniu kultury, która wspiera dwie rzeczy: ciągłe eksperymentowanie, podejmowanie ryzyka i uczenie się na porażce; oraz zrozumienie, że powtarzanie i praktyka są warunkiem opanowania.

To bardzo pasuje do przestrzeni kultury , choć w dużym stopniu zależy od narzędzi i procesu umożliwiającego wzrost kultury.

Słyszałem wiele, wiele różnych definicji DevOps. Zawierają:

• Deweloperzy obsługujący zadania operacyjne
• Jedna osoba wykonuje dwa razy więcej pracy (w tym samym czasie)
• Programiści i zespoły operacyjne współpracują ze sobą
• Operacje działają na rzecz narzędzi programistycznych (w stylu „Web Ops”)
• Tytuł pracy dla kogoś, kto tworzy i utrzymuje narzędzia programistyczne
• Zastosowanie automatyzacji w operacjach
• Wykorzystanie chmur publicznych w operacjach
• Praca, która łączy aspekty działania, rozwoju i zapewnienia jakości
• Praca, która wymaga współpracy zespołów programistów i operacyjnych
• Filozofia przełamywania barier między zespołami
• Traktowanie infrastruktury jako kodu
• Co zyskujesz, gdy byli inżynierowie oprogramowania rozpoczynają działalność
• Zupełnie nic nie znaczące modne hasło

Nie ma publicznego konsensusu co do tego, czym właściwie jest DevOps . Kilka lat temu mieliśmy podobne problemy z „Agile” i to ma pisemną definicję .

Przedstawiając swoje koncepcje nowicjuszowi, skoncentruję się na przedstawieniu tych koncepcji, zamiast na umieszczaniu etykiety, bo inaczej usłyszą sprzeczne definicje i będą mylone. Na przykład, jeśli próbujesz mówić o infrastrukturze jako kodzie , powiedz im, że mówisz o infrastrukturze jako kodzie. Im bardziej konkretny jesteś, tym lepiej, ponieważ nawet przy ustalonych definicjach większość firm koncentruje się bardziej na określonych częściach filozofii.

Definicja, której zawsze używam w tej sytuacji, jest następująca:

„Kultura tworzenia oprogramowania, która kładzie nacisk na komunikację i współpracę między zespołami zajmującymi się tworzeniem oprogramowania i operacjami, jednocześnie automatyzując proces dostarczania oprogramowania i zmiany infrastruktury. Celem DevOps jest uczynienie procesu tworzenia, testowania i wdrażania oprogramowania tak częstym, szybkim i jak to możliwe. ”

Jednak wraz z definicją ważne jest, aby rozumieli, DLACZEGO potrzebujemy DevOps. Pamiętaj, aby powiedzieć im, że DevOps szybciej łagodzi defekty oprogramowania, pozwala na lepsze zarządzanie zasobami, mniej błędów ludzkich, lepszą kontrolę wersji, stabilne środowisko operacyjne itp.

W poniższym artykule z badań naukowych, aby dokładnie zbadać to pytanie „Czym jest DevOps”, proponowana pochodna definicja DevOps to:

DevOps jest metodologią programistyczną mającą na celu wypełnienie luki między programowaniem (programistą) a operacjami (operacjami operacyjnymi), kładąc nacisk na komunikację i współpracę, ciągłą integrację, zapewnienie jakości i dostarczanie z automatycznym wdrażaniem z wykorzystaniem zestawu praktyk programistycznych.

[Jabbari i wsp.] „Co to jest DevOps ?: Systematyczne badanie mapowania definicji i praktyk” (2016)

Devops to praktyka opracowywania aplikacji, których domeną biznesową jest działalność. Tam, gdzie większość opracowywania aplikacji koncentruje się na tworzeniu aplikacji finansujących lub zajmujących się opieką zdrowotną, logistyką lub filmami dla kotów, deweloperzy koncentrują się na aplikacjach, które umożliwiają budowanie, wdrażanie, monitorowanie i gromadzenie danych.

Celem nadrzędnym powinno zawsze być umożliwienie decydentom stać decydentów . Wyobraź sobie aplikację mobilną swojego banku. Gdy poprosisz o przeniesienie, dzieje się to po naciśnięciu przycisku. Ty wykonane decyzji, a następnie wziął decyzję. To samo dotyczy twoich operacji. Gdy odpowiednia osoba zdecyduje, że część pracy jest gotowa do wdrożenia na produkcję, powinna być w stanie nacisnąć przycisk i „Właściwe rzeczy się zdarzą”. Podobnie powinni mieć wszystkie niezbędne informacje potrzebne do podejmowania prawidłowych decyzji biznesowych.

Nie chodzi o zapewnienie ludziom biznesu dostępu do serwerów - to mylący cel z implementacją. Chodzi o dostarczenie właściwych pokręteł i dźwigni odpowiednich informacji i właściwych barier ochronnych właściwym osobom, tak aby decydenci byli decydentami.