Principy DevOps (a další „agilní techniky“) byly pro vývoj podnikového softwaru přijaty z dobrých důvodů – již ve fázi vývoje jsou v tomto případě lépe zahnuty požadavky uživatelů a nasazení aplikace do produkčního prostředí by mělo celkově proběhnout rychleji. Tyto cíle DevOps se do značné míry daří plnit, nicméně se současně objevily i nové problémy. Mary E. Shacklett z Transworld Data uvádí na InformationWeek hlavní příčiny toho, proč přijetí principů DevOps v mnoha firmách nepřináší očekávané výsledky a další rozšiřování tohoto přístupu může být nakonec i kontraproduktivní.
Hlavními zmíněnými problémy/překážkami jsou neznámé a velmi různorodé specializované nástroje. Jejich funkcionalita bývá různorodá, mohou např. generovat testovací skripty, automatizovat testování, monitorovat výkon aplikací nebo optimalizovat jejich sestavování. Přitom tyto nástroje ale bývají často nové i pro jinak zkušené zaměstnance z oddělení IT. Nutností pak bývá školení (jak lidí z IT, tak často i koncových uživatelů); lidé si současně musejí zvyknout, jaké mají tyto nástroje omezení. Osvědčené nástroje se naopak často ocitají na vedlejší koleji, což může vůči zavádění DevOps vyvolávat odpor.
Obecně vede odpor k DevOps – i z řady jiných důvodů – často k tomu, že tento přístup pak podniku nepřináší dostatečnou hodnotu. Pokud uživatelé v podniku nedokážou držet krok s rychlostí změn při překotném nasazování metod DevOps, možností je sice např. zintenzivnit školení/vzdělávání nebo i personální obměna, ale možná je také třeba (nebo je alespoň jednodušší) politiky v oblasti DevOps nějak přehodnotit.
Dalším problémem bývají standardy, respektive jejich nedostatek, a obtíže při definování nových procesů. Proti standardnímu způsobu vývoje softwaru dochází k řadě změn a některé tradiční principy jsou dokonce postaveny na hlavu. Ještě před samotným zavedením DevOps má rozhodně proto smysl definovat nějakou univerzální sadu nástrojů, kterou budou všichni používat, a konkrétní případy tohoto používání. Nově definovat bývá třeba řízení a zabezpečení v celé fázi předcházející nasazení aplikace. Totéž často platí pro definování kvality a související metriky (co musí aplikace splnit před nasazením do produkčního prostředí atd.). Jaké procesy bude i nadále třeba provádět ručně a co je zcela automatizováno?
V základu DevOps stojí neustálá spolupráce ve všech fázích – při definice, návrhu, vývoji, testování, nasazování i údržbě aplikací. V praxi je ovšem často problém s požadavkem na nepřetržité interakce, kdy všechny zúčastněné skupiny by měly neustále zasahovat do všech fází těchto procesů (které navíc často probíhají současně). Jak se uvádí, např. koncoví uživatelé mají tendenci spolupracovat s firemním IT oddělením v počátečních fázích definice, návrhu, testování nebo i nasazení aplikací – ale jakmile jsou aplikace jednou nasazeny, další zájem uživatelů obvykle klesá (mají „svou práci“ a pokud možno se nechtějí aplikací dále zabývat).
Důraz na rychlost v režimu DevOps znamená, že nasazovány mohou být i nehotové aplikace a ty se pak odlaďují až za chodu. Nebo se třeba neodladí nikdy, protože za důležitější se pokládá přidávání nových funkcí. „Vnitřní hodnota“ a inovace, které přináší nová aplikace, mohou být důležitější než její chyby. Zde by nicméně měla panovat shoda mezi uživateli a oddělením IT, že to tak opravdu je. Navíc jiný režim by měl platit pro aplikace kritické. A konečně, něco jiného lze tolerovat u aplikací provozovaných výhradně v rámci podniku a něco jiného platí, pokud je mají používat i zákazníci a další obchodní partneři. Obecně platí, že všechny aplikace pro vnější použití by měly podléhat přísným standardům, a to nejen z hlediska samotné kvality/funkčnosti, ale pochopitelně i bezpečnosti a správy.
Nástroje pro automatizované testování DevOps zjednodušují zajištění kvality aplikací a zkracují dobu tohoto procesu , ale tyto nástroje jsou samy o sobě často příliš obecné. Konkrétní prostředí ve firmě může být specifické; na zajištění kvality aplikací se pak stejně musí intenzivně podílet i systémoví specialisté.
Celkově lze říci, že principy DevOps se v některých oblastech osvědčily lépe, hlavně při vývoji webových a ad hoc aplikací. Naopak DevOps má svá omezení, pokud jde o vývoj kritických aplikací, které vyžadují značné množství pečlivé integrace s existujícím kódem, a dále pak u aplikací, kde nelze očekávat příliš aktivní spolupráci koncových uživatelů.
Zdroj: InformationWeek