8 legfontosabb kihívás a DevOps elfogadásában: 2. rész - Megoldások

A két részből álló blog sorozat első részében (itt) áttekintettem a 8 legfontosabb kihívást, amelyekkel a szervezetek szembesülnek, amikor a DevOps-ot bevezetik. Nézzük meg néhány megoldást.

A változás a legnehezebb az elején, a legrosszabb a közepén és a legjobb a végén. - Robin S. Sharma

1.Kulturális funkció készítése a DevOps alapelvei szerint

A DevOps vezetõinek és a változásközvetítõknek meg kell találniuk a módszereket a szervezeten belüli csapatok és emberek folyamatos oktatására arról, hogy a DevOps kultúrája hogyan néz ki, és miért gyorsítja az értékáramlást. Néhány dolog, amit kipróbáltam, működött:

Tanulás és gyakorlati közösségek

A DevOps munkatársai belső képzéseket vagy bevezető prezentációkat szervezhetnek a DevOps elfogadására és a DevOps kultúrájának bemutatására. Ily módon előmozdíthatják és szembeszélgethetnek a szervezet minden tagjával. A személyes együttműködést előnyben részesítik az e-mail vagy a videokonferencia használata helyett, mivel az emberek ilyen módon gyorsabban építik a bizalmat, ezért javasolt egy útmutatót megtenni, ha a csapatok szétszórtak, és célja, hogy legalább mindenkivel megismerkedjenek a kapcsolatok kiépítése érdekében.

A DevOps Tudásbázis és GYIK

A DevOps csapatok létrehozhatnak tudásbázist vagy Gyakran Ismételt Kérdéseket (GYIK), és megoszthatják azokat a szervezet minden tagjával, így mindenki tudja, hol lehet információt szerezni a DevOps-hoz kapcsolódóan, ahol szükség van rá. Az információk láthatósága és könnyű elérhetősége motiválja őket arra, hogy maguk keressék és olvassa el, sőt hozzájáruljanak. Ez a fajta információ olyan együttműködési platformon tárolható, mint például az Atlassian Confluence vagy a Microsoft Teams.

A Westrum Szervezet kulturális gyakorlatainak alkalmazása

Használhatjuk a Westrum Szervezet kulturális gyakorlatát egy olyan generációs kultúra előállításához, amely átalakítja az adatfolyamot és a bizalmat, a Westrum hierarchikus kultúra modelljének hat részét vizsgálva, összpontosítva a generációs kultúrában talált gyakorlatokra;

Itt lehet felépíteni egy generációs kultúrát;

2.A változásokkal szembeni ellenállás címe

A vezetőknek elvárniuk kell, hogy az emberek ellenálljanak a változásoknak. A DevOpsologist, Philippa Hale szerint az érintettek feltérképezési eszközeiről szóló cikkében megvitatta, hogy miként kezelhetjük bizonyos csoport emberek hangulatait és érzelmeit a változások felé, akkor különféle elkötelezettségi stratégiákat alkalmazhatunk a DevOps kezdeményezéseihez való megközelítésükhöz. Jelenleg 6 „viselkedési profil” található, és hogyan tudunk velük kapcsolatba lépni, az alábbiak szerint;

kívül lévő

nézők

A cinikusok

A kritikusok

A rajongók

Támogatja (Champions / szakértők)

Összefoglalva a fentiek alapján, láthatjuk az összes elkötelezettség megközelítést, amely magában foglalja a kommunikációt, és tájékozódhatunk a DevOps elfogadásáról. Szorosan együtt kell működnünk az összes csoporttal, és láthatónak kell lennünk számukra, és segítséget kell adnunk, amikor csak szükségük van rá.

3.A világosság megteremtése a DevOps Vision-ban

A DevOps CALMS keretének bemutatása segíthet meghatározni a DevOps ütemtervet és célokat. A CALMS a fejlesztési és működési (DevOps) csapatok, funkciók és rendszerek integrációjának fogalmi kerete egy szervezeten belül.

