DevOps – A digitális fejlődés legújabb színtere

  • DevOps

DevOps – A digitális fejlődés legújabb színtere

Az emúlt évtizedekben sosem látott technológiai fejlődés szemtanúi lehettünk. Az új technológiák, fejlesztési módszertanok fénysebességel alakítják át az ipar szinte minden szegmensét. Ehhez járul hozzá a DevOps, ami mellett nem mehet el egy innovatív cég sem, ha digitális fejlődést szeretne.

Mint ahogy ebben a cikkben is írtuk, a digitális transzformáció nagyon sok előnyt rejt a vállalkozások számára, de minden szervezetnek fel kell készülnie a megváltozott fogyasztói szokások, illetve a gyorsan változó üzleti környezet által generált kihívásokra. Ez a gyakorlatban azt is jelenti, hogy bizonyos mértékben minden cég egyben fejlesztő / IT szervezetté kell váljon. Ahhoz, hogy a szoftveripar adaptálódni tudjon, hatékonyabban és megbízható módon legyen képes értéket teremteni, új módszertanokat, szervezeti struktúrákat és technológiákat kellett bevezetnie a szoftverfejlesztési életciklusba.

Fejlesztési metodikák

A fejlesztési metodikákat illetően, az agilis módszertanok a legtöbb iparágban sztenderdé váltak. Behozták a fejlesztői folyamatokba a folyamatos értékteremtés iránti igényt, a lean szemléletmódot. Iterációról iterációra működő szoftvertermék elkészítése lett a cél dokumentum halmazok és prezentációk helyett. A korábbi fél-1 éves release ciklusokat felváltották a napi, heti telepítések.

Egy gyorsan változó környezetben vajon le kell mondanunk a fejlesztési folyamat fenntarthatóságáról a sebesség oltárán? A válasz, egyértelműen nem. De ez a klasszikus technikákkal, módszertanokkal nem fog menni. Ebben tud segítségünkre lenni a DevOps.

Mit ad a DevOps – mint módszertan?

Maga a fogalom, közel 1 évtizede része az IT iparnak. Célja, hogy minél hatékonyabban, megbízható módon legyünk képesek értéket teremteni az ügyfeleinknek. A legfontosabb célunk az kell legyen, hogy bármely időpillanatban működő szoftvert tudjunk adni a végfelhasználóinknak.  Hogyan tudjuk ezt elérni?

Ennek három allapillérét azonosíthatjuk be:

  1. Szervezeti átalakítás, a silók lebontása a fejlesztői és üzemeltetői, illetve az üzletfejlesztés között.
  2. A második pillér a megfelelő CI/CD infrastruktúra kiépítése és a fejlesztési lépések automatizációja.
  3. A harmadik lépés pedig a már élesben működő rendszereink folyamatos felügyelete és az üzemeltetés tapasztalatainak  becsatornázása a fejlesztési folyamatba.

Ezek alapján fontos tisztáznunk, hogy a DevOps nem egy adott technológia, egy szervezeti egység, vagy egy szerepkör (lásd DevOps engineer). Sokkal inkább módszertan, egy utazás, amelynek végső célja az értékteremtés. Ha sztenderd definiciót kellene meghatároznunk, a DevOps az emberek, a folyamataink és a technológia uniója. E három pillér mindegyike szükséges a sikeres bevezetéséhez.

A szervezeti kultúra átalakításával a fejlesztői csapataink képessé válnak magas minőségű termékeket előállítani, ráadásul gyorsabban, mint azon csapatok, ahol csak részben implementálták a megfelelő praktikákat, szervezeti kultúrát.

Milyen előnyökkel jár a DevOps bevezetése? 

  • T2M (Time to market) rövidítése, hamarabb piacra léphetünk a termékkel, illetve az új fejlesztéseink is gyorsabban jutnak el a végfelhasználokhoz.
  • Fel tudunk készülni és adaptálódni a piaci változásokhoz. Továbbá technológiai előnyhoz juthatunk versenytársainkkal szemben.
  • Növelhetjük a rendszereink megbízhatóságát és stabilitását az automatizált tesztekkel, folyamatos monitorozással stb..

A DevOps – mint kultúra

