DevOps – Development and Operations – metoda wytwarzania oprogramowania, która kładzie nacisk na komunikację, współpracę i integrację profesjonalistów z zakresu operacji IT oraz specjalistów ds. rozwoju oprogramowania. Jest odpowiedzią na współzależność rozwoju i operacji IT. Wspiera w organizacji szybkie wytwarzanie usług i produktów software’owych.
ZASTOSOWANIE
Koncepcja DevOps jest najbardziej odpowiednia dla firm, w których częstotliwość kolejnych wydań oprogramowania jest relatywnie duża. Serwis internetowy Flickr rozwinął zdolność DevOps do wspierania wymagań biznesowych na poziomie dziesięciu wdrożeń dziennie. Dzienny cykl wdrożeń (ang. deployment cycle) może być jeszcze większy, na przykład w organizacjach produkujących aplikacje wielofunkcyjne lub o wielu ukierunkowaniach. Nazywa to się ciągłym wdrażaniem (ang. continuous deployment) lub ciągłym wydawaniem (ang. continous delivery) i często kojarzone jest z metodyką lean startup. Temat stał się popularny od roku 2009 – rozwijają się grupy robocze i stowarzyszenia profesjonalistów, powstają liczne blogi.
DevOps pomaga firmie w zarządzaniu wydaniami (ang. release management) przez standaryzowanie środowisk rozwoju. Wydarzenia mogą być śledzone w łatwiejszy sposób, podobnie jak rozwiązywanie kontroli udokumentowanego procesu. Firmy, które mają problemy z automatyzacją wydań lub wdrożeń, posiadają zwykle istniejącą już automatyzację, ale chciałyby zarządzać i prowadzić tę automatyzację w bardziej płynny sposób – bez konieczności wpisywania wszystkiego ręcznie w wiersz polecenia. Idealnie byłoby, gdyby ta automatyzacja mogła być wywoływana przez zasoby nieoperacyjne w określonych środowiskach nieprodukcyjnych. Osoby zajmujące się procesem wytwarzania oprogramowania otrzymują większą kontroli nad środowiskiem przez zrozumienie infrastruktury w sposób skupiony bardziej na aplikacjach. Proste procesy stają się jasno wyrażone, oczywiście proste procesy pod DevOps. Celem jest zautomatyzowanie jak największej liczby różnych procesów operacyjnych.
DevOps zmierza do integracji: dostarczenia produktów, testowania jakości, rozwoju cech oraz wydań związanych z utrzymaniem, aby udoskonalić niezawodność i bezpieczeństwo oraz zapewnić szybszy rozwój i cykl wdrożeń. Wiele z pomysłów (i osób) zaangażowanych w DevOps wywodzi się z obszaru zarządzania systemami przedsiębiorstwa (ang. Enterprise Systems Management) i programowania zwinnego (ang. Agile software development).
CHARAKTERYSTYKA
Termin devops nawiązuje do zespolenia rozwoju (ang. development) i operacji (ang. operations) oraz zapewnienia jakości (ang. quality assurance). Został spopularyzowany przez serię konferencji DevOps Days. Pierwsza konferencja odbyła się w 2009 roku w Belgii, a kolejne w Indiach, Stanach Zjednoczonych, Brazylii, Australii, Niemczech i Szwecji.
W tradycyjnej organizacji departamenty rozwoju, utrzymania (operacji) IT i zapewnienia jakości są rozdzielone. Brak integracji ze wsparciem IT i zapewnieniem jakości obniża skuteczność procesów wytwarzania i wdrażania oprogramowania (wykorzystujących np. zwinne programowanie). Podczas, gdy departamenty ds. rozwoju kierują się zwykle potrzebami użytkownika, dotyczącymi częstego dostarczania nowych elementów, departamenty operacyjne skupiają się bardziej na dostępności, stabilności usług IT i ich efektywności kosztowej. Te dwa sprzeczne cele tworzą lukę pomiędzy rozwojem, a operacjami, która spowalnia dostarczenie IT wartości biznesowej. DevOps promuje zbiór procesów i metod obejmujących myślenie o komunikacji i współpracy między departamentami. Do przyjęcia DevOps doprowadzają czynniki, takie jak:
- stosowanie agile lub innych procesów i metod wytwarzania oprogramowania;
- zapotrzebowanie na dużą liczbę wydań od interesariuszy z jednostek biznesowych lub utrzymania aplikacji;
- upowszechnienie wirtualizacji infrastruktury i dostępności infrastruktury w chmurze (ang. infrastructure as a service, IaaS) zarówno od dostawców wewnętrznych i zewnętrznych;
- duże nasycenie centrum danych narzędziami automatyzacji i zarządzania konfiguracją (ang. configuration management).
DevOps jest często opisywany jako nastawiona na współpracę, bardziej produktywna relacja między zespołami rozwoju i operacji. Ta udoskonalona relacja i współpraca zwiększa skuteczność i obniża ryzyko produkcyjne kojarzone z częstymi zmianami. Rola fachowca z zakresu DevOps ma cechy wspólne z rolą głównego inżyniera (ang. Chief Engineer) z Systemu produkcji Toyoty (ang. Toyota Production System). Takie osoby są odpowiedzialne za sukces projektu, ale nie mają formalnej władzy na innymi zaangażowanymi zespołami, co wymaga wiedzy technicznej w celu przekonania odpowiednich menedżerów o potrzebach. Poprzez formalne wprowadzenie roli głównego inżyniera, zarządzający firmą mogą sprawić, że przekonywanie menedżerów będzie bardziej efektywne.
WPŁYW NA ZARZĄDZANIE WYDANIAMI
W wielu firmach, wydarzenia związane z wydaniami aplikacji to działania o dużym stopniu stresu i ryzyka, angażujące wiele zespołów. W organizacji DevOps, wydania aplikacji wiążą się z mniejszym ryzykiem z następujących powodów:
- Zredukowany poziom zmian – przyjęcie modelu iteracyjnego (ang. iterative model) albo modelu przyrostowego (ang. incremental model), w porównaniu do tradycyjnego modelu kaskadowego (ang. waterfall model), oznacza, że każde wydanie zawiera mniej zmian, ale pojawia się częściej. Tworzy to wyrównaną liczbę progresywnych zmian aplikacji w przeciwieństwie do rzadkich wdrożeń o dużym efekcie wpływu – każde z nich zawiera dużą liczbę zmian.
- Zwiększona koordynacja wydań – skorzystanie z koordynatora ds. wydań (ang. release coordinator) posiadającego silną pozycję i łączącego wiedzę specjalistyczną z kompetencjami komunikacyjnymi; zastosowanie narzędzi współpracy, takich jak arkusze kalkulacyjne, telekonferencje, komunikatory internetowe, portale korporacyjne oraz serwisy internetowe klasy wiki, aby zapewnić dokładne zrozumienie danej zmiany oraz pełna współpraca wszystkich zaangażowanych.
- Automatyzacja – wszechstronna automatyzacja wdrożeń zapewnia powtarzalność zadań wdrożeniowych (ang. deployment tasks) oraz redukuje błędy wdrożeniowe (ang. deployment errors).
KOORDYNATOR WYDAŃ
Koordynator wydań (ang. release coordinator), to stosunkowo nowa rola w organizacji IT, której przypisane są przede wszystkim zadania związanie z koordynacją wdrożeń oprogramowania przedsiębiorstwa do środowisk przedprodukcyjnych. Przyczyny powołania koordynatora wydań obejmują:
- potrzebę wypełniania „luki” DevOps
- zwiększona złożoność infrastruktury – wiele warstw i platform, które tworzą aplikacje internetowe
- wzrost liczby wydań wynikający z przyjęcia modelu iteracyjnego (ang. iterative model) albo modelu przyrostowego (ang. incremental model)
- rozproszone zespoły – globalne wdrożenia, wyoutsorcowany lub hybrydowy rozwój, zespoły odpowiedzialne za testowanie i infrastrukturę.
Pojawienie się roli koordynatora wydań (nazywanego również koordynatorem wdrożeń lub koordynatorem integracji) wynika z zarządzania wydaniem lub inżynieryjnych zespołów wydań. Rola ta jest podobna do pracy kontrolera ruchu lotniczego – dokonuje on koordynacyjnych działań w realnym czasie, przez różne zespoły, aby osiągnąć cel całej grupy (bezpieczne lądowanie i startowanie), używając wspólnych zasobów (przestrzeń powietrzna, korytarz lotniczy, pasy startowe i terminale).
Koordynacja wydań różni się od zarządzania wydaniami, które jest często skupione na planowaniu i raportowaniu zmian w oprogramowaniu, aby kontrolować wydanie do produkcji określonych zmian aplikacji. Inżynieria wydania zajmuje się z systematyczną i techniczną pracą związaną z budowaniem i wdrażaniem kodu do środowisk. Natomiast ITIL-owe zarządzanie zmianą operuje na poziomie infrastruktury i zajmuje się śledzeniem wszystkich rodzajów zmian w środowisku przedsiębiorstwa IT – łącznie ze zmianami aplikacji i infrastruktury.
