(Kiemelt kép: Unsplash)
A 80-as évek közepén a szoftvereket kifejezetten a hardverekhez tervezték, melyen futottak. A frissítések terjesztése kihívást jelentett, és a vállalatok akkor szállították őket, amikor az eszközt felülvizsgálták. Idővel, ahogy a szoftverek terjesztésének módja egyre elterjedtebbé vált, ezek a frissítések végül elváltak a hardvertől, és a saját ütemükben fejlődtek. A 90-es évek eleje felé a fogyasztók nem vásároltak elég gyorsan számítógépeket ahhoz, hogy ezek a zárt ütemű frissítések indokoltak legyenek, így a gyártók elkezdtek átállni a hardverről a szoftverforgalmazásra, hogy kitöltsék az értékesítési ciklust. Ma az éves frissítések létrehozása kézenfekvő koncepciónak már tűnik. A Microsoft is ugyanezt érezte, amikor a Windows 95-tel elkezdett eltávolodni a szoftverek verzió szerinti elnevezésétől, és áttért az éves modellre. Természetesen a következő verziónak a Windows 96 nevet kellett volna viselnie, de mint minden kifinomult szoftver, ez is késedelmet szenvedett. A következő kiadást megfelelően Windows 98-nak nevezték el, tükrözve a megjelenésig eltelt idővel. Ez a ciklus folytatódott, mivel a szoftverfejlesztés nehezen tudott lépést tartani azzal a monumentális feladattal, hogy a vásárlókat mind szoftver-, mind hardverfronton rávegye a frissítésre. Csak az internet 1991 körüli megteremtése után következett be olyan változás a szoftverterjesztés módjában, mely megváltoztatta a kiadási ciklus egész koncepcióját.
Ha bővebben is érdeklik a nagyvállalati DevOps-megoldások, jöjjön el üzleti reggelinkre, április 25-én a Vígvarjú étterembe!
A DevOps kultúra fejlődése
Ha visszatekintünk a számítógépek történetére, akkor észrevehetjük, hogy a szoftverek egyszerre történő telepítésétől vagy kiadásától eljutottunk a jelenlegi modellünkig, mely átláthatóan, naponta történik. A 90-es évek vége felé, a dot-com boom fellendülése körül a szoftverek olyan bonyolulttá és kihívássá váltak, hogy a vállalatok nagy létszámú, a fejlesztési folyamat egyes aspektusait felügyelő szakembercsoportokat hoztak létre. Eltűntek azok az idők, amikor a szülők garázsában vagy kis csapatokban építettek valamit. Ennek a komplexitásnak a figyelembevételére két domináns csoport alakult ki: a fejlesztők és az üzemeltetők. A fejlesztőket azért fizették, hogy újítsanak, új funkciókat erőltessenek, és előre vigyék a dolgokat, ami elkerülhetetlenül kevésbé stabillá teszi a rendszert, vagy teljesen tönkre is teszi azt. Az üzemeltetők, vagy röviden Ops, azért kaptak fizetést, hogy a rendszert stabilan tartsák. A fejlesztők és az üzemeltetők különváltak és ellentétben álltak egymással. Ez idő alatt az Ops rendelkezett az alkalmazást futtató termelő gépek és adatbázisok kulcsaival, ami azt jelentette, hogy a fejlesztőknek rajtuk kellett keresztülmenniük a legegyszerűbb kiadások véglegesítéséhez. A fejlesztésnek viszont nem voltak meg az eszközei vagy tapasztalata a szoftver működéséhez szükséges összetett infrastruktúra karbantartásához. A fejlesztés és az üzemeltetés közötti kapcsolat nem működött túl jól, mert a vállalat egészének egyensúlyra volt szüksége a stabilitás és az innováció között.
A DevOps definíciója a kezdeti megfogalmazás óta fejlődött. Eredetileg két szerepkör, a fejlesztői és az üzemeltetési szerepkör kombinációját leíró kifejezés volt. Ma már ott tartunk, hogy automatizálhatjuk az összes olyan munkát, melyet eredetileg az Ops irányított. Ez azonban nem váltotta ki a szoftverfejlesztés „varázslatos” átalakulását. Ehelyett inkább egy hatalmas változást jelent a gondolkodásban arról, hogy hogyan adjunk lehetőséget a fejlesztőknek arra, hogy többet adjanak ki skálázhatóbb és megbízhatóbb módon. Ez egy szervezeti kultúráról szóló történet valójában. Olyasmi, amin egy olyan vállalatnál, mint a Netflix, minden fejlesztő osztozik és végez a mindennapi munkája során. A fejlesztők és az Ops között már nincs egyértelmű elválasztó vonal, és a nehéz feladatok automatizálását segítő eszközök mindkét csoportot felszabadítják, hogy a munkájuk azon területeire koncentrálhassanak, ahol szükség van a tehetségükre.
Alapelvek és gyakorlatok
A 2017-es State of DevOps jelentésben a DevOps a következőképpen van megfogalmazva: a DevOps olyan megértett gyakorlatok és kulturális értékek összessége, melyek bizonyítottan segítik a különböző méretű szervezeteket abban, hogy javítsák a szoftverkiadási ciklusokat, a szoftverminőséget, a biztonságot és a termékfejlesztéssel kapcsolatos gyors visszajelzések megszerzésének képességét (DevOps=Development+Quality Assurance (QA)+ Operations). Ugyanebben a dokumentumban összehasonlították a magasan teljesítő vállalatokat a gyengébben prosperáló cégekkel. Ahol kimutatták, hogy a magasan teljesítők csökkentik a sebességüket (vagy az átfutási időt), miközben javították a stabilitásukat. Ne feledjük, hogy a DevOps nem egy csapat, hanem egy kultúra, így az elkötelezett vezetés elengedhetetlen a sikeres DevOps átalakításokhoz. DevOpsként a fő célunk az, hogy segítsük a szoftverek gyors és megbízható szállítását. Gene Kim, John Willis, Jez Humble és Patrick Debois a The DevOps Handbook című könyvükben 3 módszert határoztak meg e cél eléréséhez. A DevOps-kezdeményezés alapját képező legfontosabb technikai gyakorlatok közé tartozik, hogy a fejlesztői és üzemeltetési csapatok egységesítsék a szoftverszállításhoz szükséges agilis folyamatok és eszközök közös készletét. A DevOps egy olyan kulturális szemlélet, mely szerint mindenkinek részt kell vennie a helyes munkavégzésben.
Munkafolyamat
Ez az elv a funkciók folyamatos kiadását képzeli el az ügyfelek számára. A célunk itt az átfutási időnk csökkentése. Az átfutási idő csökkentését segítő gyakorlatok a következők lehetnek.
A korlátozások kiküszöbölése: a munkafolyamatban minden munkát azonosítani kell. Általában ez a következőket foglalja magában: tervezés (várakozás, elemzés, munka és jóváhagyások), fejlesztés (várakozás, becslés, fejlesztés, tesztek és jóváhagyások), QA (Quality Assurance avagy minőségbiztosítás – várakozás, automatizált tesztek és kézi tesztek) és telepítés (várakozás, ops munka, jóváhagyások, telepítés, ellenőrzés). Ha már felvázoltuk a teljes munkafolyamatot, a szűk keresztmetszetek meghatározhatók és csökkenthetők (vagy még jobb, ha megszüntethetők).
Folyamatos szállítás: a telepítéseket a csapat napi munkájának részévé teszi. Általában folyamatos integrációval, csökkentett kötegmérettel, könnyű visszaforgatással stb. érhető el ez. Fő célja, hogy a kiadások kevésbé legyenek ijesztőek, így gyakran szállíthatunk, és gyors visszajelzést kaphatunk arról, ami a felhasználókat ténylegesen érdekli.
A pazarlás csökkentése: ide tartozik a részben elvégzett munka, az érték nélküli extra folyamatok, a felesleges funkciók, a feladatváltás, a blokkolt jegyek, a mozgás, a hibák (minél tovább tart egy hiba megtalálása, annál drágább lesz a kijavítása), a kézi munka és a felesleges munkafolyamatok előfordulásának csökkentése.
Javítsuk a napi munkánkat: a problémák és a technikai adósságok felhalmozásával a végén csak a megoldások elvégzéséhez juthatunk. A napi munkánál is fontosabb a napi munka javítása. Minden fejlesztési és üzemeltetési ciklus legalább 20%-kát refaktorálásra, automatizálásra és NFR-ekre kell fordítani.
A kijelölt Ops és QA-k integrálása a fejlesztői csapatokba: így olyan független csapatok jönnek létre, melyeknek nem kell jegyeket nyitniuk más csapatoknak egy funkció befejezéséhez. A csapatok struktúrája rendkívül fontos, a Conway-törvény szerint „a rendszereket tervező szervezetek arra kényszerülnek, hogy olyan terveket hozzanak létre, melyek e szervezetek kommunikációs struktúráinak a másolatai”.
Visszajelzés
Ahhoz, hogy rugalmas rendszert építsünk, növelnünk kell az információáramlást minél több területről (hamarabb, gyorsabban és olcsóbban).
Hozzunk létre telemetriát és elemezzük azt: Rendszerünkre vonatkozóan rendelkeznünk kell egy listával az eseményekről üzleti szinten, alkalmazási szinten, infrastrukturális szinten, ügyfélszoftver szinten és telepítési csővezeték szinten. Ezt elemezni kell, és riasztásokat kell kiadni, ha nem egy minta szerint viselkednek.
Tesztkiadások és szondahipotézisek: A különböző típusú telepítések (kanári telepítés, A/B tesztelés és kék-zöld tesztelés) engedélyezésével.
Folyamatos integráció: ahol minden egyes kiadást egy automatizált build-el ellenőriznek, melynek a lehető leggyorsabban fel kell felfedeznie a hibákat. Ez lehetővé teszi a fejlesztők számára, hogy gyors visszajelzést kapjanak a hibák minél korábbi javításához. A fejlesztőknek képesnek kell lenniük egységtesztek, átvételi tesztek és integrációs tesztek futtatására (és látható tesztlefedettséggel kell rendelkezniük). Teljesítményteszteket is végezhetünk úgy, hogy ugyanazt az integrációs tesztet többször párhuzamosan futtatják. A statikus kódelemzést is lehetne automatizálni a biztonság vagy a „tiszta kód” érdekében.
Folyamatos tanulás és fejlesztés
A szervezeti tudásra összpontosít, és célja, hogy megtanítsa az embereket gondolkodni – a viselkedés megváltoztatása kultúrát teremt. Ennek eléréséhez az alábbiakra van szükség.
Biztonsági kultúra: Ez a fajta kultúra megkönnyíti, hogy a vezetőnek félelem nélkül rossz híreket adjon, így mindenki arra koncentrálhat, hogy mi okozta a tényleges problémát, nem pedig arra, hogy ki okozta azt. A vezetőnek is meg kell tudnia osztani a rossz híreket, a munkavállalók problémamegoldók, és csak akkor tudnak segíteni, ha elmondják nekik a valódi problémát. A hibátlan utólagos vizsgálatot is el kellene végezni, hogy büntetés helyett a tanulásra ösztönözzünk, elkerülve az olyan megoldásokat, mint a „legyünk óvatosabbak”. A Google a „hibaköltségvetés” nevű módszert alkalmazza, hogy bizonyos szintű hibákat megengedjen, így tesztelhetik a hipotéziseket és tanulhatnak a hibáikból, amíg el nem érik a hibaköltségvetést.
Ellenálló képesség tesztelése: Ennek egyik fő példája a Netflix káoszmajma (Chaos Monkey). Ez teszteléssel biztosítja a rugalmasságot. A Netflix elképzelése szerint a gyakorlat teszi a mestert, így a hibázás egyetlen módja, hogy jobbá váljunk a kudarcok terén, az az, hogy elrontunk dolgokat.
A helyi felfedezéseket alakítsuk át globális fejlesztésekké: Telemetria hozzáadásával vagy dokumentáció készítésével érhető el. Az utóvizsgálatoknak mindenki számára elérhetőnek kell lenniük, hogy elolvashassák és tanulhassanak belőle.
Tervezzünk képzéseket: Ez történhet a vállalaton belül, ahol egy csapat új koncepciókat vagy készségeket tanít másoknak, illetve tanfolyamokhoz, konferenciákhoz való hozzáféréssel vagy heti rendszerességgel történő találkozással, hogy elolvassanak és kommentáljanak egy könyvet.
