Ha cége még csak a DevOps vagy a CI/CD eszközöket vezeti be, akkor hasznos lehet, ha megismeri a leggyakoribb hibákat, hogy ne ismétlődjenek meg, és ne lépjenek rá valaki másnak.
Csapat lefordította a cikket .
A kultúra és folyamatok megváltoztatására való felkészületlenség
Ha megnézed a ciklikus diagramot , egyértelmű, hogy a DevOps gyakorlatában a tesztelés folyamatos tevékenység, minden egyes telepítés alapvető része.
DevOps végtelen ciklus diagram
A tesztelés és a minőségbiztosítás a fejlesztés és szállítás során a fejlesztők minden tevékenységének elengedhetetlen része. Ehhez gondolkodásmódváltásra van szükség, hogy a tesztelést minden feladatba beépítsük.
A tesztelés minden csapattag napi munkájának részévé válik. Az állandó tesztelésre való átállás nem egyszerű, fel kell rá készülni.
A visszajelzés hiánya
A DevOps hatékonysága az állandó visszajelzésektől függ. A folyamatos fejlesztés lehetetlen, ha nincs tere az együttműködésnek és a kommunikációnak.
Azok a vállalatok, amelyek nem szerveznek visszamenőleges találkozókat, nehezen tudják megvalósítani a folyamatos visszacsatolás kultúráját a CI/CD-ben. Minden iteráció végén retrospektív megbeszéléseket tartanak, amelyek során a csapattagok megbeszélik, mi ment jól és mi rosszul. A retrospektív találkozók a Scrum/Agile alapja, de a DevOps-hoz is szükségesek.
Ennek az az oka, hogy a retrospektív találkozók a visszajelzések és a vélemények cseréjének szokását váltják ki. Az indulásnál az egyik legfontosabb pont az ismétlődő retro találkozók megszervezése, hogy azok érthetőek és ismerősek legyenek az egész csapat számára.
Ami a szoftverminőséget illeti, a csapat minden tagja felelős a karbantartásáért. A fejlesztők például egységteszteket és kódot is írhatnak a tesztelhetőséget szem előtt tartva, ezzel is segítve a kockázat csökkentését a kezdetektől fogva.
Az egyik egyszerű módja annak, hogy tükrözze a teszteléssel kapcsolatos gondolkodásban bekövetkezett változásokat, ha a tesztelőket nem minőségellenőrzőnek, hanem szoftvertesztelőnek vagy minőségügyi mérnöknek hívjuk. Ez a változtatás túl egyszerűnek vagy akár ostobának is tűnhet. De ha valakit "szoftverminőség-biztosítónak" nevezünk, akkor az rossz elképzelést ad arról, hogy ki a felelős a termék minőségéért. Az Agile, CI/CD és DevOps gyakorlatokban mindenki felelős a szoftver minőségéért.
Egy másik fontos szempont, hogy megértsük, mit jelent a minőség az egész csapat és minden egyes tagja, a szervezet és az érintettek számára.
A színpad befejezésének félreértése
Ha a minőség folyamatos és általános folyamat, akkor a szakasz befejezésének közös értelmezése szükséges. Honnan tudod, hogy egy szakasznak vége? Mi történik, ha egy lépést befejezettként jelölnek meg egy Trello vagy más Kanban táblán?
Definition of Done (DoD) egy hatékony eszköz a CD DevOps/CI kontextusában. Segít jobban megérteni a minőségi szabványokat, hogy mit és hogyan épít a csapat.
A fejlesztőcsapatnak el kell döntenie, hogy mit jelent a „Kész” kifejezés. Le kell ülniük, és listát kell készíteniük azokról a jellemzőkről, amelyeknek minden szakaszban meg kell felelniük ahhoz, hogy teljesnek tekintsék.
A DoD átláthatóbbá teszi a folyamatot, és megkönnyíti a CI/CD megvalósítását, ha azt minden csapattag megérti és kölcsönösen megállapodnak benne.
Reális, egyértelműen meghatározott célok hiánya
Ez az egyik leggyakrabban idézett tanács, de érdemes megismételni. Ahhoz, hogy sikeres legyen minden nagyobb erőfeszítés, beleértve a CI/CD-t vagy a DevOps-t, reális célokat kell kitűznie, és a teljesítményt ezekhez képest kell mérnie. Mit akarsz elérni a CI/CD-vel? Lehetővé teszi ez gyorsabb, jobb minőségben történő megjelenést?
A kitűzött céloknak nemcsak átláthatónak és reálisnak kell lenniük, hanem összhangban kell lenniük a vállalat jelenlegi tevékenységével is. Például, milyen gyakran van szüksége ügyfeleinek új javításokra vagy verziókra? Nincs szükség a folyamatok túlterhelésére és a gyorsabb kiadásra, ha ez nem jár további előnyökkel a felhasználók számára.
Ezenkívül nem mindig kell egyszerre CD-t és CI-t megvalósítania. Például a szigorúan szabályozott vállalatok, például bankok és orvosi klinikák csak a CI-vel dolgozhatnak.
A CI jó kiindulópontként szolgál minden DevOps-t megvalósító vállalat számára. Ennek bevezetésekor jelentősen megváltozik a vállalatok szoftverszállítási megközelítése. A CI elsajátítása után gondolkodhat a teljes folyamat javításán, a közzétételi sebesség növelésén és egyéb változtatásokon.
Sok szervezet számára a CI önmagában is elegendő, és a CD-t csak akkor szabad megvalósítani, ha hozzáadott értéket jelent.
A megfelelő műszerfalak és mutatók hiánya
Miután kitűzte a céljait, a fejlesztőcsapat létrehozhat egy irányítópultot a KPI-k mérésére. Kidolgozása előtt érdemes felmérni, hogy milyen paramétereket fognak figyelni.
A különböző jelentések és alkalmazások hasznosak a csapat különböző tagjai számára. A Scrum Mastert jobban érdekli a státusz és az elérés. Míg a felső vezetést a szakemberek kiégési aránya érdekelheti.
Egyes csapatok piros, sárga és zöld jelzésekkel ellátott műszerfalakat is használnak a CI/CD állapotának felmérésére, hogy megértsék, mindent jól csinálnak-e, vagy van-e hiba. A piros azt jelenti, hogy figyelnie kell arra, ami történik.
Ha azonban a műszerfalak nincsenek szabványosítva, félrevezetőek lehetnek. Elemezze, milyen adatokra van szüksége mindenkinek, majd készítsen szabványos leírást arról, hogy mit jelentenek. Fedezze fel, mi értelmesebb az érdekelt felek számára: grafika, szöveg vagy számok.
Nincs manuális teszt
A tesztautomatizálás lefekteti a jó CI/CD folyamat alapjait. Az automatizált tesztelés azonban minden szakaszban nem jelenti azt, hogy ne végezzen manuális tesztelést.
Hatékony CI/CD folyamat létrehozásához manuális tesztekre is szükség van. A tesztelésnek mindig lesznek olyan vonatkozásai, amelyek emberi elemzést igényelnek.
Érdemes megfontolni a kézi tesztelési erőfeszítések integrálását a folyamatba. Miután néhány teszteset manuális tesztelése befejeződött, továbbléphet a telepítési fázisra.
Ne próbálja javítani a teszteket
A hatékony CI/CD folyamathoz hozzáférés szükséges a megfelelő eszközökhöz, legyen szó tesztkezelésről, integrációról és folyamatos felügyeletről.
Erős, minőségorientált kultúra kialakítása a cél , az ügyfelekkel folytatott interakciók figyelése a telepítés után és a fejlesztések nyomon követése.
Íme néhány praktikus tipp, amelyeket könnyen megvalósíthat:
- Győződjön meg róla, hogy a tesztek könnyen írhatók, és elég rugalmasak ahhoz, hogy ne törjenek el a kód átalakítása során.
- A fejlesztői csapatokat be kell vonni a tesztelési folyamatba – tekintse meg a felhasználói problémák és kérések listáját, amelyeket fontos tesztelni a CI folyamat során.
- Előfordulhat, hogy nem rendelkezik teljes tesztlefedettséggel, de mindig győződjön meg arról, hogy az UX és az ügyfélélmény szempontjából fontos folyamatokat tesztelik.
Végül, de nem utolsósorban fontos szempont
A CI/CD-re való áttérés általában alulról felfelé halad, de végső soron ez egy olyan átalakulás, amely vezetői vásárlást, időt és erőforrásokat igényel a vállalattól. Hiszen a CI/CD készségek, folyamatok, eszközök és kulturális átrendeződések összessége, az ilyen változtatásokat csak szisztematikusan lehet végrehajtani.
Mit kell még olvasni a témában:
- .
- .
- .
Forrás: will.com