streamalism.org

1. Áttekintés

Ebben a cikkben megismerjük a DevOps alapelveinek és gyakorlatának alapjait. Meglátjuk, hogy ez miért releváns és hasznos a szoftverfejlesztésben. Megértjük azt is, hogyan tudjuk értelmesen átvenni a DevOps alkalmazást, és milyen eszközök állnak rendelkezésünkre ezen az úton.

2. Történelmi kontextus

Nem tudjuk értékelni a DevOps-ot a mai állapotban anélkül, hogy egy kicsit visszatekintenénk a történelembe. A szoftverfejlesztés kezdeti napjait leginkább az úgynevezett vízesési módszertan jellemezte. Ez tulajdonképpen azt jelenti a szoftvereket egymás után fogalmazták meg, tervezték, fejlesztették, tesztelték és terjesztették.

Minden lépés a lehető legrészletesebb volt a visszatérés nagyon költséges volt. Ez valójában azt jelentette, hogy a gondolat és a cselekvés között sokkal hosszabb várakozási idő volt. Ez azonban nem volt olyan probléma, mivel a technológiai helyzet sokkal kevésbé ingatag volt, és a zavarok túlságosan elterjedtek.

Érdekes módon ez a modell nem tartott sokáig. Mivel a technológia üteme megváltozott és a zavarok gyakran bekövetkeztek, a vállalkozások érezni kezdték a hőséget. Szükségük volt gyorsabban tesztelhető új ötletek. Ez gyorsabb változásokat jelentett az üzlet minden területén, beleértve a szoftvereket is.

Ez egy teljesen új világot adott a szoftverfejlesztési módszertanoknak, amelyek lazán láthatók az Agile égisze alatt. Az agilis kiáltvány meghatározza azokat az elveket, amelyeket követni kell szoftverek kis lépésekben, gyorsabb visszacsatolási ciklussal. Számos olyan mozgékony keret létezik, mint a Scrum és a Kanban a gyakorlatban.

3. Mi az DevOps?

Láttuk, hogy a gyorsabb visszajelzéssel történő növekményes fejlesztés napjainkra a szoftverek szállításának sarokkövévé vált. De hogyan érhetjük el ezt? Bár a hagyományos agilis módszerek ésszerű pontra visznek minket, még mindig nem ideális.

Az agilis módszertanok folyamatosan finomítják önmagukat, miközben folyamatosan törekednek a silók feltörésére.

Hagyományosan mindig különböző csapataink voltak, amelyek felelősek a szoftverek fejlesztéséért és szállításáért. Ezek a csapatok gyakran a silókban működtek. Ez gyakorlatilag sokkal hosszabb visszacsatolási ciklussá változik, amire nem vágyunk az agilis módszerekkel.

Tehát nem kell sok okoskodás ahhoz, hogy megértsük, hogy a jól integrált, több funkciót átfogó, agilis csapatok sokkal jobban megfelelnek céljaik megvalósítására. A DevOps az az a gyakorlat, amely ösztönzi a szoftverfejlesztő és az operációs csapatok közötti kommunikációt, együttműködést, integrációt és automatizálást. Ez jobban lehetővé teszi számunkra az inkrementális fejlődés gyorsabb visszajelzéssel történő megvalósítását.

A következő ábra elmagyarázza a DevOps gyakorlásának lehetséges munkafolyamatát:

Miközben később, az oktatóanyagban áttekintjük ezen lépések részleteit, értsük meg a DevOps néhány alapelvét:

• Értékcentrikus megközelítés (a végfelhasználó által megvalósított módon)
• Együttműködési kultúra (hatékony kommunikációval, folyamatokkal és eszközökkel)
• Folyamatok automatizálása (a hatékonyság növelése és a hibák csökkentése érdekében)
• Mérhető eredmények (a célok mérésére)
• Folyamatos visszajelzés (hajlamos a gyors fejlődésre)

4. Hogyan lehet elindítani az utazást?