A DevOps vezetõinek egyértelmû útitervet kell kidolgozniuk a DevOps fejlõdéséhez, egyértelmû fejlesztési szakaszokkal. Meg kell osztaniuk, és a szervezeten belül mindenki számára láthatóvá kell tenni;

4.Csapatközi együttműködés létrehozása

A fejlesztési és informatikai üzemeltetési csapatoknak meg kell tanulniuk az együttműködést. Ez jelentheti a többfunkciós csoport létrehozását, beleértve a fejlesztõket és az operatívumokat is, de ez sok szervezetben nem mûködik. Gyakran túlságosan drámai szervezeti változás, vagy egyszerűen nincs elég ember, hogy körüljárjon. A hagyományos technológiai osztályok felépítése általában magában foglalja a mélyreható tárgyi ismereteket például a biztonság és a hálózatépítés körüli informatikai műveletekben, így nehéz megérteni, hogyan lehet megosztani az ilyen típusú embereket a fejlesztési vagy termékcsoportok között.

Miben segít az, ha mind a fejlesztési, mind az informatikai műveleti csapatok rendszeresen találkoznak? Ha a fejlesztői csapatok az agilis gyakorlataik részeként napi ellenőrzéseket végeznek, akkor az informatikai műveletek meghívása segíthet az akadályok megszüntetésében. Meghívva őket sprinttervezésre, biztosítható, hogy ezeket a nem funkcionális követelményeket figyelembe vegyék a sprintben, ezáltal racionalizálva az értékátadási folyamatot.

Csapatközi kommunikációs eszközök, például a Slack vagy a Microsoft Teams, itt valóban segítenek, mivel lehetővé teszik az együttműködés folyamatosságát. A „Riasztás / értesítés” csevegőcsoportot vagy csatornát szintén megfelelő módon kell kezelni, hogy a kérdéseket a megfelelő csapathoz lehessen irányítani, és a probléma / hiba megoldásához szükséges megfelelő intézkedésekkel gyorsan eskalálódhassanak.

Íme néhány együttműködési eszköz, amelyet használhat, és megkezdheti az együttműködést a szervezeten belül;

5.A környezetek szabványosítása

A környezet olyan erőforrások vagy célzott helyek gyűjteménye, amelyeket a csővezetéken keresztül kódból valódi termékké kíván konvertálni. A környezet magában foglalhatja virtuális gépeket (VM), adatbázis-kiszolgálókat, harmadik fél szolgáltatásait stb. Az alábbiakban egy példa található a környezeti szakaszokra annak felhasználásával, felhasználó / személyiségével és a környezet fenntartásáért felelős személyekkel;

A jól körülhatárolt környezet előnyei a következők;

  1. Telepítési rekord / előzmények - A csővezeték futtatásának minden részletét az erőforrások CI / CD eszközében rögzítik.
  2. Nyomonkövethetőség - lehetővé teszi annak nyomon követését, hogy a kódváltozás (átadás) vagy a szolgáltatás / hibajavítás (munkaelemek) elérték-e a környezetet.
  3. Engedély / ellenőrzés - biztonságos környezet, megadva, hogy mely felhasználó megengedett, és melyik célkörnyezetet telepítse.

Az automatizált környezet biztosítása a siker egyik fő tényezője a folyamatos szállítási folyamatban. Igényelhet-e az Dev-csoport új környezetet ad-hoc módon, és az Ön környezetét igény szerint biztosítják-e az alkalmazás telepítésekor? Az alkalmazás környezete három fő területre osztható:

1. Infrastruktúra

2. Konfiguráció

3. Függőségek

Az infrastruktúra az a hely, ahol az alkalmazást vagy szolgáltatást telepítik, és az alkalmazás speciális konfigurációs igényeket futtat. Ez magában foglalja azt is, hogyan kell a függőségeket integrálni az alkalmazásba. Manapság az infrastruktúrát szkript segítségével lehet biztosítani, vagy „Infrastruktúra mint kód” -nak, vagy röviden IaC-nak hívják. Az IaC manapság könnyebben elérhetővé válik a teljes környezetvédelmi folyamat automatizálására rendelkezésre álló eszközök átfogó köre révén.

