DevOps — DevOps

DevOps to zestaw praktyk, który łączy tworzenie oprogramowania ( Dev ) i operacje IT ( Ops ). Ma na celu skrócenie cyklu życia systemów i zapewnienie ciągłej dostawy przy zachowaniu wysokiej jakości oprogramowania . DevOps jest komplementarny z rozwojem oprogramowania Agile ; kilka aspektów DevOps pochodziło z metodologii Agile.

Definicja

Poza tym, że jest to wielofunkcyjne połączenie terminów i pojęć „rozwoju” i „operacji”, naukowcy i praktycy nie opracowali uniwersalnej definicji terminu „DevOps”. Najczęściej DevOps charakteryzuje się kluczowymi zasadami: współwłasnością, automatyzacją przepływu pracy i szybką informacją zwrotną.

Z perspektywy akademickiej Len Bass , Ingo Weber i Liming Zhu — trzej badacze informatyki z CSIRO i Software Engineering Institute — zasugerowali zdefiniowanie DevOps jako „zestawu praktyk mających na celu skrócenie czasu między wprowadzeniem zmiany w systemie a wprowadzenie zmiany do normalnej produkcji, przy jednoczesnym zapewnieniu wysokiej jakości”.

Termin ten jest jednak używany w wielu kontekstach. Najbardziej udany DevOps to połączenie określonych praktyk, zmiany kultury i narzędzi.

Historia

W 1993 roku Konsorcjum Architektury Sieci Informacji Telekomunikacyjnej ( TINA-C ) zdefiniowało model cyklu życia usług, który łączył tworzenie oprogramowania z operacjami usług (telekomunikacyjnych). Niektórzy twierdzą, że DevOps pojawiło się po części jako reakcja na „odgórne” nakazowe podejście ITIL w latach 90. XX wieku. DevOps, jako podejście „oddolne”, zyskało popularność i przetrwało, ponieważ zostało stworzone przez inżynierów oprogramowania dla inżynierów oprogramowania i jest elastyczną praktyką, a nie sztywnymi ramami.

W 2014 roku Lisa Crispin i Janet Gregory napisały książkę More Agile Testing, zawierającą rozdział poświęcony testowaniu i DevOps.

Łańcuchy narzędziowe

Ponieważ DevOps ma być wielofunkcyjnym trybem pracy, ci, którzy praktykują tę metodologię, używają różnych zestawów narzędzi – określanych jako „ toolchains ” – zamiast jednego. Oczekuje się, że te łańcuchy narzędzi będą pasować do jednej lub więcej z następujących kategorii, odzwierciedlając kluczowe aspekty procesu rozwoju i dostarczania.

  1. Kodowanie – tworzenie i przegląd kodu, narzędzia do zarządzania kodem źródłowym , scalanie kodu.
  2. Budynek – narzędzia do ciągłej integracji , stan kompilacji.
  3. Testowanie – narzędzia do ciągłego testowania , które zapewniają szybką i terminową informację zwrotną na temat ryzyka biznesowego.
  4. Pakowanie — repozytorium artefaktów , przygotowywanie aplikacji przed wdrożeniem.
  5. Wydanie – zarządzanie zmianą, zatwierdzanie wydań, automatyzacja wydań .
  6. Konfiguracja – konfiguracja i zarządzanie infrastrukturą , infrastruktura jako narzędzia kodu .
  7. Monitoring – monitorowanie wydajności aplikacji , doświadczenie użytkownika końcowego.

Związek z innymi podejściami

Wiele pomysłów fundamentalnych dla praktyk DevOps jest inspirowanych lub odzwierciedla inne dobrze znane praktyki, takie jak cykl Lean i Deming's Plan-Do-Check-Act , aż po The Toyota Way i podejście Agile polegające na rozkładaniu komponentów i wielkości partii.

Zręczny

Motywacje do tego, co stało się nowoczesnym DevOps i kilkoma standardowymi praktykami DevOps, takimi jak zautomatyzowane kompilowanie i testowanie, ciągła integracja i ciągłe dostarczanie, wywodzą się ze świata Agile, który (nieformalnie) datuje się na lata 90., a formalnie na 2001 rok. metody takie jak Extreme Programming nie mogą „zadowolić klienta poprzez wczesne i ciągłe dostarczanie wartościowego oprogramowania”, chyba że przejmą obowiązki operacyjne/infrastrukturalne związane z ich aplikacjami, z których wiele zautomatyzowali. Ponieważ Scrum pojawił się jako dominujący framework Agile na początku 2000 roku i pominął praktyki inżynierskie, które były częścią wielu zespołów Agile, ruch na rzecz automatyzacji operacji / funkcji infrastruktury oderwał się od Agile i rozszerzył na to, co stało się nowoczesnym DevOps. Obecnie DevOps koncentruje się na wdrażaniu opracowanego oprogramowania, niezależnie od tego, czy jest ono tworzone za pomocą Agile, czy innych metodologii.

ArchOps