Míg az elmélet egyértelmű és vonzó, az igazi kihívások a DevOps értelmes gyakorlása. Ahogy eddig összegyűltünk, A DevOps többnyire emberekről szól, nem pedig csapatokról.

Az ilyen csapatok jellemzői a közös célok, a hatékony kommunikáció és a többfunkciós képességek. Mivel ennek a változásnak nagy része kulturális, gyakran lassú és súrlódásmentes.

4.1. Motiváció

Csak azért, mert ott van egy népszerű gyakorlat, nem feltétlenül teszi alkalmassá számunkra. Meg kell értenünk minden váltás motivációját - még inkább, ha váltunk az agilis felé. Ez az hasznos kitűzni az elérni kívánt célok meghatározásával.

A DevOps céljai bármely szervezetben a szervezet ambícióitól, kultúrájától és érettségétől függenek. Íme néhány a DevOps leggyakoribb célja:

• Jobb élmény a végfelhasználók számára
• Gyorsabb idő a piacra kerülésre
• Javított átlagos idő a gyógyulásig

4.2. Örökbefogadás

Ne feledje, hogy a DevOps nem végállapot, hanem folyamatos fejlesztési folyamat a célok elérése érdekében. Ezért a csapatban mindenkinek törekednie kell az akadályok azonosítása és gyors eltávolítása. Íme néhány tevékenység, amely segíthet nekünk az indulásban:

• Tisztán értse meg a gyártási ciklus jelenlegi elképzeléseit
• Gyűjtse össze a nyilvánvaló szűk keresztmetszetek egy részét, és használja a mutatókat a tényszerű döntések meghozatalához
• Fontosabbá kell tenni azokat a szűk keresztmetszeteket, amelyek eltávolításakor a legtöbb értéket adják
• Adjon meg egy iteratív tervet az érték fokozatos megadásához a kiemelt tételeknél
• Kövesse a Develop-Deploy-Measure rövid ciklusait a célok elérése érdekében

5. DevOps gyakorlatok

Számos gyakorlatot kell követni, de az ötletnek semmit sem szabadna használnia arany standardként. Gondosan meg kell vizsgálnunk minden gyakorlatot állapotunk és céljaink hátterében, majd megalapozott döntéseket kell hoznunk. Azonban szinte az összes gyakorlat általában a folyamatok automatizálására összpontosít, amennyire csak lehetséges.

5.1. Agilis tervezés

Az agilis tervezés a gyakorlat rövid lépésenkénti meghatározása. Bár a célnak egyértelműnek kell lennie, nem szükséges előre meghatározni és részletezni a teljes alkalmazást. A kulcs itt az a munka rangsorolása az általa elérhető érték alapján.

Ezután meg kell szakítani rövid, de működő lépések ismétlésével.

5.2. Infrastructure-as-Code (IaC)

Ez a az infrastruktúra kezelésének és kiépítésének gyakorlata géppel olvasható konfigurációs fájlokon keresztül. Ezeket a konfigurációkat egy verziókezelő rendszerben is kezeljük, akárcsak a kódalapunkat. Számos tartományspecifikus nyelv áll rendelkezésre ezen konfigurációs fájlok deklaratív létrehozásához.

5.3. Teszt automatizálás

A szoftveres tesztelés hagyományosan kézi erőfeszítés volt, amelyet gyakran silókban hajtottak végre. Ez nem házasodik össze agilis elvekkel. Ezért elengedhetetlen, hogy megpróbáljuk a szoftvertesztelés automatizálása minden szinten, például egységtesztelés, funkcionális tesztelés, biztonsági tesztelés és teljesítménytesztelés.

5.4. Folyamatos integráció (CI)

A folyamatos integráció a A munkakód gyakori, kisebb lépésekben történő összevonásának gyakorlata egy megosztott adattárhoz. Általában automatizált buildek és ellenőrzések futnak gyakran ezen a megosztott adattáron, hogy a lehető leghamarabb figyelmeztessenek minket a kódtörésekre.

