Ha a cége éppen most vezeti be a DevOps-t vagy a CI/CD eszközöket, hasznos lehet megismerkedni a leggyakoribb hibákkal, hogy elkerülhesse őket, és ne lépjen el mások nyomába.
A parancs fordította a cikket .
A kultúra és a folyamatok változására való felkészületlenség
Ha megnézzük a ciklikus diagramot , láthatjuk, hogy a DevOps gyakorlatokban a tesztelés folyamatos munka, amely minden egyes telepítés alapvető részét képezi.
A DevOps végtelen ciklikus diagramja
A tesztelés és a minőségbiztosítás a fejlesztés és a szállítás folyamatában elengedhetetlen része mindannak, amit a fejlesztők végeznek. Ez gondolkodásmódbeli változást igényel, hogy a tesztelést minden feladatba beépítsük.
A tesztelés a csapat minden tagjának mindennapi munkájának részévé válik. Az állandó tesztelésre való áttérés nem könnyű, készen kell állni rá.
Visszajelzés hiánya
A DevOps hatékonysága a folyamatos visszajelzésen múlik. A folyamatos fejlesztés lehetetlen, ha nincs hely az együttműködésre és a kommunikációra.
A cégek, amelyek nem szerveznek retrospektív találkozókat, nehezen tudják bevezetni a folyamatos visszajelzés kultúráját a CI/CD-ben. A retrospektív találkozókat minden iteráció végén tartják, ahol a csapat tagjai megvitatják, mi ment jól és mi nem. A retrospektív találkozók a Scrum/Agile alapja, de a DevOps esetében is szükségesek.
Ez azért van, mert a retrospektív találkozók elősegítik a visszajelzés és vélemények cseréjének szokását. Az egyik legfontosabb dolog a kezdetekkor a visszatérő retro-találkozók szervezése, hogy ezek érthetőek és szokásosak legyenek az egész csapat számára.
Amikor a szoftver minőségéről van szó, a csapat minden tagjának felelőssége annak fenntartása. Például a fejlesztők moduláris teszteket írhatnak, valamint a tesztelhetőséget szem előtt tartva írhatják a kódot, segítve ezzel a kockázatok csökkentését már a kezdetektől.
Az egyik egyszerű módja a tesztelésre vonatkozó elképzelések változásának tükrözésére az, hogy a tesztelőket nem QA-nak, hanem szoftvertesztelőknek vagy minőségbiztosítási mérnököknek nevezzük. Ez a változás talán túl egyszerűnek vagy akár butának tűnik. De ha valakit "szoftverminőség-biztosítási szakértőnek" hívnak, az félrevezető képet ad arról, hogy ki felelős a termék minőségéért. Az Agile, CI/CD és DevOps gyakorlatokban mindenkinek felelőssége van a szoftver minősége.
Egy másik fontos szempont megérteni, hogy mit jelent a minőség az egész csapat és annak minden tagja, a szervezet és az érdekelt felek számára.
A szakasz befejezésének helytelen megértése
Ha a minőség egy folyamatos és közös folyamat, akkor közös megértés szükséges a szakasz befejezéséről. Hogyan lehet megérteni, hogy egy szakasz befejeződött? Mi történik, amikor a szakasz befejezettként van megjelölve a Trello táblán vagy bármely más Kanban táblán?
A befejezett szakasz definíciója (DoD) erőteljes eszköz a CD DevOps/CI kontextusában. Segít jobban megérteni a csapat által épített dolgok minőségi szabványait.
A fejlesztőcsapatnak meg kell határoznia, hogy mit jelent a "Kész". Le kell ülniük és össze kell állítaniuk egy listát azokról a jellemzőkről, amelyeknek teljesülniük kell minden szakaszban ahhoz, hogy azt befejezettnek lehessen tekinteni.
A DoD átláthatóbbá teszi a folyamatot és megkönnyíti a CI/CD bevezetését, ha minden csapattag számára világos és kölcsönösen elfogadott.
A reális, jól meghatározott célok hiánya
Ez az egyik leggyakrabban idézett tanács, de érdemes megismételni. Bármilyen komoly kezdeményezés, beleértve a CI/CD vagy DevOps bevezetését, sikeréhez valós célokat kell kitűzni, és azokat mérni szükséges. Mit próbál elérni a CI/CD-val? Gyorsabban szeretné kiadni a verziókat, jobb minőséggel?
A kitűzött céloknak nemcsak átláthatóknak és reálisnak, hanem a vállalat jelenlegi tevékenységeinek is meg kell felelniük. 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 kiadások felgyorsítására, ha ez nem jár plusz előnyökkel a felhasználók számára.
Ezen kívül nem mindig szükséges a CD és a CI egyidejű megvalósítása. Például olyan szigorúan szabályozott vállalatok, mint a bankok és egészségügyi klinikák, csak a CI-t alkalmazhatják.
A CI jó kiindulópontot nyújt minden olyan cég számára, amely a DevOps bevezetésén dolgozik. A CI bevezetésével drámai változások következnek be a szoftverek szállítási megközelítéseiben. Miután elsajátították a CI-t, érdemes elgondolkodni a folyamat javításán, a kibocsátási sebesség növelésén és más változtatásokon.
Sok szervezet számára elegendő egy CI, és a CD-t csak akkor kell megvalósítani, ha további előnyöket nyújt.
A megfelelő irányítópultok és metrikák hiánya
Miután beállították a célokat, a fejlesztőcsapat létrehozhat egy irányítópultot a KPI-k mérésére. A fejlesztés előtt érdemes értékelni azokat a paramétereket, amelyeket nyomon fognak követni.
Különböző jelentések és alkalmazások hasznosak a csapat különböző tagjai számára. A Scrum mestereket inkább a státusz és a lefedettség érdekli, míg a felsővezetés számára a szakemberek kiégési sebessége lehet a fontos.
Néhány csapat az állapot CI/CD értékelésére piros, sárga és zöld indikátorokkal ellátott irányítópultokat is használ, hogy világosan lássák, jól csinálják-e a dolgokat, vagy hiba lépett fel. A piros azt jelzi, hogy figyelmet kell fordítani a folyamatokra.
Ha azonban az információs panelek nincsenek standardizálva, félrevezetők lehetnek. Elemezze, hogy kinek milyen adatokra van szüksége, majd hozzon létre egy standardizált leírást arról, hogy mit is jelentenek. Tudd meg, mi van jobban értelmezve az érdekelt felek számára: grafikonok, szöveg vagy számok.
A manuális tesztek hiánya
A tesztelés automatizálása megalapozza a jó CI/CD folyamatot. De az automatizált tesztelés minden lépésnél nem jelenti azt, hogy a manuális tesztelést mellőzni kell.
A hatékony CI/CD folyamat felépítéséhez manuális tesztekre is szükség van. Mindig lesznek olyan tesztelési aspektusok, amelyek emberi elemzést igényelnek.
Érdemes megfontolni a manuális tesztelési erőfeszítések integrálását a folyamatba. Miután a manuális tesztelés néhány tesztesete befejeződött, lehetőség nyílik a telepítési fázisra.
Ne próbálja megjavítani a teszteket
A hatékony CI/CD folyamat megköveteli, hogy hozzáférjünk a szükséges eszközökhöz, legyen szó tesztkezelésről vagy integrációról és folyamatos monitorozásról.
Egy erős, minőségorientált kultúra kialakítása a következőkre fókuszál: , a telepítés utáni ügyfélinterakciók monitorozására és a fejlesztések nyomon követésére.
Íme néhány gyakorlati tanács, amelyet egyszerűen megvalósíthat:
- Gondoskodjon róla, hogy a tesztek könnyen írhatóak legyenek, és elég rugalmasak ahhoz, hogy ne törjenek meg a kód refaktorálásakor.
- A fejlesztői csapatoknak részt kell venniük a tesztelési folyamatban – látnia kell a felhasználói problémákat és kéréseket, amelyek fontosak a CI folyamatok során végzett ellenőrzéshez.
- Lehet, hogy nem rendelkezik teljes tesztelési lefedettséggel, de mindig ügyeljen arra, hogy az UX-t és az ügyfélinterakciókat érintő folyamatait teszteljék.
Az utolsó, de nem elhanyagolható szempont
A CI/CD-re való áttérés általában alulról felfelé történik, de végül ez egy olyan átalakulás, amely vezetői részvételt, idő- és erőforrást igényel a vállalattól. A CI/CD készségekből, folyamatokból, eszközökből és kulturális átalakulásból áll, és az ilyen változások bevezetését csak rendszerszerűen lehet megvalósítani.
Mit érdemes még olvasni a témában:
- .
- .
- .
Forrás: habr.com