Ahogy korábban kifejtettük, a DevOps kiemelt feladatként tekinti a megfelő szervezeti struktúra, kultúra kialakítását. Ez a fajta változás megköveteli a szervezeten belüli kollaborációt, épít a cégen belüli transzparenciára.

A különböző csapatoknak, mint fejlesztői és üzemeltetői csapatok, meg kell osszák egymással folyamataikat, prioritásaikat és fel kell sorakozniuk egy olyan közös cél mögé, ami valós üzleti értéket teremt.

Egy ilyen közös cél lehet például a telepítések számának növelése 50 %-kal, vagy leszorítani az éles környezetben talált bugok számát 50%-kal. A közös célokon kívül a csapatoknak abban is meg kell állapodniuk, milyen KPI-ket (key performance indicator) alkalmaznak, miben mérik a sikerességük mértékét? Transzparencia mindenekelőtt!

DevOps  – a humán változások motorja

További része az új szervezeti felállásnak, a felelősségi körök balra tolódása. A teljes fejlesztési életciklus során bizonyos aktivitásokat eltolunk a fejlesztési folyamat minél korábbi fázisaiba. A fejlesztő már nem csak kódolással foglalkozik, de a munkája részét kell képezze a tesztelés is például. Mit jelent ez?

A fejlesztői csapat nem csak az új kódok fejlesztésért felel a továbbiakban, de olyan szempontokat is figyelembe kell venniük, amely az üzemeltetést, a biztonságot és egyéb aspektusokat érint. Ennek megfelelően az IT üzemeltetési csapat is be kell vonódjon a projekt korai fázisaiba, a fejlesztéssel közösen megtalálni azokat a technológiákat és módszertanokat, amelyek segíthetnek elérni a kívánt célt.

Egy példával élve, az automtizált tesztelés, a penetrációs tesztek, vagy a kódbázis szkennelése természetes része kell legyen a fejlesztési folyamatnak, míg klasszikus berendezkedésű projektekben ezek az aktivitások sokszor csak a fejlesztést követően történnek meg, vagy már csak a fejlesztés nagyon előrehaladott állapotában.

A DevOps – mint technológia

Ahhoz, hogy technológiai oldalról is kellően megtámogassuk a projektjeinket, be kell vezetni olyan design patterneket, praktikákat, amelyek lehetővé teszik a minél magasabb fokú kollaborációt és elősegítik a folyamataink automatizációját.

Ilyen például a Contunous Integration és Delivery, a központi konfiguráció menedzsment, agilis módszertanok a fejlesztésben, a kölönféle felhő platformok használata. Ezek közül a legszélesebb körben elterjet praktitát majdnem minden hazai cég is alkalmazza. Egy megfeleően megépített CI/CD rendszer félsiker, de korántsem elegendő a sikerhez.

Continous integration and Delivery

A CI/CD folyamatok lehetővé teszik a csapat számára, hogy bármilyen a verzió-kezelő rendszerben történő változás hatására lefussanak olyan automatizmusok, amelyek képesek garantálni, hogy a fejlesztett funkciók, nem sértik a közös kódbázis integritását a merge folyamat során.

A CI folyamat felelőssége a szoftver fordítása, tesztelése és integrációja a közös kódbázisba automatikus módon. Amennyiben nem megfelelő a módosítások minősége (nem elegendő teszt lefedettség, biztonsági  problémák, nem megfelelő sztenderdek használata, általánosan sérül a csapat DOD-ja) az integrációs folyamat megszakad.

A CD, azaz Continous Delivery pedig egy képesség meglétét jelenti. A csapatnak bármely időpillanatban készen kell állnia egy új, müködő szoftver verzió kiadására.  A CI/CD pipeline alapja a magas fokú automatizáció, próbáljunk meg a fordítás / telepítés lehető legtöbb lépését automatizálni deklaratív/programozott eszközökkel. Ezzel elérjük, hogy a fejlesztési folyamatunk stabilitása, performanciája az emberi beavatkozás miatt csorbát szenvedjen. Természetesen előfordulnak olyan esetek, mely során nem elkerülhető a manuális intervenció. Néhány gyakran használt platform például az Azure DevOps Services, GitHub, Gitlab és társaik.

