Lehet, hogy sokan tisztában vagytok az összes kapcsolódó elmélettel . De tudod, hogyan valósítsd meg a DevOps alapelveit a való életben? Ebben a blogban a DevOps valós idejű forgatókönyveit fogom megvitatni, amelyek segítenek egy rövid megértésben a dolgok valós idejű működéséről.
A mutatók, amelyekre kitérekDevOps Real Time Scenarios cikkvannak:
- Mi az a DevOps?
- A DevOps megoldotta problémákat
- CI (folyamatos integráció) forgatókönyvek
- CT (folyamatos tesztelés) forgatókönyvek
- CD (folyamatos szállítás) forgatókönyvek
- DevOps adatforgatókönyvek
Kezdjük tehát az első témánkkal.
Mi az a DevOps?
A DevOps egy szoftverfejlesztési megközelítés, amely magában foglalja a szoftver folyamatos fejlesztését, folyamatos tesztelését, folyamatos integrációját, folyamatos telepítését és folyamatos ellenőrzését a fejlesztés teljes életciklusa alatt. Ezek a tevékenységek csak DevOps-ban lehetségesek, nem agilisak vagy vízesések. Ezért választotta a Facebook és más vezető vállalatok a DevOps-ot üzleti céljaik előremutató útjának.A DevOps-ot elsősorban a magas színvonalú szoftverek rövid fejlesztési ciklusokban történő fejlesztése szempontjából előnyben részesítik, ami nagyobb vevői elégedettséget eredményez.
Ennek következő szakaszábanA DevOps Real Time Scenarios cikkében megnézzük a DevOps által megoldott különféle problémákat.
A DevOps megoldotta problémákat
1. Szállítson értéket az ügyfeleknek
- DevOps minimalizálja az időt ahhoz, hogy értéket teremtsen az ügyfeleknek. A ciklus ideje a történet / feladat fejlesztő általi befejezésétől a gyártásig jelentősen csökken, lehetővé téve az érték lehető leggyorsabb megvalósítását.
A DevOps révén megvalósított legfontosabb érték az, hogy lehetővé teszi az informatikai szervezetek számára az „alapvető” üzleti tevékenységükre összpontosítson . A korlátok eltávolításával az értékáramban és a telepítési folyamatok automatizálásával a csapatok a tevékenységekre koncentrálhatnak. Ez nem csak bitek és bájtok mozgatása, hanem az ügyfelek értékének megteremtését segíti. Ezek a tevékenységek növelik a vállalat fenntartható versenyelőnyét és jobb üzleti eredményeket hoznak létre.
2. Csökkentett ciklusidő
Belsőleg a DevOps az egyetlen módja annak, hogy elsajátítsuk a biztonságos kód betekintéssel történő szállítását. Fontos a kapuk és a jól kidolgozott DevOps folyamat. Amikor új verziót szállít, az az aktuális verzióval együtt futtatható. Összehasonlíthatja a mutatókat is, hogy megvalósítsa a kívánt eredményt az alkalmazás és a teljesítmény mutatóival.
a módszer túlterhelése és a módszer felülírása a java-ban
A DevOps a fejlesztői csapatokat irányítja folyamatos fejlesztés és gyorsabb kioldási ciklusok . Ha jól sikerül, ez az iteratív folyamat lehetővé teszi, hogy az idő múlásával jobban összpontosítson a valóban fontos dolgokra. Például olyan dolgok, amelyek nagyszerű élményeket teremtenek a felhasználók számára - és kevesebb idő jut az eszközök, folyamatok és technológiák kezelésére.
3. A piacra kerülés ideje
A legfontosabb megoldandó probléma a a folyamat bonyolultságának csökkentése. Ez jelentősen hozzájárul üzleti sikerünkhöz azáltal, hogy lerövidíti a piacra kerülési időnket, gyors visszajelzést ad a funkciókról, és jobban reagál az ügyfelek igényeire.
4. Probléma megoldása
A DevOps sikeres megvalósításának legnagyobb értéke a nagyobb bizalom a kézbesítésben, a láthatóság és a folyamat nyomon követhetősége, így gyorsabban megoldhatja a problémákat.
A DevOps másik fontos előnye, hogy nem pazarolja az időt. A szervezet embereinek és erőforrásainak összehangolása gyors telepítést és frissítéseket tesz lehetővé. Ez lehetővé teszi a DevOps programok számára a problémák kijavítását, mielőtt azok katasztrófává válnának.A DevOps létrehozza az átláthatóság kultúráját, amely elősegíti az összpontosítást és az együttműködést a fejlesztési, műveleti és biztonsági csapatok között.
CI (folyamatos integráció)DevOps valós idejű forgatókönyvek
1. Az egyének a folyamatos integrációt kontraproduktívnak tekinthetik
A fejlesztőcsapat tagjai különböző szerepekkel, felelősséggel és prioritásokkal rendelkeznek. Lehetséges, hogy a termékmenedzser elsődleges fontossága új funkciók bevezetése lehet, a projektmenedzsernek meg kell győződnie arról, hogy csapatuk betartja-e a határidőt. A programozók azt gondolhatják, hogy ha megállnak egy kisebb hibát kijavítani minden alkalommal, akkor az lelassítja őket. Úgy érezhetik, hogy az építkezés tisztán tartása extra terhet jelent számukra, és nem lesznek előnyösek extra erőfeszítéseik miatt. Ez potenciálisan veszélyeztetheti az alkalmazkodási folyamatot.
Ennek leküzdésére:
Először is, győződjön meg róla, hogy az egész csapata a fedélzeten van, mielőtt elfogadja a folyamatos integrációt.
A műszaki vezetőknek és a csapatvezetőknek segíteniük kell a csapattagokat a folyamatos integráció költségeinek és előnyeinek megértésében.
Jelölje ki, hogy a kódolóknak milyen előnyök származnak, ha más munkamódszernek szentelik magukat, amely valamivel nagyobb nyitottságot és rugalmasságot igényel.
2. CI integrálása a meglévő fejlesztési folyamatba
A CI elfogadása elkerülhetetlenül szükségessé teszi a fejlesztési munkafolyamat bizonyos részeinek megváltoztatását. Előfordulhat, hogy a fejlesztői nem javítják a munkafolyamatot, ha az nem sérült meg. Ez főleg akkor lehetséges, ha a csapatának nagyobb rutinja van a jelenlegi munkafolyamat végrehajtásában.
Ha módosítani szeretné a munkafolyamatot, akkor azt nagy elővigyázatossággal kell megtennie. Ellenkező esetben ez veszélyeztetheti a fejlesztői csapat termelékenységét és a termék minőségét is. A vezetőség kellő támogatása nélkül a fejlesztőcsapat kissé vonakodik olyan feladatok elvégzésétől, amelyek ilyen kockázatokkal járnak.
Ennek leküzdésére:
Biztosítania kell, hogy elegendő időt biztosítson a csapat számára az új munkafolyamat kialakításához. Ez egy rugalmas, folyamatos integrációs megoldás kiválasztása érdekében történik, amely támogatja az új munkafolyamatot.
Győződjön meg arról is, hogy a vállalatnak van-e hátulja, még akkor is, ha a dolgok az elején nem nagyon mennek zökkenőmentesen.
3. Visszatérés a korábbi tesztelési szokásokhoz
A folyamatos integráció alkalmazásának az azonnali hatása, hogy csapata gyakrabban tesztel. Tehát több teszthez több tesztesetre lesz szükség, és a tesztesetek megírása időigényes lehet. Ezért a fejlesztőknek gyakran el kell osztaniuk idejüket a hibák kijavítása és a tesztesetek írása között.
Ideiglenesen a fejlesztők képesek időt takarítani meg manuális teszteléssel, de ez hosszú távon jobban fájhat. Minél tovább halogatják a tesztesetek írását, annál nehezebb lesz utolérni a fejlesztés előrehaladását. A legrosszabb esetben a csapat visszatérhet a régi tesztelési folyamathoz.
Ennek leküzdésére:
posztgraduálisnak tekintett mesterképzés
Hangsúlyoznia kell, hogy a tesztesetek megírása a kezdetektől fogva sok időt takaríthat meg a csapat számára, és biztosíthatja a termék magas tesztfedettségét.
Illessze be vállalati kultúrájában azt az elképzelést is, miszerint a tesztesetek ugyanolyan értékes eszközök, mint maga a kódbázis.
4. A fejlesztők figyelmen kívül hagyják a hibaüzeneteket
Gyakori probléma, hogy amikor nagyobb csapatok dolgoznak együtt, a CI-értesítések mennyisége elsöprővé válik, és a fejlesztők figyelmen kívül hagyják és elnémítják őket. Ezért lehetséges, hogy hiányolják a számukra releváns frissítéseket.
Olyan szakaszhoz vezethet, amikor a kódolók viszonylagos immunitást alakítanak ki a meghibásodott buildek és hibaüzenetekkel szemben. Minél tovább figyelmen kívül hagyják a vonatkozó értesítéseket, annál tovább fejlődnek rossz irányú visszajelzések nélkül. Ez hatalmas visszahúzódást, pénz, erőforrások és idő pazarlását okozhatja.
Ennek leküzdésére:
Csak kritikus frissítéseket küldhet.
Csak annak a fejlesztőnek küldje el az értesítést, aki a javításáért felelős.
CT (folyamatos tesztelés) ban benDevOps valós idejű forgatókönyvek
A követelmények specifikációjának helyes megszerzése
Ha megfelel a követelményeinek, akkor a csata majdnem fele megnyerhető. Tehát, ha nagyon pontosan és pontosan megértette a követelményeket, akkor jobban megtervezheti a tesztterveket és jól lefedheti a követelményeket.
Mégis, sok csapat sok időt és erőfeszítést fordít egyszerűen a követelmények tisztázására. Ez egy nagyon gyakori buktató, és ennek elkerülése érdekében a csapatok alkalmazhatják a modell-alapú tesztelés és a viselkedés-vezérelt fejlesztési technikákat. Ez segít a teszt forgatókönyvek pontos és megfelelő megtervezésében.
Ezek a gyakorlatok mindenképpen segítenek a hiányosságok gyorsabb orvoslásában és felszámolásában. Emellett lehetővé teszi számukra, hogy több tesztesetet generáljanak automatikusan, már a sprint kezdetétől.
Csővezetés
A folyamatos tesztelés előnyei és folyamatos szállítás szorosan kötődnek a csővezeték hangszereléséhez. Ez közvetlenül azt jelenti, hogy megértsük, hogyan működik, miért működik, hogyan kell elemezni az eredményeket, és hogyan és mikor kell méretezni. Minden a csővezetéktől függ, ezért integrálnia kell a csővezetéket az automatizálási csomaggal.
De a csapatok oka az, hogy egyetlen megoldás sem biztosítja a CD-csővezeték építéséhez szükséges teljes eszközláncot.
A csapatoknak jellemzően a rejtvény megfelelő darabjait kell megkeresniük. Nincsenek tökéletes eszközök, általában csak a legjobbak a legjobb eszközök, amelyek integrációt biztosítanának több más eszközzel együtt. És természetesen egy API, amely egyszerű integrálást is lehetővé tesz.
Röviden, lehetetlen folytatni a folyamatos tesztelést egy szabványosított és automatizált csővezeték sebessége és megbízhatósága nélkül.
A bonyolultság növelése és kezelése
Egy másik fontos forgatókönyv az, hogy a folyamatos tesztelés bonyolultabbá válik, miközben a termelési környezet felé halad. A tesztek száma és bonyolultsága növekszik az érlelő kód és a környezet bonyolultabbá válásával.
A teszteket minden alkalommal frissítenie kell, amikor különböző fázisokat és automatizált parancsfájlokat frissít. Ennek eredményeként a tesztek futtatásához szükséges teljes idő is növekszik a kiadás felé.
Erre a megoldás a továbbfejlesztett teszthangszerelésben rejlik, amely megfelelő mennyiségű tesztet fed le rövidebb sprintciklusokban, és lehetővé teszi a csapatok számára, hogy magabiztosan teljesítsenek. Ideális esetben a teljes folyamatot automatizálni kell, a CT-t különböző szakaszokban kell végrehajtani. Ez házirend-kapuk és kézi beavatkozások segítségével történik, egészen addig, amíg a kódot nem állítják elő a gyártásig.
Visszacsatolási hurkok létrehozása
A fejlesztési ciklus minden szakaszában gyakori visszacsatolási hurok nélkül a folyamatos tesztelés nem lehetséges. Részben ez az oka annak, hogy a CT-t nehéz megvalósítani. Nemcsak automatizált tesztekre van szükség, hanem a teszt eredményeinek és végrehajtásának láthatóságára is.
A hagyományos visszacsatolási hurkok, mint például a naplózási eszközök, a kódprofilosítók és a teljesítményfigyelő eszközök, már nem hatékonyak. Sem nem működnek együtt, sem nem nyújtanak mélyreható betekintést a problémák megoldásához. A valós idejű irányítópultok, amelyek automatikusan jelentéseket generálnak és működőképes visszajelzést adnak az egész SDLC-n keresztül, segítenek a szoftver gyorsabb kiadásában a gyártásban, kisebb hibák nélkül. Az irányítópultokhoz való valós idejű hozzáférés és az összes csapattag hozzáférése elősegíti a folyamatos visszacsatolási mechanizmust.
Környezet hiánya
A folyamatos tesztelés egyszerűen azt jelenti, hogy gyakrabban kell tesztelni, és ehhez több környezetet kell gyakrabban ütni. Ez szűk keresztmetszetet jelent, ha az említett környezetek nem állnak rendelkezésre a szükséges időben. Egyes környezetek API-k, mások pedig különböző interfészek révén érhetők el. Ezen környezetek egy része modern architektúra felhasználásával építhető fel, míg mások monolitikus örökölt kliens / szerver vagy nagygépes rendszerekkel.
De itt az a kérdés, hogy hogyan koordinálja a tesztelést a különféle környezettulajdonosokon keresztül? Az is előfordulhat, hogy nem mindig működtetik a környezetet. A válasz mindezekre az Virtualizáció . A környezet virtualizálásával tesztelheti a kódot anélkül, hogy túl sokat aggódna a változatlan területek miatt.A környezetek hozzáférhetővé és igény szerint elérhetővé tétele a virtualizáció révén biztosan segít eltávolítani a folyamat jelentős szűk keresztmetszetét.
CD (folyamatos szállítás) ban benDevOps valós idejű forgatókönyvek
A telepítések túl sokáig tartanak
Az elosztott alkalmazások általában többet igényelnek, mint a fájlokat a szerverre másolni és beilleszteni. A komplexitás általában növekszik, ha van egy kiszolgálófarmja. A bizonytalanság abban, hogy mit, hol és hogyan telepítsünk, elég normális dolog. Az eredmény? Hosszú várakozási idő, hogy műtárgyaink bekerüljenek az útvonal következő környezetébe, így késleltethetünk mindent, tesztelhetünk, élhetünk stb.
Mit hoz a DevOps az asztalra? A fejlesztési és informatikai műveleti csapatok hibátlan együttműködési munkamenet során határozzák meg a telepítési folyamatot. Először ellenőrzik, hogy mi működik, majd automatizálással a következő szintre emelik a folyamatos szállítás megkönnyítését. Ez drasztikusan csökkenti a bevetés időzítését, és utat nyit a gyakoribb bevetések számára is.
Hiányzó műtermékek, szkriptek és egyéb függőségek
Gyakran találkozunk hibákkal egy működő szoftver új verziójának telepítése után. Ezt gyakran az okozza, hogy a hiányzó könyvtárak vagy adatbázis-szkriptek nem frissülnek. Ennek oka általában az egyértelműség hiánya a telepítendő függőségek és elhelyezkedésük tekintetében. A fejlesztés és a műveletek közötti együttműködés elősegítése az esetek többségében segíthet az ilyen jellegű problémák megoldásában.
Az automatizálás terén meghatározhat függőségeket, amelyek sokat segítenek a telepítések felgyorsításában. Konfigurációkezelő eszközök, mint Báb vagy Fő hozzájáruljon a függőségek meghatározásának egy extra szintjével. Nem csak a függőségeket határozhatjuk meg alkalmazásunkon belül, hanem az infrastruktúra és a szerver konfigurációs szintjén is. Például létrehozhatunk egy virtuális gépet egy teszthez, és telepíthetjük / konfigurálhatjuk kandúr mielőtt leleteink megjelennek.
A gyártás hatástalan ellenőrzése
Néha úgy konfigurálja a felügyeleti eszközöket, hogy sok irreleváns adatot állítson elő a termelésből, máskor azonban nem elég vagy egyáltalán nem állítanak elő. Nincs meghatározva, hogy mire kell vigyáznia és mik a mutatók.
Meg kell állapodnia arról, hogy mit kell figyelnie és mely információkat kell előállítania, majd be kell állítania a vezérlőket. Az alkalmazás teljesítménymenedzsment eszközei nagy segítséget jelentenek, ha szervezete megengedheti magának, hogy vessen egy pillantást az AppDynamics, az New Relic és az AWS X-Ray elemekre.
DevOps adatforgatókönyvek
A DevOps az új szoftverfejlesztéssel járó kockázatok kiküszöböléséről szól: Az adatok elemzése azonosítja ezeket a kockázatokat. A DevOps folyamat folyamatos mérése és fejlesztése érdekében az elemzésnek a teljes folyamaton át kell terjednie. Ez felbecsülhetetlen betekintést nyújt a menedzsmentbe a szoftverfejlesztés életciklusának minden szakaszában.
1. Kevesebb idő az adatok elemzésére
A minden pillanatban előállított összes adattal együtt a szervezeteknek el kell fogadniuk, hogy nem tudják mindezt elemezni. Egyszerűen nincs elég idő a napban - és sajnos a robotok még nem elég kifinomultak ahhoz, hogy mindezt helyettünk teljes egészében elvégezzék.
pl sql bemutató kezdőknek
Ezért fontos meghatározni, hogy mely adatkészletek vannak a legjelentősebbek. A legtöbb esetben ez minden szervezetnél más lesz. Tehát mielőtt belevágna, határozza meg a legfontosabb üzleti célokat és célokat. Ezek a célok általában a vásárlói igények körül forognak - elsősorban azok a legértékesebb szolgáltatások, amelyek a legfontosabbak a végfelhasználók számára. Egy kiskereskedő esetében például a lista tetején van annak elemzése, hogy a forgalom miként hat a webhely fizetési oldalára, és annak működésének tesztelése a háttérben.
Néhány gyors tipp annak elemzéséhez, hogy mely adatok legfontosabbak:
Készítsen diagramot: Határozza meg, hogy a kiesések milyen hatással lesznek a vállalkozására, és tegyen fel olyan kérdéseket, mint például: „Ha X törik , milyen hatással lesz a többi tulajdonságra? '
Nézze meg a korábbi adatokat: Határozza meg, hol merültek fel problémák a múltban, és folytassa a tesztekből származó adatok elemzését, és győződjön meg arról, hogy ez nem fordul elő.
2. Nehéz kommunikáció
Ma a legtöbb szervezet továbbra is különböző csapatokkal és személyekkel működik együtt, azonosítva saját céljaikat, és felhasználva saját eszközeiket és technológiáikat. Minden csapat függetlenül jár el, leválasztva a folyamatról és csak az integrációs szakaszban találkozik más csapatokkal.
Amikor a nagyobb képet kell megvizsgálni és azonosítani, hogy mi működik és mi nem, a szervezet küzd azért, hogy egyetlen megoldást találjon. Ez azért van, mert főleg azért, mert mindenki nem osztja meg az összes adatot, lehetetlenné téve az elemzést.
Ennek a problémának a kiküszöbölése érdekében módosítsa a kommunikáció áramlását annak biztosítása érdekében, hogy mindenki az SDLC-n keresztül együttműködjön, nemcsak az integrációs folyamat során.
Először is győződjön meg arról, hogy erős a szinkronizálás a DevOps mérőszámaival a kezdéstől kezdve. Minden csapat előrehaladását egyetlen irányítópulton kell megjeleníteni, ugyanazokat a kulcs teljesítménymutatókat (KPI) felhasználva, hogy a menedzsment láthassa az egész folyamatot. Ez azért történik, hogy összegyűjthessék az összes szükséges adatot annak elemzéséhez, hogy mi ment rosszul (vagy mi sikerült).
A kezdeti metrikus beszélgetésen túl folyamatos kommunikációnak kell lennie a csapat értekezletein vagy olyan digitális csatornákon keresztül, mint a Slack.
3. Munkaerőhiány
Rövid személyzet esetén intelligensebb eszközökre van szükségünk, amelyek a mély tanulást használják fel az összegyűjtött adatok tárolására és a döntések gyors meghozatalára. Végül is senkinek nincs ideje megvizsgálni az egyes tesztek végrehajtását (és néhány nagy szervezet esetében körülbelül 75 000 lehet egy adott napon). A trükk a zaj megszüntetése és a megfelelő dolgok megtalálása, amelyekre összpontosítani lehet.
Itt segíthet a mesterséges intelligencia és a gépi tanulás. A piacon jelenleg sok eszköz használja az AI-t és az ML-t, például:
Fejlesszen szkripteket és teszteket a különféle adatok mozgatásához és érvényesítéséhez
Jelentés a minőségről a korábban megtanult viselkedés alapján
Dolgozzon a valós idejű változásokra reagálva.
Tehát ezzel a DevOps valós idejű forgatókönyvekről szóló cikk végére értünk.
Most, hogy megértette, mi a DevOps valós idejű forgatókönyv, nézze meg ezt az Edureka, egy megbízható online tanulási vállalat, amelynek több mint 250 000 elégedett tanulóval rendelkező hálózata elterjedt az egész világon. Az Edureka DevOps tanúsító tanfolyam segít a tanulóknak megérteni, mi a DevOps, és szert kell szerezni a különféle DevOps folyamatok és eszközök, például a Báb, a Jenkins, a Nagios, az Ansible, a Chef, a Saltstack és a GIT számára az SDLC több lépésének automatizálásához.
Van egy kérdésünk? Kérjük, említse meg ennek megjegyzés rovatábanDevOps Real Time Scenarios cikkés mi visszatérünk hozzád.