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ć:
- 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.
- Ś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.
- 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.
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.
