Megosztás a következőn keresztül:

Tesztalapú fejlesztés azure-beli célzónákhoz

  • Cikk

A tesztalapú fejlesztés (TDD) egy szoftverfejlesztési és DevOps-folyamat, amely javítja az új funkciók minőségét és a kódalapú megoldások fejlesztését. A TDD a tényleges kód létrehozása előtt egységtesztelési eseteket hoz létre, és teszteli a kódot a tesztelési eseteken. Ez a megközelítés ellenzi a kód fejlesztését és a tesztesetek későbbi létrehozását.

A célzóna olyan környezet, amely kóddal előre elkészített számítási feladatokat üzemeltet. A célzónák olyan alapvető képességeket tartalmaznak, amelyek meghatározott felhőszolgáltatásokat és ajánlott eljárásokat használnak. Ez a cikk egy olyan megközelítést ismertet, amely a TDD-t használja a sikeres kezdőzónák üzembe helyezéséhez, miközben megfelel a minőségi, biztonsági, üzemeltetési és szabályozási követelményeknek.

A felhőinfrastruktúra a kódvégrehajtás kimenete. A jól strukturált, tesztelt és ellenőrzött kód életképes célzónát hoz létre. A felhőalapú infrastruktúra és annak mögöttes forráskódja ezzel a megközelítéssel biztosíthatja, hogy a célzónák kiváló minőségűek legyenek, és megfeleljenek az alapvető követelményeknek.

Ezzel a megközelítéssel egyszerű funkciókéréseket teljesíthet a korai fejlesztés során. A felhőbevezetési életciklus későbbi szakaszában ezt a folyamatot használhatja a biztonsági, üzemeltetési, szabályozási vagy megfelelőségi követelmények teljesítéséhez. Ez a folyamat különösen hasznos a kezdőzónák párhuzamos fejlesztési erőfeszítések során történő fejlesztéséhez és újrabontásához.

Tesztalapú fejlesztési ciklus

Az alábbi ábra az Azure-beli célzónák tesztalapú fejlesztési ciklusát mutatja be:

Az Azure-beli célzónák tesztalapú fejlesztési folyamatának ábrája.

  1. Hozzon létre egy tesztet. Adjon meg egy tesztet annak ellenőrzéséhez, hogy egy szolgáltatás elfogadási feltételei teljesültek-e. A fejlesztés során automatizálhatja a tesztet a manuális tesztelési munka mennyiségének csökkentése érdekében, különösen a nagyvállalati szintű üzemelő példányok esetében.

  2. Tesztelje a célzónát. Futtassa az új tesztet és a meglévő teszteket. Ha a szükséges funkció nem szerepel a felhőszolgáltató ajánlataiban, és a korábbi fejlesztési erőfeszítések nem adták meg, a tesztnek sikertelennek kell lennie. A meglévő tesztek futtatásával ellenőrizheti, hogy az új funkció vagy teszt nem csökkenti-e a meglévő célzóna-funkciók megbízhatóságát.

  3. Bontsa ki és bontsa újra a célzónát. Adjon hozzá vagy módosítsa a forráskódot a kért érték hozzáadása funkció teljesítéséhez, és javítsa a kódbázis általános minőségét.

    A TDD-feltételek teljesítéséhez a felhőplatform csapata csak a kért funkciónak megfelelő kódot adna hozzá. A kódminőség és a karbantartás azonban közös munka. Az új funkciókérések teljesítésével a felhőplatform-csapatnak meg kell próbálnia javítani a kódot a duplikációk eltávolításával és a kód tisztázásával. Erősen ajánlott teszteket futtatni az új kód létrehozása és a forráskód újrabontása között.

  4. Helyezze üzembe a célzónát. Miután a forráskód teljesítette a funkciókérést, helyezze üzembe a módosított célzónát a felhőszolgáltatónál egy ellenőrzött tesztelési vagy tesztkörnyezetben.

  5. Tesztelje a célzónát. Tesztelje újra a célzónát annak ellenőrzéséhez, hogy az új kód megfelel-e a kért funkció elfogadási feltételeinek. Az összes teszt sikeres elvégzése után a rendszer befejezettnek tekinti a funkciót, és az elfogadási feltételek teljesülnek.