5.5. Folyamatos kézbesítés / telepítés (CD)

A folyamatos szállítás a a szoftver kis lépésekben történő kiadásának gyakorlata, amint az minden ellenőrzésen megfelel. Ezt gyakran a folyamatos integrációval együtt alkalmazzák, és kihasználhatja az automatizált kiadási mechanizmust (a továbbiakban: folyamatos telepítés).

5.6. Folyamatos megfigyelés

A figyelés - talán a DevOps központja - gyorsabb visszacsatolási ciklust tesz lehetővé. Azonosítás a szoftver minden aspektusának, ideértve az infrastruktúrát is, nyomon követéséhez megfelelő mérőszámok létfontosságúak. A megfelelő mutatók, a valós idejű és hatékony elemzéssel párosulva gyorsabban azonosíthatják és megoldhatják a problémákat. Sőt, közvetlenül betekint az agilis tervezésbe.

Ez a lista még korántsem teljes és folyamatosan fejlődik. A DevOps-ot gyakorló csapatok folyamatosan kitalálják a céljaik elérésének jobb módjait. Néhány további megemlítendő gyakorlat a Containerization, a Cloud-Native Development és a Microservices, hogy csak néhányat említsünk.

6. A kereskedelem eszközei

A DevOps-ról egyetlen beszélgetés sem lehet teljes az eszközökről való beszélgetés nélkül. Ez az a terület, ahol az elmúlt években robbanás történt. Lehet, hogy lesz egy új eszköz, mire befejezzük az oktatóanyag elolvasását! Bár ez egyszerre csábító és elsöprő, óvatosságra van szükség.

Nem szabad DevOps utunkat első lépésként az eszközökkel kezdeni. Mi a megfelelő eszközök megtalálása előtt meg kell vizsgálnia és meg kell határoznia céljainkat, embereinket (kultúránkat) és gyakorlatainkat. Ennek tisztázása érdekében nézzük meg, melyek állnak a rendelkezésünkre álló, időnként bevált eszközök között.

6.1. Tervezés

Mint láttuk, az érett DevOps mindig agilis tervezéssel indul. Bár világos a célkitűzés, csak néhány rövid iteráció esetén szükséges prioritást meghatározni és meghatározni a munkát. Ezeknek a korai ismétléseknek a visszajelzései felbecsülhetetlen értékűek a jövő és az egész szoftver kialakításában. Egy hatékony eszköz itt segítene bennünket a folyamat könnyed gyakorlásában.

A Jira az Atlassian által kifejlesztett legkiválóbb kérdéskövető termék. Nagyon sok beépített mozgékony tervezési és felügyeleti eszközzel rendelkezik. Nagyrészt ez egy kereskedelmi termék, amelyet akár helyben futtathatunk, akár tárolt alkalmazásként használhatunk.

6.2. Fejlődés

Az agilis ötlet az, hogy gyorsabban prototípusozzon, és visszajelzést kérjen a tényleges szoftverről. A fejlesztőknek változtatásokat kell végrehajtaniuk, és gyorsabban be kell olvadniuk a szoftver megosztott verziójába. Még fontosabb, hogy a csapattagok közötti kommunikáció folyékony és gyors legyen.

Vizsgáljuk meg a tartomány mindenütt megtalálható eszközeit.

A Git egy elosztott verzióvezérlő rendszer. Meglehetősen népszerű, és számos hosztolt szolgáltatás kínál git-tárházakat és hozzáadott értékű funkciókat. Eredetileg Linus Torvalds fejlesztette ki, így a szoftverfejlesztők közötti együttműködés meglehetősen kényelmessé válik.

A Confluence az Atlassian által kifejlesztett együttműködési eszköz. Az együttműködés minden agilis csapat sikere. Az együttműködés tényleges szemantikája meglehetősen kontextuális, de ennek ellenére felbecsülhetetlen egy olyan eszköz, amely zökkenőmentes erőfeszítést tesz. A összefolyás pontosan illeszkedik erre a helyre. Sőt, jól integrálódik Jirával!