Mit jelent ez a gyakorlatban?

Ha egy klasszikus / agilis fejlesztési pipeline-t végig nézünk az alábbi lépéseket azonosíthatjuk be.

  • Követelmény analízis, információk összegyűjtése
  • Tervezés
  • Fejlesztés
  • Telepítés
  • Karbantartás, monitorozás

Minden új commit hatására lefutnak azok a minőséget ellenőrző scriptek, eszközök, amelyek valamilyen aspektusból vizsgálják a kódot. Ez lehet valamilyen kódolási sztenderd betartásának ellenőrzése, statikus kód analízis, ahol a kódban használt struktúrákat, mintákat elemezzük anti-patternek után kutatva. Egyik népszerű statikus elemző eszköz például a SonarQube lehet.

A build folyamat alatti tesztelés során tipikusan unit teszteket futtatunk. Mérhetjük a tesztlefedettséget, amely mértéke szintén befolyásolhatja a build sikerességét. Amit fontos megemlíteni, hogy további úgynevezett quality gate-eket kell a folyamatba építeni, amelyek alapján döntést tudunk hozni a kód minőségét illetően.

Az összegyűjtött információk alapján eldönthetjük, kívánjuk-e megtörni az integrációs / build folyamatot, vagy engedjük az integrációt és tovább lépünk a következő szakaszba a tesztelésben / telepítésben. Mik lehetnek ezek a KPI-ok? Ahogy említettem, például tesztlefedettség, a statikus kódelemzésből kiesett struktúrális problémák, biztonsági sebezhetőségek súlyossága és számossága. Amennyiben tovább lépünk a folyamatban, elvégezhetjük az új fejlesztések integrációs / biztonsági / performancia tesztjeit, illetve kitelepítjük az új verziót teszt környezetekre, ahol a tesztelők és üzleti felhasználók is elkezdhetik a manuális és exploratory tesztelést.

Egy klasszikus fejlesztési folyamatban ezek a feladatok jól behatárolt felősségi körökhöz vannak rendelve. A fejlesztő megírja a unit teszteket, a tesztelő az integrációs és egyéb teszteket, majd a telepítésért és monitorozásért az üzemeltetők lesznek felelősek.  Egy DevOps vezérelt projektben ezek a felelősségi körök elmosódnak és a feladatok egyre inkább korábbra tolódnak az időben.

A fejlesztő kötelessége a tesztelés támogatása, az automata tesztek tervezése és irása is. Kell, hogy legyen rálátása arra, hogy milyen infrastruktúrán lesz üzemeltetve a rendszer. Egy Instrastructure as a Code mintát használó projektben az infrastruktúra kódjának a megírásában is segédkezik.

A projekt szempontjából minden kóddá válik és a projekt kódbázisának szerves részét képzi a konfiguráció menedzsment, az infrastruktúrát leíró kód is. Ebben az üzemeltetés támogatást kell nyújtson a fejlesztői csapatoknak és amennyiben lehetséges az üzemeltetés jelenjen meg a projektben rendszeres jelleggel már tervezési feladatok során.

A sikeres együttműködés érdekében, a fejlesztői / üzemeltetői technológiák sztenderdként kell működjenek a szervezetben. Minden érdekelt oldalnak tisztában kell lennie a fejlesztett termék architektúrájával és  a használt fejlesztői, üzemeltetői eszközök alapjaival. Erre remek példa, hogy az üzemeltetés például ellenőrizheti a fejleszők által elkészített infra és konfigurációs menedzsmenttel kapcsolatos kódokat (Chef, Puppet, ARM, scriptek stb.)

Zárásként fontos kiemelni, hogy a DevOps egy folyamat, el kell indulni az úton és folyamatosan beépíteni a tanultakat a folyamatba.

Ha kérdéseid merültek fel a témával kapcsolatban, keress minket bátran, vagy jelentkezz ingyenes konzultációnkra, ahol közösen kitaláljuk, milyen típusú fejlesztés illik leginkább a cégedhez!

2020-09-14T13:41:52+00:002020, szeptember 14, hétfő|Categories: Fejlesztési technológiák, Felhő alapú webes alkalmazás fejlesztés|Cimkék: |