Co zawiera „DevOps Transformation”?

Niektóre firmy konsultingowe promują usługę o nazwie „DevOps Transformation”. Wiele dużych firm mówi na ten temat na konferencjach i spotkaniach na całym świecie.

Co pociąga za sobą taka „DevOps Transformation”? Jak to wygląda w sensie praktycznym, zarówno dla udanych transformacji, jak i nieudanych.

Muszę odpowiedzieć na to pytanie w kontekście tego, czym jest DevOps, a dokładniej w ramach transformacji DevOps, w których uczestniczyłem, DevOps jest własnością pełnego cyklu rozwoju oprogramowania. Wszystkie praktyki przedstawione na wykresie są ważną częścią DevOps i umożliwiają zarówno myślenie systemowe, jak i wzmacnianie pętli sprzężenia zwrotnego .

Jednak kluczowym czynnikiem odróżniającym CI / CD i DevOps jest faktyczne działanie oprogramowania w środowisku produkcyjnym, w którym może on dostarczać wartość swoim klientom i obsługiwanej firmie.

Jako konsultant biorący udział w transformacji DevOps lub prowadzący ją, mam przed sobą następujące aspekty:

• Kultura : Jak Dave słusznie zwrócił uwagę na kulturę ciągłego eksperymentowania i uczenia się jest kluczem do sukcesu każdej transformacji. Z perspektywy DevOps sprowadza się to do tego, w jaki sposób możemy stworzyć kulturę, która wspiera wybrany model DevOps, tym modelem może być „You Build It, You Run It” lub może to być bardziej zgodne z inżynierią niezawodności witryny Google praktyką .

• Model operacyjny : jest to część propozycji biznesowej, która określa, w jaki sposób organizacja będzie dostarczać wartość, ogólnie poprzez artykułowanie użytych osób, procesów i narzędzi na wysokim poziomie. Bez modelu operacyjnego nie masz planu, w jaki sposób organizacja przyjmuje praktyki zdefiniowane przez kulturę, co z kolei prowadzi do braku jasności i rozbieżnych zachowań.

• A-Level Aircover : Często naszym zadaniem jako konsultantów pracujących w ramach programów transformacyjnych jest dokonanie radykalnych zmian w sposobie działania firmy. Będziesz denerwować ludzi, a niektórym ludziom nie spodobają się zmiany - ważne jest, abyś miał „osłonę powietrzną” z góry, aby zmieniać rzeczy i iść do przodu.

Po osiągnięciu wysokiego poziomu ważne jest znalezienie czegoś, co można realistycznie dostarczyć:

1. Zacznij jak najmniej, najlepiej, gdy masz ludzi, którzy rozumieją kulturę, szkic modelu operacyjnego i wpis od kierownictwa tworzą „Minimalny możliwy do zrealizowania projekt”, nie próbuj zagotować oceanu, wprowadzając DevOps do tysięcy odbiorców. Ustaw osiągalny cel:
   • Zautomatyzuj tworzenie infrastruktury z produktu X.
   • Zautomatyzuj dostarczanie produktu X na platformę Azure we wszystkich środowiskach.
   • Wsparcie zwrotne od outsourcera Y do zespołu programistów w Londynie.
   • Utwórz zestaw testów wokół naszej najbardziej ryzykownej funkcji i uruchom je w ciągłej integracji.
2. Świetnie, że masz już za sobą pewne sukcesy, teraz nadszedł czas, aby zacząć dzielić to na kolejne zespoły, dodać kolejne zespoły do ​​miksu i uruchomić je. Nie obawiaj się początkowo oferować „wsparcie białych rękawiczek”, aby pomóc im w przejściu; będą potrzebować dużo trzymania się za ręce w nadchodzących tygodniach i miesiącach.
3. Teraz masz kilku wczesnych użytkowników adoptujących nowy sposób pracy; masz masę krytyczną, czas zacząć ewangelizować pracę, którą wykonujesz z szerszą publicznością:
   • Regularnie pokaż i powiedz sesje , poproś pierwszych użytkowników, aby pokazali, jak skutecznie odnieśli sukces.
   • Oferuj sesje drop-in aby umożliwić innym częściom organizacji zbadanie, w jaki sposób mogą dołączyć do zespołu.
   • Umożliwić tworzenie wspólnot praktyk skupiających się na określonych dyscyplinach: ciągłe wdrażanie, automatyczne testowanie, komunikacja biznesowa, zarządzanie ryzykiem, monitorowanie i alarmowanie itp.

4. Zatrzymaj kurs i zakończ transformację, dołączając do reszty organizacji. Zrozum związek między cyklem Hype firmy Gartner a cyklem życia adopcji . Przygotuj się, aby Program Transformacji wpadł w „Koryto rozczarowania”, pozostań na polu i miej cel końcowy na widoku.

   

Aby głębiej zbadać ostatni punkt, przeczytaj artykuł Geoffrey A. Moore Crossing the Chasm . Mógłbym dosłownie napisać książkę o tym, jak przeprowadzić transformację DevOps, jednak zanim ją skończę, prawdopodobnie nie będzie już dla mnie pracy nad transformacją DevOps.

DevOps dzieli się na trzy główne wymiary:

Kultura Kultura
DevOps kładzie nacisk na wysoki poziom zaufania, współpracy i komunikacji między wszystkimi interesariuszami, zwłaszcza deweloperami, operacjami i bezpieczeństwem. Naturalne napięcie i rywalizacja między tymi grupami powodują tarcie, a często dysfunkcję. DevOps polega (prawdopodobnie) przede wszystkim na wyrównaniu wysiłków między tymi zespołami.

Procesy
programowania DevOps są ściśle powiązane z procesami Agile. Zachęca się Ops do stosowania praktyk podobnych do zwinnych, aby lepiej dostosować się do wysiłków deweloperów. Procesy dostosowane do DevOps są zaprojektowane tak, aby obsługiwać pętle o wysokiej prędkości i szybkim sprzężeniu zwrotnym w całym cyklu rozwojowym / dostawczym. Ciągła integracja, ciągłe dostarczanie i ciągłe doskonalenie (kaizen) są głównymi obszarami procesu DevOps.

Technologia
DevOps nie jest narzędziem, ale jest obsługiwane przez narzędzia. Istnieją całe rodziny narzędzi obsługujących szereg obszarów, w tym ciągłą integrację, kontrolę źródła i zarządzanie cyklem życia aplikacji.

„Transformacja DevOps” musi dotyczyć elementów wszystkich trzech, ale niekoniecznie wszystkich jednakowo w tym samym czasie. Istnieje naturalny postęp i „ścieżka krytyczna” transformacji. Można argumentować, na przykład, DevOps zależy od jakiejś formy zwinnej praktyki, przynajmniej w zespole / zespołach programistów. Problemy z kulturą mogą wymagać rozwiązania przed dokonaniem inwestycji w oprzyrządowanie.

Odniesienia:
Kultura: https://www.andykelk.net/devops/using-the-westrum-typology-to-measure-culture
Technologia: https://xebialabs.com/periodic-table-of-devops-tools/