A Development (fejlesztés) és az Operations (üzemeltetés) sok szervezetnél még mindig két külön világ. Azonban ez a két világ nagyon jól működik együtt. Főleg úgy, ha összeállít egy DevOps csapatot, ami által nem két külön csapattal kell dolgoznia, akik alig, ha vállalnak garanciát saját részükért a termékkel kapcsolatban. Így egy csapatot kap, amelynek a célja közös: egy jól működő termék létrehozása, amely minden ügyfél számára könnyen használható.
Hónapokkal később fellépő zavar
Sok szervezetnél gyakran előfordul, hogy a fejlesztői csapatok elkészítenek egy nagyszerű új funkcionalitást a szoftverben. Ez mégsem működik megfelelően, ennek ellenére az account managerek és a product ownerek szívesen mutatják be ügyfeleiknek és a stakeholdereknek, a fejlesztés pedig mosollyal az arcán kezd hozzá a következő projektjéhez.
Azonban később, néhány hónap múlva elérkezik a release ideje. Az új funkcionalitásnak köszönhetően sokat romlik a termék teljesítménye és zavar lép fel a mögötte futó adatbázisban is, miközben a fejlesztők már régen egy másik projekten dolgoznak.
Az Operations csapata pedig már újra látja a vihar közeledtét: az adatbázissal kapcsolatos segélykiáltások számát kell csökkenteniük úgy, hogy a termék teljesítménye se essen vissza. Ekkor igazából már mondhatjuk azt is, hogy valójában két fejlesztői részleg alakult ki.
Együtt a végső cél felé
A cégek életében egyre jelentősebb szerepet kapnak az Agilis módszertan alapelvei, a szoftver-termékek pedig egyre gyakrabban a Continuous Deployment, vagyis a folyamatos szállítás alapelve szerint kerülnek a piacra. Természetesen senki nem örülne annak, ha egy új funkcionalitáson még hónapokkal később is javítani kellene. Amikor egy új funkcióval gazdagítjuk a termékünket, a legjobb, ha azonnal visszajelzések érkeznek működésével kapcsolatban. Így a fejlesztés gyorsan ki tudja javítani a fontos hibákat.
De hogyan tud arról gondoskodni, hogy munkatársai minél gyorsabban adjanak visszajelzést a termékkel kapcsolatban? Sok szervezet számára a kérdésre adott választ a DevOps jelenti. A fejlesztés nem csak a termék elkészítéséért felelős, hanem annak sikeres használatáért is. Az üzemeltetés pedig együtt ötletel velük a fejlesztés folyamata során.
Közös alkalmazások használata
A Development azokat a rendszereket használja és tartja karban, amelyekkel az Operations is sok tapasztalattal rendelkezik, ilyenek például az automatikus tesztelés és a code repository-k (kódbázis) szempontjából. Miért ne használhatná a fejlesztés is ugyanazokat a rendszereket, mint az üzemeltetés?
Még hatékonyabb, ha ezeket az alkalmazásokat az Operations üzemelteti mindkét fél számára, mivel ez az a terület, amelyen ők a legtöbb tapasztalattal rendelkeznek. Ha cége készen áll erre, akkor a DTAP-infrastuktúrájának (Development, Testing, Acceptance, Production) központi kezelése például az üzemeltetés SaaS-környezetein is okos döntés.
Az új technológiák hatékonyabb karbantartása
Mivel az IT-infrastruktúrák egyre összetettebbé válnak, a folyamatok automatizálása egyre fontosabbá válik az üzemeltetéssel foglalkozó csapatok számára. Ha például 1500 SaaS-környezetet üzemeltet egyszerre, hatékonyabb, ha nem csak manuálisan frissíti ezeket. Emiatt az Operations is egyre többet foglalkozik kódokkal a munkája során, mint ahogy ez a fejlesztésen is történik. Ezért például egy úgynevezett „desired state configuration”-t érdemes annyira központilag kezelni, amennyire csak lehetséges, amelyhez használhat verziókezelő rendszereket, mint például a Git.
A kulcs ahhoz, hogy cégét DevOps-szervezetnek tudja nevezni, az ugyanazokban a környezetekben és alkalmazásokban történő közös munkában, valamint az új funkcionalitások lehető leghatékonyabb módon történő szállításában rejlik. A hab a tortán, hogy ez által nem két külön csapat fog dolgozni a cégén belül, akik újra és újra feltalálják a spanyolviaszt egymástól függetlenül.
Hogyan változtasson az IT osztály megítélésén? Olvassa el ingyenesen letölthető e-bookunkat, és tudja meg, hogyan fejlesztheti 6 lépésben az IT osztályt!