ArchOps przedstawia rozszerzenie dla praktyki DevOps, zaczynając od artefaktów architektury oprogramowania , zamiast kodu źródłowego, do wdrażania operacji. ArchOps stwierdza, że ​​modele architektoniczne są pierwszorzędnymi jednostkami w rozwoju oprogramowania, wdrażaniu i operacjach.

CI/CD

Automatyzacja jest podstawową zasadą osiągnięcia sukcesu DevOps, a CI/CD jest kluczowym elementem.

CI/CD obejmuje ciągłą integrację (CI) i ciągłe dostarczanie (CD) lub ciągłe wdrażanie (CD). Używane razem te trzy procesy automatyzują kompilację, testowanie i wdrażanie, dzięki czemu zespoły DevOps mogą szybciej i bardziej niezawodnie wysyłać zmiany kodu. Odnosząc się do CI/CD, przywoływany „CD” jest zwykle ciągłym dostarczaniem, a nie ciągłym wdrażaniem. Ciągłe dostarczanie i inne procesy CI/CD koncentrują się na automatyzacji zadań dostarczania oprogramowania , podczas gdy DevOps koncentruje się również na zmianach organizacyjnych, aby wspierać doskonałą współpracę między wieloma zaangażowanymi funkcjami. Obydwa mają wspólne doświadczenie w zwinnych metodach i myśleniu lean , traktując priorytetowo małe i częste zmiany o wartości ukierunkowanej na klienta końcowego. Zapewnia to dwie rzeczy: Oprogramowanie jest zawsze w stanie możliwym do wydania przez cały cykl życia, co sprawia, że ​​dostarczanie oprogramowania jest tańsze i mniej ryzykowne.

Ponadto ulepszona współpraca i komunikacja między zespołami i wewnątrz zespołów pomaga skrócić czas wprowadzania produktów na rynek przy zmniejszonym ryzyku.

Operacje danych

Zastosowanie ciągłego dostarczania i DevOps do analizy danych zostało nazwane DataOps. DataOps dąży do integracji inżynierii danych, integracji danych, jakości danych, bezpieczeństwa danych i prywatności danych z operacjami. Stosuje zasady DevOps, Agile Development i statystycznej kontroli procesu , stosowane w lean manufacturing , aby poprawić czas cyklu wydobywania wartości z analizy danych.

Inżynieria niezawodności witryny

W 2003 r. firma Google opracowała inżynierię niezawodności witryny (SRE), metodę ciągłego wprowadzania nowych funkcji do wielkoskalowych systemów o wysokiej dostępności przy jednoczesnym zachowaniu wysokiej jakości doświadczeń użytkownika końcowego. Chociaż SRE wyprzedza rozwój DevOps, są one ogólnie postrzegane jako powiązane ze sobą.

DevSecOps, zmiana bezpieczeństwa w lewo

DevSecOps to rozszerzenie DevOps, aby umożliwić zintegrowanie praktyk bezpieczeństwa z podejściem DevOps. Tradycyjny model scentralizowanego zespołu ds. bezpieczeństwa musi przyjąć model sfederowany, umożliwiający każdemu zespołowi dostarczającemu uwzględnienie prawidłowych kontroli bezpieczeństwa w swoich praktykach DevOps. Przesunięcie w lewo bezpieczeństwa to podejście do bezpieczeństwa oprogramowania, w którym praktyki bezpieczeństwa i testy są przeprowadzane na wcześniejszym etapie cyklu życia oprogramowania.

BizOps

BizOps kontrastuje z DevOps ze względu na bardziej zintegrowane podejście. Podczas gdy DevOps jest bardziej skoncentrowany na rozwoju IT i oprogramowania, BizOps integruje technologię z codziennymi decyzjami organizacyjnymi i operacjami biznesowymi.

Zmiana kulturowa

Inicjatywy DevOps mogą powodować zmiany kulturowe w firmach, zmieniając sposób, w jaki operacje , programiści i testerzy współpracują ze sobą podczas procesów tworzenia i dostarczania. Zapewnienie spójnej pracy tych grup jest kluczowym wyzwaniem podczas wdrażania metodyki DevOps w przedsiębiorstwie. DevOps dotyczy zarówno kultury, jak i łańcucha narzędzi.

Budowanie kultury DevOps

Kultura organizacyjna jest silnym predyktorem wydajności IT i organizacji. Praktyki kulturowe, takie jak przepływ informacji, współpraca, wspólne obowiązki, uczenie się na błędach i nowe pomysły, mają kluczowe znaczenie dla DevOps. Budowanie zespołu i inne działania angażujące pracowników są często wykorzystywane do tworzenia środowiska, które sprzyja tej komunikacji i zmianie kulturowej w organizacji. DevOps jako podejście usługowe pozwala deweloperom i zespołom operacyjnym przejąć większą kontrolę nad swoimi aplikacjami i infrastrukturą bez ograniczania szybkości. Przenosi również ciężar posiadania problemu na zespół programistów, czyniąc go znacznie bardziej ostrożnym w swoim kroku.

