A DevOps egyrészt kultúra, másrészt készséghalmaz, harmadrészt az előzőeket támogató szoftvereszközök összessége. Egyfajta filozófia, amely azt tűzi ki célul, hogy fejlesztő csapatok, IT üzemeltetés és minőségbiztosítók mind együttesen dolgozzanak annak érdekében, hogy az egyes szoftverek és azok új verziói zökkenőmentesen készüljenek el és kerüljenek éles környezetbe. Az elmúlt évtizedekben – a korábbi, mostanra elavult standardok és gyakorlatok követésének hatására – a legtöbb nagyvállalatnál az előbb felsorolt IT részlegek működése eléggé izolálttá vált. Ezen próbál változtatni a DevOps. Egy kapocs, aminek segítségével mindenki együtt dolgozhat a projektek sikeréért.

A DevOps folyamatok középpontjában a folyamatos integráció, a gyakori és hatékony release adás, a manuális hibalehetőségek kiküszöbölése, automatikus és megkerülhetetlen minőségbiztosítás, a konténerizált szállítás és a rendszerek skálázhatóságának támogatása áll.

A hagyományos megközelítés szerint a szoftver fejlesztés és a szoftver üzemeltetés izoláltan működik, a két részleg közötti kommunikációra szigorú szabályok vonatkoznak. Ezekre szükség is van, hiszen a rendszerek helyes működéséhez szükség van információcserére, és mivel a rendszerek készítői és működtetői között nincs átfedés, ezért bonyolult folyamatok betartására van szükség ahhoz, hogy az egész ökoszisztéma zökkenőmentesen - vagy minimális zökkenőkkel működjön. Az évek során ezek a folyamatok pontosan szabályozva lettek - megszületett az ITIL, amely az informatikai rendszerek fejlesztését és üzemeltetését szabályozza. Külön iparág épült erre a szabványra, képzett ITIL szakértők vannak a világ minden pontján, akik éberen őrködnek a szabályok betartása felett.

Mégis, mi az oka annak, hogy ez a jól bevált folyamat repedezik?

Az internet.

Azzal, hogy az emberiség jelentős részének karnyújtásnyira vált a világ, új típusú igények jelentek meg. A nyaralást a kanapéról, néhány óra alatt meg tudjuk szervezni, ez korábban napokba, hetekbe került. A szolgáltatók számára pillanatok alatt kiderül, hogy milyen típusú szolgáltatásokra van igény a felhasználók oldaláról. Aki ezt nem tudja kielégíteni, attól villámgyorsan elfordulnak az ügyfelek és keresnek olyat, aki képes erre. Mert ne feledjük, ilyen mindig lesz.

A hagyományosan felépített rendszerek és szolgáltatások éppen amiatt váltak korlátjává ennek a törekvésnek, ami miatt kitalálták őket - a robosztusságuk mellé merevség párosult, ami alkalmatlanná teszi őket a változások gyors követésére. Az a szolgáltató, aki éves szinten 4 release-ben gondolkodik, elveszíti a versenyt - mire kijön a megoldásával, az már régen meghaladott lesz.

Mégis, hogyan lehet ezt a gordiuszi csomót átvágni? Hogyan lehet gyors iterációkat csinálni úgy, hogy ne sérüljön a minőség, robosztusság és általában azok az elvek amelyek a nagyvállalati környezetben elengedhetetlenek?

Itt jön képbe a devops. Ha át tudjuk vágni a szigorú határokat a fejlesztői és az üzemeltetői oldal között, akkor az élesítési folyamat drámaian fel tud gyorsulni. Ahhoz viszont, hogy ez ne veszélyeztesse a működést, a következő feltételeknek kell teljesülnie:

Szemléletmód váltás. A folyamatban levő összes szereplőnek el kell fogadnia, hogy mindenki azért felelős hogy a leszállított rendszer megfelelően működjön. Ez nem azt jelenti, hogy mindenkinek mindenhez értenie kell. Inkább azt, hogy úgy kell végeznie a feladatát, hogy az az nem a “fejlesztés” vagy az “üzemeltetés”, hanem a “rendszer működés”  igényeit elégítse ki. Nélkülözhetetlen a csapattagok között a folyamatos kommunikáció, és a proaktív problémamegoldás

Folyamat automatizálás. A sok iteráció sok monoton ismétlődő feladattal jár - Build, tesztelés, telepítések, új környezetek kialakítása, stb. Ezek folyamatos végrehajtása komoly ráfordítást igénylő, idegőrlő munka és rengeteg hibalehetőséggel jár. Ezért szükség van azokra az eszközökre amelyek ezeket a tevékenységeket részben vagy akár egészében is automatizálni tudják - ezzel biztosítva a hibák drasztikus csökkenését és az egyenletes minőséget.

Fontos azonban leszögezni, hogy a devops módszertan sem a bölcsek köve. Nem minden esetben érdemes használni, bizonyos esetekben többet árthatunk vele mint amennyi előny származik a használatából. Ahol nincsenek gyors és szignifikáns változások, ott nem mutatkozik meg az igazi ereje. Az is lényeges, hogy kevés olyan feladat van, ahol vegytiszta módon alkalmazható - nincs olyan, hogy ez most devops-szal csináljuk, ezt pedig nem. Az egyes elemei elhagyhatók, testre szabhatók, de a lényeg hogy a szemléletmód, amit biztosít, meghatározó a termék életciklusa során.

Szerző:

SX Csapata