DevOps ang. Development and Operations

DevOps
Metoda
Inżynieria oprogramowania
Logo DevOps Days
Właścicielbrak
Rozpowszechnianiegrupy robocze,

stowarzyszenia profesjonalistów,

blogi
Powstanie2009 r.
Aktualna wersjaspontaniczny rozwój
Certyfikacjabrak
SpołecznośćDevOps Days

DevOps.Com
Ilustracja koncepcji



DevOps – 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.[1] Jest odpowiedzią na współzależność rozwoju i operacji IT. Wspiera w organizacji szybkie wytwarzanie usług i produktów software'owych.[2][3][4][5][6]

Spis treści

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.[7] 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)[8] lub ciągłym wydawaniem (ang. continous delivery)[9] i często kojarzone jest z metodyką lean startup[10]. Temat stał się popularny od roku 2009 - rozwijają się grupy robocze i stowarzyszenia profesjonalistów, powstają liczne blogi.[11][12]

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).[13]

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[14], a kolejne w Indiach, Stanach Zjednoczonych, Brazylii, Australii, Niemczech i Szwecji.[15]



Rys.1. DevOps jako obszar wspólny rozwoju, operacji i zapewniania jakości


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.[16] Do przyjęcia DevOps doprowadzają czynniki, takie jak:
  1. stosowanie agile lub innych procesów i metod wytwarzania oprogramowania;
  2. zapotrzebowanie na dużą liczbę wydań od interesariuszy z jednostek biznesowych lub utrzymania aplikacji;
  3. upowszechnienie wirtualizacji infrastruktury[17] i dostępności infrastruktury w chmurze (ang. infrastructure as a service, IaaS) zarówno od dostawców wewnętrznych i zewnętrznych;
  4. duże nasycenie centrum danych narzędziami automatyzacji[18] 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).[19] 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).


Poniższy rysunek pokazuje różnice między zdarzeniami o dużej częstotliwości w przypadku metod agile oraz rzadkimi wydaniami w przypadku metod tradycyjnych. W przypadku częstych zdarzeń, często mierzonych w dniach lub tygodniach, wysiłek jest bardziej równomierny a ryzyko za każdego wydania relatywnie małe. W przypadku rzadkich, często mierzonych w kwartałach lub latach, dużych wydań występują szczyty wysiłku i są one związane z bardzo dużym wysiłkiem



Rys.2. Różnice wielkości zmian w funkcji częstotliwości wydań


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.

Zobacz też

Linki zewnętrzne

Bibliografia

  • Gene Kim: Top 11 Things You Need to Know About DevOps, IT Revolution Press
  • Gene Kim, Kevin Behr, George Spafford: The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win,
  • Patrick DeBois, Gene Kim, Mike Orzen, John Willis: The DevOps Cookbook
  • Michael Hüttermann: DevOps for Developers, Apress 2012, ISBN: 978-1-4302-4569-8
  • Seth Godin: Poke the Box, 2011
  • Jez Humble, David Farley: Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation, Addison-Wesley 2010, ISBN: 978-0321601919
  • David J. Anderson: Kanban: Successful Evolutionary Change for Your Technology Business, Blue Hole Press 2010
  • Kevin Behr, Gene Kim, George Spafford: The Visible Ops Handbook, IT Process Institute 2005
  • John Allspaw, Jesse Robbins: Web Operations: Keeping the Data On Time, O'Reilly Media 2010
  • Rob England: Introduction to Real ITSM, CreateSpace 2008

Znaki towarowe

  • IT Infrastructure Library®, ITIL® are registered trade marks of the Cabinet Office;
ostatnia modyfikacja 20 sierpnia 2016 r.