Raport o stanie DevOps z 2015 r. wykazał, że siedem najważniejszych miar o najsilniejszej korelacji z kulturą organizacyjną to:

  1. Inwestycja organizacyjna
  2. Doświadczenie i skuteczność liderów zespołów
  3. Ciągła dostawa
  4. Zdolność różnych dyscyplin (rozwój, operacje i infosec) do osiągania wyników typu win-win
  5. Wydajność organizacyjna
  6. Ból podczas wdrażania
  7. Praktyki szczupłego zarządzania

Rozlokowanie

Firmy z bardzo częstymi wydaniami mogą wymagać wiedzy na temat DevOps. Na przykład firma, która obsługuje witrynę Flickr do hostingu obrazów, opracowała podejście DevOps do obsługi dziesięciu wdrożeń dziennie. Codzienne cykle wdrażania byłyby znacznie wyższe w organizacjach produkujących aplikacje wielozadaniowe lub wielofunkcyjne. Codzienne wdrażanie jest określane jako ciągłe wdrażanie

Wymagania o znaczeniu architektonicznym

Aby skutecznie ćwiczyć DevOps, aplikacje muszą spełniać zestaw wymagań architektonicznych (ASR), takich jak: możliwość wdrażania, modyfikowalność, testowalność i możliwość monitorowania.

Mikroserwisy

Chociaż w zasadzie możliwe jest praktykowanie DevOps w dowolnym stylu architektonicznym, styl architektoniczny mikrousług staje się standardem w budowaniu systemów stale wdrażanych. Usługa o niewielkich rozmiarach pozwala na wyłonienie architektury indywidualnej usługi poprzez ciągłą refaktoryzację.

Automatyzacja DevOps

Obsługuje również spójność, niezawodność i wydajność w organizacji i jest zwykle włączany przez współużytkowane repozytorium kodu lub kontrolę wersji. Badacz DevOps, Ravi Teja Yarlagadda, stawia hipotezę: „Dzięki DevOps zakłada się, że wszystkie funkcje mogą być wykonywane, kontrolowane i zarządzane w centralnym miejscu za pomocą prostego kodu”.

Automatyzacja z kontrolą wersji

Wiele organizacji używa kontroli wersji do obsługi technologii automatyzacji DevOps, takich jak maszyny wirtualne , konteneryzacja (lub wirtualizacja na poziomie systemu operacyjnego ) i CI/CD . Artykuł DevOps: rozwój łańcucha narzędzi w domenie bankowej zauważa, że ​​w przypadku zespołów programistów pracujących nad tym samym projektem „Wszyscy programiści muszą wprowadzać zmiany w tej samej bazie kodu, a czasem edytować nawet te same pliki. być systemem, który pomaga inżynierom unikać konfliktów i zachowywać historię bazy kodu”, z systemem kontroli wersji Git i platformą GitHub przywołaną jako przykłady.

Przyjęcie

Praktyki i adopcja DevOps

Praktyki DevOps i ich zależności obejmują sieć zależności, która łączy potencjalne korzyści z uporządkowanym łańcuchem praktyk. Korzystając z tej sieci organizacje mogą wybrać drogę, która umożliwia realizację ich celów.

Przyjęcie DevOps jest napędzane przez wiele czynników, w tym:

  1. Wykorzystanie zwinnych i innych procesów i metod rozwojowych ;
  2. Zapotrzebowanie na zwiększone tempo wydań produkcyjnych – ze strony interesariuszy aplikacji i jednostek biznesowych ;
  3. Szeroka dostępność infrastruktury zwirtualizowanej i chmurowej – od dostawców wewnętrznych i zewnętrznych;
  4. Zwiększone wykorzystanie narzędzi do automatyzacji centrum danych i zarządzania konfiguracją ;
  5. Większy nacisk na automatyzację testów i metody ciągłej integracji ;
  6. Masa krytyczna publicznie dostępnych najlepszych praktyk.

Zobacz też

Uwagi

Bibliografia

Dalsza lektura

  • Davis, Jennifer; Daniels, Ryn (30 maja 2016). Efektywne DevOps : budowanie kultury współpracy, koligacji i narzędzi na dużą skalę . Sewastopol, Kalifornia: O'Reilly. Numer ISBN 9781491926437. OCLC  951434424 .
  • Kim, Gene; Debois, Patrick; Willisa, Jana; Pokorny, Jez; Allspaw, John (7 października 2015). Podręcznik DevOps: jak stworzyć światowej klasy zwinność, niezawodność i bezpieczeństwo w organizacjach technologicznych (wyd. pierwsze). Portland, OR. Numer ISBN 9781942788003. OCLC  907166314 .
  • Forsgren, Nicole; Pokorny, Jez; Kim, Gene (27 marca 2018). Przyspieszenie: Nauka o Lean Software i DevOps: Budowanie i skalowanie organizacji wysokowydajnych technologii (wyd. pierwsze). Rewolucja IT Prasa. Numer ISBN 9781942788331.