A TDD-ciklus megismétli az előző alapvető lépéseket, amíg meg nem felelnek a kész teljes definíciójának. Ha az összes hozzáadott funkció és elfogadási feltétel megfelel a kapcsolódó teszteknek, a kezdőzóna készen áll a felhőbevezetési terv következő hullámának támogatására.

A TDD-t hatékonyabbá tevő ciklust gyakran piros/zöld tesztnek nevezik. Ebben a megközelítésben a felhőplatform-csapat egy sikertelen teszttel vagy piros teszttel indul a kész definíció és a meghatározott elfogadási feltételek alapján. A felhőplatform-csapat minden egyes funkcióhoz vagy elfogadási feltételhez elvégzi a fejlesztési feladatokat, amíg a teszt be nem fejeződik, vagy zöld teszttel rendelkezik.

A TDD célja a jobb tervezés, nem pedig egy tesztcsomag létrehozása. A tesztek értékes összetevők a folyamat befejezéséhez.

A befejezés definíciója

A siker lehet egy szubjektív mérték, amely a felhőplatform-csapat számára kevés hasznos információt biztosít a kezdőzóna fejlesztése vagy újrabontása során. Az egyértelműség hiánya a felhőkörnyezetben nem várt elvárásokhoz és biztonsági résekhez vezethet. Mielőtt a felhőplatform-csapat újraterjesztené vagy kibővítené a célzónákat, egyértelművé kell tenniük a kész (DoD) definícióját az egyes célzónákhoz.

A DoD egy egyszerű megállapodás a felhőplatform-csapat és más érintett csapatok között, amelyek meghatározzák a kezdőzóna fejlesztési munkáiba belefoglalandó értéknövelő funkciókat. A DoD gyakran egy ellenőrzőlista, amely megfelel a rövid távú felhőbevezetési tervnek.

Ahogy a csapatok több számítási feladatot és felhőfunkciót vezetnek be, a DoD és az elfogadási feltételek egyre összetettebbé válnak. Az érett folyamatokban a várt funkciók saját elfogadási kritériumokkal rendelkeznek, hogy egyértelműbb legyen. Ha az értéknõtt funkciók mindegyike megfelel az elfogadási feltételeknek, a célzóna megfelelően konfigurálva van ahhoz, hogy a jelenlegi bevezetési hullám vagy kiadás sikeres legyen.

Egyszerű DoD-példa

A kezdeti migráláshoz a DoD túl egyszerű lehet. Az alábbi példa egy egyszerű DoD:

A kezdeti kezdőzóna 10 számítási feladatot fog üzemeltetni kezdeti tanulási célokra. Ezek a számítási feladatok nem kritikus fontosságúak a vállalat számára, és nem férnek hozzá a bizalmas adatokhoz. A jövőben ezek a számítási feladatok valószínűleg éles környezetben lesznek kibocsátva, de a kritikusság és a bizalmasság várhatóan nem változik.

Ezeknek a számítási feladatoknak a támogatásához a felhőbevezetési csapatnak meg kell felelnie a következő feltételeknek:

  • Hálózati szegmentálás a javasolt hálózattervezéshez igazodva. Ennek a környezetnek peremhálózatnak kell lennie, amely hozzáfér a nyilvános internethez.
  • A számítási, tárolási és hálózati erőforrásokhoz való hozzáférés a digitális tulajdon felderítéséhez igazodó számítási feladatok üzemeltetéséhez.
  • A séma elnevezése és címkézése a könnyű használat érdekében.
  • A bevezetés során a felhőbevezetési csapat ideiglenes hozzáférése a szolgáltatáskonfigurációk módosításához.
  • Az éles kiadás előtt integrálás a vállalati identitásszolgáltatóval a folyamatos identitáskezelés és hozzáférés szabályozása érdekében. Ekkor a felhőbevezetési csapat hozzáférését vissza kell vonni.