A Slack az azonnali üzenetküldő platform, amelyet a Slack Technologies fejlesztett ki. Ahogy megbeszéltük, mozgékony a csapatoknak képesnek kell lenniük az együttműködésre és a kommunikációra, lehetőleg valós időben. Az azonnali üzenetküldés mellett a Slack számos módot kínál a kommunikációra egyetlen felhasználóval vagy felhasználók csoportjával - és jól integrálható más eszközökkel, például a Jira és a GitHub!

6.3. Integráció

A fejlesztők által egyesített változtatásokat folyamatosan ellenőrizni kell a megfelelés szempontjából. Ami megfelelést jelent, az a csapatra és az alkalmazásra jellemző. Mindazonáltal a statikus és dinamikus kódelemzés, valamint a funkcionális és nem funkcionális metrikus mérések a megfelelés összetevőinek tekinthetők.

Nézzünk meg röviden néhány népszerű integrációs eszközt.

A Jenkins egy vonzó, nyílt forráskódú és ingyenes automatizálási szerver. Évek óta az iparban van, és elég érett ahhoz, hogy az automatizálási használati esetek széles spektrumát kiszolgálja. Deklaratív módon kínál egy automatizálási rutint, és számos módot kínál arra, hogy automatikusan vagy manuálisan kiváltsa. Ráadásul gazdag pluginekkel rendelkezik, amelyek számos további funkcióval szolgálnak az erőteljes automatizálási csővezetékek létrehozásához.

A SonarQube egy nyílt forráskódú, folyamatos ellenőrzési platform, amelyet a SonarSource fejlesztett ki. A SonarQube számos statikus elemzési szabálykészlettel rendelkezik számos programozási nyelv számára. Ez segít a kódszagok mielőbbi észlelésében. Ezenkívül a SonarQube olyan irányítópultot kínál, amely integrálhat más mutatókat, például a kód lefedettségét, a kód összetettségét és még sok mást. És jól működik a Jenkins Serverrel.

6.4. Szállítás

Fontos a változások és az új funkciók gyors átadása a szoftverekben. Amint megállapítottuk, hogy az adattárban egyesített változások megfelelnek szabványainknak és irányelveinknek, képesnek kell lenniünk arra, hogy gyorsan eljuttassuk a végfelhasználókhoz. Ez segít visszajelzések gyűjtésében és a szoftver jobb formálásában.

Számos olyan eszköz létezik itt, amelyek segíthetnek a kézbesítés egyes aspektusainak automatizálásában addig a pontig, ahol elérjük a folyamatos telepítést.

A Docker elterjedt eszköz bármilyen típusú alkalmazás gyors tárolásához. Az operációs rendszer szintű virtualizációt használja a szoftverek elkülönítésére a tárolóknak nevezett csomagokban. Konténerezés azonnali előnye van a megbízhatóbb szoftverkézbesítés szempontjából. A Docker Containers jól meghatározott csatornákon keresztül beszél egymással. Sőt, ez meglehetősen könnyű az izoláció más módjaihoz, például a Virtuális gépekhez képest.

A Chef / Báb / Ansible konfigurációkezelő eszköz. Mint tudjuk, egy szoftveralkalmazás tényleges futó példánya a kódbázis felépítésének és konfigurációinak kombinációja. És bár a kódbázis összeállítása változhatatlan a környezetekben, a konfigurációk nem. Ez az, ahol Konfigurációkezelő eszközre van szükségünk alkalmazásunk egyszerű és gyors telepítéséhez. Számos népszerű eszköz található ezen a téren, mindegyiknek megvannak a furcsaságai, de a Chef, a Báb és az Ansible nagyjából lefedi az alapokat.

