Pokud se pohybujete v IT a slova jako kvalita, automatizace nebo spolupráce nevnímáte jako sprosté výrazivo, určitě budete chtít zjistit, do jaké míry se principy DevOps dají reálně využít ve vaší každodenní praxi. DevOps spočívá v propojení vývoje software s jeho provozem.

Snahy o vzájemné propojení těchto tradičně oddělených komunit a nastavení efektivnější spolupráce existovaly samozřejmě už dříve. Jako první je ale systematicky uchopil a pojmenoval Patrick Dubois, frustrovaný belgický konzultant, který se mezi lety 2007 a 2008 staral o migraci dat pro belgickou vládu. Primárně se věnoval testování kompatibility jednotlivých používaných nástrojů a pokusům o nastavení procesů nezbytných pro fungující kooperaci mezi vývojáři a operačním týmem obhospodařujícím vládní servery a databázové sítě.

Agilní správa systémů jako předchůdce DevOpsu

Během celého procesu postupně narůstalo Duboisovo znechucení z překážek stojících mezi aplikačními a infrastrukturními postupy a nedostatkem vzájemného pochopení mezi jednotlivými týmy. Když v roce 2008 uváděl vývojář a softwarový architekt Andrew „Clay“ Shafer diskusi o agilní infrastruktuře během Agile konference v kanadském Torontu, zúčastnil se jí Dubois jako jediný zájemce. Z jejich setkání postupně vykrystalizoval koncept „agilní správy systémů“, ale jimi založená stejnojmenná skupina zaznamenala podle Googlu jen omezený zájem.

Za den, kdy se IT svět oficiálně dozvěděl o metodách označovaných dnes zkratkou DevOps, je obecně považována přednáška dvou zaměstnanců společnosti Flickr provozující stejnojmenný web pro sdílení fotografií. John Allspaw tehdy působil jako technický ředitel a Paul Hammond měl na starosti vývoj této platformy. Jejich prezentace o spolupráci mezi vývojem a operativou a jejím nastavení v rámci Flickru zazněla na konferenci O’Reilly Velocity v roce 2009. Oba přednášející jasně deklarovali, že vzájemný vztah obou oddělení musí být „bezproblémový, transparentní a plně integrovaný“, má-li jejich spolupráce vést ve svém důsledku ke zdárnému výsledku.

Během přednášky zazněly snad všechny typické poznámky a obvyklé předsudky, kvůli nimž bylo takřka nemožné přimět vývojáře a IT administrátory k fungující spolupráci. Tehdy nastavené procesy vzájemnou propast mezi oběma odděleními spíše dále prohlubovaly, než aby se ji pokoušely překonat. „Nemůže za to můj kód, ale tvůj stroj,“ zaznělo mimo jiné na této legendární prezentací. Na jejím základy postupně vykrystalizovaly metody DevOps, snažící se zmiňovanou propast odstranit a napomoci tak zrychlení dodávek softwaru a zlepšení jeho výsledné kvality.

Devopsdays: Z Gentu až do Kalifornie

Dubois se Allspawovy a Hammondovy prezentace nemohl zúčastnit osobně, ale sledoval ji prostřednictvím video streamu. Protože jasně pojmenovala problémy, na které narážel ve své každodenní praxi i on, rozhodl se svolat pomocí sociálních sítí vlastní konferenci. V belgickém Gentu se tak díky jeho úsilí uskutečnily v roce 2009 první Devopsdays. Termín DevOps se tak oficiálně stal součástí žargonu IT specialistů.

Druhý ročník Devopsdays se pro rostoucí zájem konal ve Spojených státech a proběhl během zmiňované konference Velocity v kalifornském Mountain View v roce 2010. Od té doby bylo jen ve Spojených státech zorganizováno několik desítek DevOps dnů a konkrétně v loňském roce jich bylo po celém světě zorganizováno více než třicet.

DevOps jako téma na román

Dalším klíčovým momentem pro rozvoj principů známých pod zkratkou DevOps se stalo vydání knihy The Phoenix Project, kterou v roce 2013 napsalo trio autorů Gene Kim, Kevin Behr a George Spafford. Jejich román vypráví příběh IT manažera, nacházejícího se ve zdánlivě beznadějné situaci. Je pověřen záchranou ecommerce projektu, jehož vývoj se dostal do kritické fáze.

V roli tajemného rádce mu radí jeden z investorů a pomocí zásad tzv. štíhlé výroby, které vyvinula japonská firma Toyota po druhé světové válce, ho naučí novému uvažování o IT obecně a vývoji aplikací zvláště, přičemž mu krom jiného představí i koncept DevOps. Knihou se inspirovali i tvůrci podobně koncipovaného románu Outsource or Else! (Outsorcujte nebo!), ve které technický ředitel jedné softwarové firmy využívá principů DevOps při outsourcingu vývoje nového vlajkového produktu jeho společnosti.

Josef Wudy Autor je technickým ředitelem společnosti MEMOS Software