A konfiguráció az alkalmazás környezetének legkövetkezõbb következménye. A konfiguráció diktálja, hogy az alkalmazás hogyan exportál egy adott infrastruktúrában, és hogy az infrastruktúra hogyan alakul ki az alapul szolgáló alkalmazás megismerésében.

A függőségek mind azok a modulok vagy rendszerek, amelyektől egy alkalmazás függ, a könyvtáraktól a szolgáltatásokig vagy más alkalmazásokig.

Az automatizált környezetvédelmi szolgáltatás előnye az alábbiak szerint:

  • Csökkentette a bonyolultságot azáltal, hogy lehetővé teszi a DevOps csapatok számára, hogy magasabb szintű absztrakción dolgozzanak.
  • Megnövelt stabilitás azáltal, hogy lehetővé teszi az alkalmazások számára, hogy dinamikusan reagáljanak telepítésükre.
  • Megnövelt rugalmasság a konfigurációkezelés és az alkalmazás speciális tárhelyi környezetének leválasztása révén.

Számos eszköz áll rendelkezésre a piacon, függetlenül attól, hogy nyílt forráskódú vagy vállalati -, amelyek segítségével automatizálhatjuk a szolgáltatást az összes fent említett 3 területre, az alábbiakban;

6.A DevOps Toolchain szabványosítása és önkiszolgálás biztosítása

Miután a DevOps elfogadási célok és folyamatok meg vannak határozva, meghatározhatjuk a folyamatok teljesítéséhez szükséges eszközkészletet. Győződjön meg arról, hogy a fejlesztési és az informatikai üzemeltetési csapatok együtt dolgoznak a szervezet számára megfelelő eszközök eldöntésében. Bármely új bevezetett eszközzel a meglévő dolgozókat ki kell képezni. Szintén elengedhetetlen annak biztosítása, hogy az eszközök megfeleljenek a biztonsági követelményeknek, és jól integrálódjanak a meglévő erőforrásokhoz és szolgáltatásokhoz.

** Csak nevezze meg a piacon elérhető néhány eszközláncot a fenti szakaszokhoz.

7. A kiadáskezelés felgyorsítása

Miután helyesen meghatároztuk a környezetünket, a DevOps vezetőknek létre kell hozniuk egy megfelelő kiadási csővezetéket, amelyre akkor van szükség, ha automatikus indításra van szükségünk a telepítéshez, amikor szükség van a telepítés előtti jóváhagyási kapura és amikor a minőségbiztosítási / tesztelési szakaszot kell elhelyezni. Az alábbi kép egy alapkioldó csővezetéket mutat be, kombinált automatikus és kézi üzembe helyezéssel;

Ha van megfelelő kiadási csővezetéke, az építési, integrációs, tesztelési, szállítási és egyéb folyamatok automatizálása, ez csökkenti az emberi tevékenységeket minden kiadás során, valamint a szükséges menedzsment és koordinációt.

Mivel a fejlesztésgyorsítás versenyelőnyré vált, a DevOps csapata megpróbálta lehetővé tenni a folyamatos integrációt és a folyamatos disztribúciót (CI / CD). A CI / CD segít a fejlesztőknek és az informatikai műveleteknek a szoftverfejlesztési és tesztelési folyamat hatalmas nehézségeinek leküzdésében. Az évek során a szoftverfejlesztés a vállalati szintről, ahol széles források állnak rendelkezésre, átállt a kisebb fejlesztőcsoportokra, amelyek versenyezni tudnak lépésekkel az okostelefonok milliárdjaiból, valamint más mobil fogyasztói eszközökből és platformokból. Az alábbiakban bemutatunk egy példát a CI / CD csővezetékről a rendelkezésre álló szerszámlánc kombinációval;