A HashiCorp Terraform segíthet nekünk az infrastruktúra kiépítésében, amely a magán adatközpontok napja óta unalmas és időigényes feladat. De az egyre szélesebb körű felhő alkalmazásával az infrastruktúrát gyakran eldobható és megismételhető konstrukciónak tekintik. Ez azonban csak akkor érhető el, ha megvan egy eszköz, amellyel deklaratív módon meghatározhatjuk az egyszerű és a komplex infrastruktúrát, és egy gombnyomással létrehozhatjuk. Lehet, hogy álomszekvenciának hangzik, de a Terraform aktívan megpróbálja áthidalni ezt a szakadékot!

6.5. Monitoring

Végül elengedhetetlen, hogy megfigyelhessük a bevetést és mérni tudjuk a célokhoz képest. Számos mérőszám létezhet, amelyeket a rendszerektől és az alkalmazásoktól gyűjthetünk. Ezek tartalmazzák az alkalmazásunkra jellemző üzleti mutatókat.

Az ötlet itt az, hogy szinte valós időben képesek legyünk gyűjteni, kurátort készíteni, tárolni és elemezni ezeket a mutatókat. Számos új, nyílt forráskódú és kereskedelmi termék is elérhető ezen a téren.

Az Elastic-Logstash-Kibana (ELK) három nyílt forráskódú projekt halmaza - Elasticsearch, Logstash és Kibana. Az Elasticsearch egy nagyon skálázható keresési és elemzési motor. A Logstash egy szerveroldali adatfeldolgozási folyamatot kínál számunkra, amely sokféle forrásból származó adatok felhasználására képes. Végül, a Kibana segít ezen adatok vizualizálásában. Ez a verem együtt lehet az összes alkalmazás adatainak, például az összes alkalmazás naplóinak összesítésére és valós idejű elemzésére használják.

A Prometheus egy nyílt forráskódú rendszerfigyelő és riasztó eszköz eredetileg a SoundCloud fejlesztette ki. Többdimenziós adatmodell, rugalmas lekérdezési nyelv jön hozzá, és idősoros adatokat képes HTTP-n keresztül továbbítani. A Grafana egy másik nyílt forráskódú elemzési és felügyeleti megoldás amely több adatbázissal működik. Prométheusz és Grafana együtt képes adj valós idejű kezelést nagyjából minden olyan mutatóról, amelyet rendszereink képesek előállítani.

7. DevOps kiterjesztések (vagy tényleg!)

Láttuk, hogy a DevOp alapvetően folyamatos erőfeszítéseket tesz a szoftverek gyorsabb és iteratív, értékalapú kézbesítésével kapcsolatos akadályok felszámolására. Az egyik azonnali következtetés az, hogy itt nem lehet végállapot.

Amit az emberek a fejlesztési és az operációs csapatok közötti súrlódásként értek el, az nem az egyetlen súrlódás. A silók lebontása a szervezeten belül az együttműködés fokozása érdekében a központi gondolat. Az emberek hamarosan rájöttek erre hasonló súrlódások vannak a fejlesztői és tesztelő csapatok, valamint a fejlesztési és biztonsági csapatok között. Számos hagyományos rendszerben külön biztonsági és teljesítménycsoportok működnek.

A DevOps teljes potenciálja soha nem valósulhat meg, amíg nem tudjuk megszakítani a csapatok közötti szinte minden határt és segíteni őket sokkal hatékonyabb együttműködésben. Ez eredendően azt jelenti, hogy a csapatok, mint például a tesztelés, a biztonság és a teljesítmény, a csapatba kerülnek.

Az összetévesztés nagyrészt nómenklatúrájában rejlik. A DevOps megérteti velünk, hogy leginkább fejlesztési és üzemeltetési csapatokról van szó. Ezért az idők folyamán új feltételek jelentek meg, amelyek magukban foglalják a többi csapatot. De nagyrészt csak a DevOps valósul meg hatékonyabban!

7.1. DevTestOps