Az utolsó pont nem funkció- vagy elfogadási feltétel, hanem azt jelzi, hogy további bővítésekre lesz szükség, és a többi csapattal is érdemes korán megismerkedni.

Összetettebb DoD-példák

A szabályozási módszertan a felhőadaptálási keretrendszer egy irányítási csapat természetes érettségén keresztül nyújt elbeszélő utat. A folyamatba ágyazva számos példa van a DoD-ra és az elfogadási kritériumokra, szabályzatutasások formájában.

Az előző példák alapvető minták, amelyek segítenek a kezdőzónák doD-jának fejlesztésében. Mintaszabályzatokat kaphat a felhőszabályozás öt szemléletéhez.

Azure-eszközök és funkciók a TDD kezdőzónájának támogatásához

Az alábbi ábra az Azure-ban elérhető tesztalapú fejlesztési eszközöket mutatja be:

Az Azure-ban elérhető tesztalapú fejlesztési eszközöket bemutató ábra.

Ezeket az Azure-eszközöket és -funkciókat egyszerűen integrálhatja a TDD-be a kezdőzóna létrehozásához. Az eszközök meghatározott célokat szolgálnak, így könnyebben fejleszthetők, tesztelhetők és üzembe helyezhetők a célzónák a TDD-ciklusokkal összhangban.

  • Az Azure Resource Manager egységes platformot biztosít a buildelési és üzembehelyezési folyamatokhoz. A Resource Manager-platform a forráskód-definíciók alapján üzembe helyezheti a kezdőzónákat.

  • Az Azure Resource Manager-sablonok elsődleges forráskódot biztosítanak az Azure-ban üzembe helyezett környezetekhez. Egyes külső eszközök, például a Terraform saját ARM-sablonokat biztosítanak az Azure Resource Managerhez való küldéshez.

  • Az Azure rövid útmutatósablonjai forráskódsablonokat biztosítanak, amelyek segítenek felgyorsítani a kezdőzóna és a számítási feladatok üzembe helyezését.

  • Az Azure Policy biztosítja a DoD-ban az elfogadási feltételek tesztelésének elsődleges mechanizmusát. Az Azure Policy automatikus észlelést, védelmet és megoldást is biztosít, ha az üzembe helyezés eltér a szabályozási szabályzatoktól.

    Egy TDD-ciklusban létrehozhat egy szabályzatdefiníciót egyetlen elfogadási feltétel teszteléséhez. Az Azure Policy beépített szabályzatdefiníciókat tartalmaz, amelyek megfelelnek a DoD-ban az egyes elfogadási feltételeknek. Ez a megközelítés a kezdőzóna módosítása előtt biztosít mechanizmust a vörös tesztekhez.

    Az Azure Policy beépített szabályzatkezdeményeket is tartalmaz, amelyekkel tesztelheti és kényszerítheti a teljes DoD-t a célzónához. Az összes elfogadási feltételt hozzáadhatja a teljes előfizetéshez rendelt szabályzatkezdeményezéshez. Miután a kezdőzóna megfelel a DoD-nak, az Azure Policy kikényszerítheti a tesztelési feltételeket, hogy elkerülje azokat a kódmódosításokat, amelyek miatt a teszt meghiúsul a jövőbeni kiadásokban.

    Tervezzen és tekintse át az Azure Policyt kód-munkafolyamatként a TDD-megközelítés részeként.

  • Az Azure Resource Graph lekérdezési nyelvet biztosít az adatvezérelt tesztek létrehozásához a célzónában üzembe helyezett eszközökre vonatkozó információk alapján. Az bevezetési terv későbbi részében ez az eszköz összetett teszteket is meghatározhat a számítási feladatok eszközei és a mögöttes felhőkörnyezet közötti interakciók alapján.

    A Resource Graph speciális lekérdezésmintákat tartalmaz, amelyekkel megismerheti, hogy a számítási feladatok hogyan vannak üzembe helyezve a kezdőzónában speciális tesztelési forgatókönyvek esetén.

Az előnyben részesített megközelítéstől függően a következő eszközöket is használhatja:

Következő lépések