Esetünkben az eszközök kombinációját választjuk, mivel úgy tűnik, hogy a legjobb megoldást nyújtja bonyolult igényeinkhez. A legtöbb vállalati termékeket fejlesztő csapat részesülne egy ilyen, a földről felépített megközelítésből. Szerszámlánc-veremünk a következőkből áll:

  1. Atlassian JIRA - eszköz a csapat-együttműködéshez a termékmaradékból, a Sprint tervezésből és a kiadási jelentésekből, valamint az Agile csapat teljesítményéről az egyes sprintjeken.
  2. Github - elosztott verziókezelő rendszer (DVCS), ahol a fejlesztő kommunikál egymással, és együttműködik annak érdekében, hogy a termék jellemzői kódja jobb legyen, és a változások és a kód verziók jobban átláthatók legyenek. Az esetleges változásokat más fejlesztõknek vagy a Kódvizsgálónak felül kell vizsgálnia, amelyek tisztábbá tették a kódot és kevesebb hibát / hibát okoztak.
  3. Azure DevOps - ez egy eszköz, amelyet a CI / CD-csővezeték összehangolására használunk, és ezenkívül a DevOps Engineer, a fejlesztő, a kiadáskezelő és a minőségbiztosítási csapat közötti további együttműködés. Ez az a hely, ahol az integráció történik egy jó minőségű termék szállítása érdekében, ezért van biztonsági elemzés és minőségbiztosítási tesztelés, mielőtt telepítjük a termelési környezetbe.
  4. Datadog - Ez egy megfigyelő eszköz, amely a Datadog használatával megfigyelheti kiszolgálóit, felhőit, metrikáit, alkalmazásait és csapatait. Olyan, mint egyablakos mindenféle monitor, a környezet és a termékek számára.

A hatékony CI / CD-csővezeték jelentősen javíthatja a forgalomba hozatalhoz szükséges időt és fenntarthatja a szoftver stabilitását és minőségét.

8. A tesztelés automatizálása

A DevOps elősegíti az automatizálást, és célja, hogy az emberi beavatkozást nem igénylő mindennapi feladatok minél több automatizálását elvégezze. A minőségbiztosítási szakértők bevonása a DevOps csapat összetételébe elősegíti a csapat döntését a legjobb megközelítésről, vagy a tesztelési eszközök automatizálhatók. Az automatizálási eszközök általában az alkalmazás- vagy rendszerhibák tesztelésekor működnek, de a minőségbiztosítási tesztelés sokkal jobb feladatot jelent a használhatóság és a kiadási készség tesztelésében.

Az automatizált folyamatos tesztelés integrálása a CI / CD-csővezetékbe olyan alkalmazástesztelő eszközt igényel, amelyet könnyű integrálni a már használt építési, teszt-automatizálási és CI / CD-eszközökkel, és kiterjedt webes API-támogatással rendelkezik. Az automatizált folyamatos tesztelés előnye az alábbiak szerint:

Stabilitás. Segít a minőség- és biztonsági követelmények következetesebb alkalmazásában. Ha rögzít egy kézi biztonsági tesztet, majd azt automatizálja, akkor ez olyan biztonsági követelménnyé válik, amelyet minden építkezésnél érvényesíteni lehet.

Sebesség. A skálázható eszközök által biztosított automatikus folyamatos teszteléssel a fejlesztők valódi időben megtalálhatják és finomíthatják a kérdéseket az SDLC-ben. Ezzel felgyorsítja az alkalmazásfejlesztést és elkerüli a kézi tesztelés során gyakori hibákat.

Skála. A kézi tesztelés méretének növeléséhez több kézi tesztelőre van szüksége. Az automatizált tesztelés méretezéséhez több alkalmazásra és verzióra van szükség a teszteléshez.

Következtetés

A DevOps Adoption egy olyan út, amelynek a szervezet felépítésének és céljainak elemzésével kell kezdődnie. E közös kihívások megoldása a DevOps Adoption segítségével az átalakulás sokkal simábbá válik. Egy adott időszak alatt a szervezet minden csapata vagy személy megszokja a DevOps változásait és alkalmazkodik a folyamatos tanulási folyamatokhoz. Miután a fejlesztési, üzemeltetési és menedzsment csapatok megtanulják az együttműködést, automatikusan segítenek egymásnak, és szorosan együttműködnek a DevOps Adoption céljainak archiválásában.