A DevOps sarokköve az kiváló minőségű szoftverek szállítása kis lépésekben és gyakrabban. A minőség hangsúlyozásának itt számos szempontja van. Bizonyos értelemben gyakran feltételezzük, hogy az általunk alkalmazott DevOps gyakorlatok segítenek ennek elérésében. És az is igaz, hogy a korábban tárgyalt gyakorlatok közül sok mindenekelőtt a magas minőség biztosítására összpontosít.

De a szoftverek funkcionális tesztelése sokkal szélesebb körű. Gyakran hajlamosak vagyunk megtartani a magasabb rendű tesztelést, például a végpontok közötti tesztelést a szoftver szállításának vége felé. Ennél is fontosabb, hogy ez gyakran egy külön csapat feladata, amely későn vesz részt a folyamatban. Itt kezdenek eltérni a dolgok a DevOps elvektől.

Amit inkább tennünk kellene, az az, hogy a kezdetektől fogva integrálja a szoftvertesztelést minden szinten. A tervezés tesztelésétől kezdve a szoftver tesztelését a szállítás szerves részének kell tekinteni. Ezenkívül ugyanannak a csapatnak kell felelnie a szoftver fejlesztéséért és teszteléséért. Ez a DevTestOps gyakorlata széles körben ismert. Ezt gyakran folyamatos tesztelésnek és balra tolásnak is nevezik.

7.2. DevSecOps

A biztonság minden szoftverfejlesztés szerves része, és bonyolult. Ez gyakran azt jelenti, hogy külön biztonsági szakembercsoportunk van, akikkel azonnal kapcsolatba lépünk, amikor készen állunk a termék szállítására. Az ebben a szakaszban azonosított sebezhetőségek kijavítása költséges lehet. Ez megint nem felel meg jól a DevOps elveinek.

Ekkorra már meg kell találnunk az alkalmazandó megoldást, és ez nekünk is meg kell a játék elején hozza fel a biztonsági aggályokat és a személyzetet. Motiválnunk kell a csapatokat, hogy minden szakaszban gondolkodjanak a biztonságról. A biztonság kétségkívül nagyon specializált terület, ezért szükségünk lehet egy szakember bevonására a csapatba. De az az ötlet, hogy a kezdetektől fogva vegyük figyelembe a legjobb gyakorlatokat.

Ahogy haladunk, vannak számos rendelkezésre álló eszköz, amely automatizálhatja a sebezhetőségek zömének vizsgálatát. Ezt a folyamatos integrációs ciklusokba is bekapcsolhatjuk, hogy gyors visszajelzést kapjunk! Most nem integrálhatunk mindent a folyamatos integrációba, mivel ezt könnyűnek kell tartanunk, de mindig lehetnek más, periodikus vizsgálatok külön-külön.

8. Következtetés

Ebben a cikkben áttekintettük a DevOps alapelveit, gyakorlatait és a használható eszközöket. Megértettük azt a kontextust, ahol a DevOps releváns, és azokat az okokat, amelyek számunkra hasznosak lehetnek. Röviden megbeszéltük azt is, hogy hol kezdjük a DevOps bevezetésének útját.

Ezenkívül megérintettünk néhány népszerű gyakorlatot és eszközt, amelyet ebben az utazásban használhatunk. Megértettünk néhány más népszerű kifejezést is a DevOps körül, például a DevTestOps és a DevSecOps.

Végül meg kell értenünk, hogy a DevOps nem egy végállapot, hanem egy olyan utazás, amely soha nem fejeződik be! De a szórakoztató rész itt maga az utazás. Mindeközben soha nem szabad szem elől tévesztenünk céljainkat, és a legfontosabb elvekre kell összpontosítanunk. Könnyen belecsöppenhet egy népszerű eszköz vagy kifejezés fényébe az iparban. De mindig emlékeznünk kell arra, hogy bármi csak akkor hasznos, ha segít abban, hogy hatékonyabban hozzunk értéket közönségünk számára.