Firmy bývají konzervativní a ne všechny možné přínosy změn se opravdu využijí. Problémem je dotažení do zralé podoby, nedostává se vhodných softwarových nástrojů a ve hře jsou i bezpečnostní otázky. Cynthia Harvey sepsala na InformationWeek přehled nejčastějších chyb, které provázejí nasazení DevOps jako metody vývoje, testování a provozu softwaru. Na co si dávat pozor?
Někdy je DevOps pokládán pouze za způsob, jak zrychlit tvorbu kódu pomocí metod typu agilního/extrémního programování. Výsledkem může být současný pokles kvality kódu včetně např. dokumentace a auditů. Doporučuje se toto riziko omezit především zavedením testování už do raných fází vývojového procesu, to ale prozatím dělá jen relativně málo organizací.
Opačným extrémem je pomalé uvolňování nových verzí kódu, které jde přímo proti principům DevOps. Při pokročilém zvládnutí DevOps se nové verze kódu uvolňují víckrát denně, periody v řádu měsíce jsou nepřijatelné.
Principy DevOps by měly být v rámci IT nasazovány postupně, alespoň podle většiny doporučení; jde o dost radikální změnu a riziko je třeba rozložit. Podniky se tímto názorem vesměs řídí, DevOps se nasazuje v určitých odděleních firmy nebo pouze pro řešení konkrétních projektů. Pouze mezi 10–30 % podniků (podle různých průzkumů) nasadilo DevOps rovnou plošně. Problém ale je, že po počátečním nasazení DevOps další implementace těchto metod ustanou, pouze asi třetina podniků tak dojde k používání DevOps ve zralé podobě.
Standardně se za velký problém přechodu na DevOps pokládá celá firemní kultura a způsob myšlení (v podobných souvislostech často používaný výrok/fráze, že DevOps je „filozofií“). Zaměstnanci, včetně vyššího managementu, bývají konzervativní a podnik funguje vlastní setrvačností. Součástí přechodu na DevOps by měla být školení a další firmy vzdělávání. Z druhé strany řada firem přiznává, že pro radikální změnu přístupu k vývoji a nasazování softwaru prostě nedisponují dostatečnými odbornými znalostmi. Někdy se DevOps neobejde bez nutnosti přijmout nové lidi.
Problémem může být i dostatek vhodných softwarových nástrojů. Požadavky na nástroje pro průběžné nasazování softwaru se různí a zdaleka ne každému podniku stačí Docker. Chybí best practices (osvědčené postupy), různá oddělení i jednotliví lidé pracují až příliš podle svého. Příkladem takové nejistoty jsou třeba způsoby, jak se kód nechává větvit (forkování) a jak (především jak často) se provádí zase jeho slučování. Nemusí jít o katastrofu, ale plný potenciál DevOps pak zůstane nevyužitý.
A na závěr, když už se zavádí DevOps, měla by se dotáhnout automatizace (aby např. nepřetrvávala práce ručního nasazování softwaru na různé servery); obavy v souvislosti se změnou testování/auditování softwaru vzbuzují také otázky zabezpečení. Produktivní vývojové týmy tráví při DevOps otázkami zabezpečení relativně méně času – což ale nemusí signalizovat budoucí problémy, může jít i o doklad správného nasazení bezpečnostních principů už v raných fázích vývoje (dle průzkumu Puppet Research jsou komplikace s řešením bezpečnostním otázek typické pro i jinak málo efektivní vývojové týmy).
Podle průzkumu RightScale 84 % velkých a 72 % středních podniků dnes přijala alespoň některé postupy DevOps. Dle této analýzy se v režimu DevOps kód nasazuje a nové verze uvolňují v průměru až 200krát častěji, vytvoření aplikace je rychlejší až 24krát. Dle studie CA Technologies se náklady na vývoj aplikace a údržbu IT při DevOps v průměru snižují o 26 %. Rychlejší je při DevOps nejen samotný vývoj softwaru, ale i řešení problémů, zvyšuje se spokojenost zákazníků a DevOps pozitivně koreluje s růstem tržeb.
