Bevezetés támogatása digitális találmányokkal

Az innováció végső tesztje az ügyfél reakciója a találmányára. A hipotézis igaznak bizonyult? Az ügyfelek használják a megoldást? A felhasználók kívánt százalékának igényeinek megfelelően méretezhető? A legfontosabb, hogy visszatérnek-e? Ezen kérdések egyike sem kérdezhető fel a minimális működőképes termék (MVP) megoldás üzembe helyezéséig.

Ebben a cikkben a bevezetés folyamatos integrációs és folyamatos üzembe helyezési (CI/CD) folyamateszközökkel való segítésével foglalkozunk. A folyamatos integráció a kód naponta többszöri automatizálása egy frissített projekt létrehozásához. A folyamatos üzembe helyezés ezeknek a függvényeknek a nap folyamán történő automatikus kézbesítése.

A bevezetést befolyásoló CI/CD-súrlódás csökkentése

A bevezetés néhány akadálya a technológia és a folyamatok kombinációjával minimalizálható. A CI/CD- vagy DevOps-folyamatokat ismerő olvasók számára az alábbi CI/CD-folyamatfolyamatok lesznek ismerősek. Ez a cikk kiindulópontot hoz létre a felhőbevezetési csapatok számára, amelyek az innovációt és a visszajelzési hurkokat táplálják. Ez a kiindulási pont robusztusabb CI/CD- vagy DevOps-megközelítéseket eredményezhet, ahogy a termékek és a csapatok kifejlődnek.

Az ügyfélre gyakorolt hatás méréséről a hipotézis pozitív ellenőrzése iterációt és meghatározást igényel. Ez a CI/CD-cikk célja, hogy minimalizálja a lassú innovációt okozó technikai csúcsokat , miközben gondoskodik arról, hogy az ajánlott eljárások érvényben legyenek. Ez segít a csapatnak megtervezni a jövőbeli sikereket, miközben az aktuális ügyféligényeket is kielégíti.

Bevezetés és digitális találmányok támogatása: A fejlettségi modell

Az innováció módszertanának elsődleges célja az ügyfélkapcsolatok kiépítése és a visszajelzési hurkok felgyorsítása, ami piaci innovációkhoz vezet. Az alábbi kép és szakaszok az ezt a módszertant támogató kezdeti implementációkat ismertetik.

• Megosztott megoldás: Hozzon létre egy központosított adattárat a megoldás minden aspektusához.
• Visszajelzési hurkok: Győződjön meg arról, hogy a visszajelzési hurkok iterációkkal konzisztensen kezelhetők.
• Folyamatos integráció: A megoldás rendszeres összeállítása és konszolidálása.
• Megbízható tesztelés: Ellenőrizze a megoldás minőségét és a várt változásokat a tesztelési metrikák megbízhatóságának biztosítása érdekében.
• Megoldás üzembe helyezése: Helyezzen üzembe megoldásokat, hogy a csapat gyorsan megoszthassa a módosításokat az ügyfelekkel.
• Integrált mérés: Tanulási metrikákat adhat hozzá a visszajelzési ciklushoz, hogy a teljes csapat egyértelmű elemzést végezhesse.

A technikai kiugró értékek minimalizálása érdekében feltételezzük, hogy az érettség kezdetben alacsony lesz ezen alapelvek között. Tervezze meg előre azokat az eszközöket és folyamatokat, amelyek úgy méretezhetők, hogy a hipotézisek részletesebbé válnak. Az Azure-ban a GitHub és az Azure DevOps lehetővé teszi, hogy a kis csapatok kis súrlódással kezdhessenek. Ezek a csapatok több ezer fejlesztőt is bevonhatnak, akik skálázási megoldásokon dolgoznak, és több száz ügyfélhipotézist tesztelnek. A cikk további része bemutatja a "nagy terv, kis kezdő" megközelítést, amely lehetővé teszi az elfogadást ezen alapelvek között.

Megosztott megoldás

Az ügyfélre gyakorolt hatás méréséről a hipotézis pozitív ellenőrzése iterációt és meghatározást igényel. Az innovációs ciklusok során sokkal több hibát fog tapasztalni, mint amennyit nyer. Ez a várható eredmény. Ha azonban egy ügyfélnek nagy léptékben kell igazodnia, hipotézisre és megoldásra van szüksége, a világ gyorsan változik.

A digitális találmányok és innováció skálázásakor nincs értékesebb eszköz, mint a megoldás közös kódbázisa. Sajnos nem lehet megbízhatóan megjósolni, hogy melyik iteráció vagy melyik MVP fogja eredményezni a győztes kombinációt. Ezért soha nem túl korai közös kódbázist vagy -adattárat létrehozni. Ez az egyetlen technikai csúcs , amelyet nem szabad késleltetni. Ahogy a csapat végigvezeti a különböző MVP-megoldásokat, a megosztott adattár egyszerű együttműködést és gyorsított fejlesztést tesz lehetővé. Ha a megoldás módosításai a tanulási metrikákat lefelé húzják, a verziókövetés lehetővé teszi a megoldás korábbi, hatékonyabb verziójának visszaállítását.

A kódtárak kezelésére leggyakrabban használt CI/CD-eszköz a GitHub, amellyel néhány lépésben létrehozhat egy megosztott kódtárat. Emellett az Azure DevOps Azure Repos funkciója git - vagy TFVC-adattárak létrehozására is használható.

Visszajelzési hurkok

Az ügyfél a megoldás részévé tétele kulcsfontosságú az innovációs ciklusok során az ügyfélkapcsolatok kialakításában. Ez részben az ügyfelek hatásának mérésével valósítható meg. Ehhez beszélgetésekre és közvetlen tesztelésre van szükség az ügyféllel. Mindkettő olyan visszajelzést generál, amelyet hatékonyan kell kezelni.

Minden visszajelzési pont potenciális megoldást jelent az ügyfelek számára. Ennél is fontosabb, hogy a közvetlen ügyfélvisszajelzések minden apró részlete lehetőséget kínál a partnerség javítására. Ha a visszajelzés MVP-megoldássá teszi, ezt ünnepelje meg az ügyféllel. Még akkor is, ha néhány visszajelzés nem működik, egyszerűen átlátható a döntés, hogy deprioritize a visszajelzés azt mutatja, a növekedési gondolkodásmód és a hangsúly a folyamatos tanulás.

Az Azure DevOps a visszajelzések kérésének, biztosításának és kezelésének módjait tartalmazza. Ezek az eszközök központosítják a visszajelzéseket, hogy a csapat lépéseket tegyen, és átlátható visszajelzési ciklust biztosítson.

Folyamatos integráció

A folyamatos integráció a kód naponta többszöri automatizálása, hogy egyetlen projekt frissüljön. Ahogy a bevezetések mérete és a hipotézis egyre közelebb kerül a valós innovációhoz nagy léptékben, a vizsgálandó kisebb hipotézisek száma általában gyorsan növekszik. A pontos visszajelzési hurkok és a zökkenőmentes bevezetési folyamatok érdekében fontos, hogy ezek a hipotézisek integrálva legyenek és támogassák az innováció mögött álló elsődleges hipotézist. Ehhez gyorsan át kell lépnie az innovációra és a növekedésre, amihez több fejlesztőnek kell tesztelnie az alapvető hipotézis variációit. A későbbi fejlesztési lépésekhez akár több fejlesztői csapatra is szükség lehet, mindegyik egy megosztott megoldás felé építkezhet. A folyamatos integráció az első lépés az összes mozgó rész kezelése felé.

A folyamatos integráció során a kódmódosítások gyakran egyesülnek a főágban. Az automatizált buildelési és tesztelési folyamatok biztosítják, hogy a főágban lévő kód mindig éles minőségű legyen. Ez biztosítja, hogy a fejlesztők együtt dolgozzanak ki olyan megosztott megoldásokat, amelyek pontos és megbízható visszajelzési hurkokat biztosítanak.

Az Azure DevOps és az Azure Pipelines a GitHubon vagy más adattárakban csupán néhány lépéssel biztosít folyamatos integrációs képességeket. További információ: Mi a folyamatos integráció? vagy próbálja ki a folyamatos integrációs gyakorlati labort. Olyan megoldásarchitektúrák érhetők el, amelyek felgyorsíthatják a CI-/CD-folyamatok létrehozását az Azure DevOpson keresztül.

Megbízható tesztelés

A hibák bármely megoldásban hamis pozitív vagy hamis negatív eredményt hozhatnak létre. A váratlan hibák könnyen vezethetnek a felhasználói bevezetési metrikák félreértelmezéséhez. Negatív visszajelzéseket is generálhatnak az ügyfelektől, amelyek nem felelnek meg pontosan a hipotézis tesztjének.

Az MVP-megoldás korai iterációi során hibák várhatók. A korai örökbefogadók még azt is észrevehetik. A korai kiadásokban az elfogadási tesztelés általában nem létezik. Az empátiával való építés egyik aspektusa azonban az igény és a hipotézis érvényesítésére vonatkozik. Mindkettő elvégezhető kódszinten végzett egységtesztekkel és manuális elfogadási tesztekkel az üzembe helyezés előtt. Ezek együttesen biztosítják a megbízhatóságot a tesztelésben. Érdemes megpróbálni automatizálni egy jól definiált buildelési, egység- és elfogadási tesztsorozatot. Ezek biztosítják a hipotézis és az eredményként kapott megoldás finomabb finomhangolásával kapcsolatos megbízható metrikákat.

Az Azure Test Plans szolgáltatás eszközkészletet biztosít a teszttervek manuális vagy automatizált végrehajtása során történő fejlesztéséhez és működtetéséhez.

A megoldás üzembe helyezése

A bevezetés elősegítésének talán legérthetőbb aspektusa az, hogy ön képes szabályozni egy megoldás kiadását az ügyfelek számára. Ha önkiszolgáló vagy automatizált folyamatot biztosít egy megoldás ügyfelek számára történő kiadásához, felgyorsíthatja a visszajelzési ciklust. Ha lehetővé teszi az ügyfelek számára, hogy gyorsan kommunikáljanak a megoldás módosításaival, meghívja őket a folyamatba. Ez a megközelítés a hipotézisek gyorsabb tesztelését is elindítja, csökkentve a feltételezéseket és a lehetséges átdolgozásokat.

A megoldás üzembe helyezésének több módja is van. A három leggyakoribb:

• A folyamatos üzembe helyezés a legfejlettebb módszer, mivel automatikusan üzembe helyezi a kódmódosításokat az éles környezetben. Az érett hipotéziseket tesztelő érett csapatok számára a folyamatos üzembe helyezés rendkívül értékes lehet.
• A fejlesztés korai szakaszában a folyamatos teljesítés megfelelőbb lehet. A folyamatos teljesítés során a kódmódosítások automatikusan üzembe lesznek helyezve egy éles környezetbe. A fejlesztők, az üzleti döntéshozók és a csapat többi tagja ezzel a környezettel ellenőrizhetik, hogy a munkájuk készen áll-e az éles üzemre. Ezzel a módszerrel a meglévő üzleti tevékenységek befolyásolása nélkül is tesztelheti a hipotézist az ügyfelekkel.
• A manuális üzembe helyezés a kiadáskezelés legkevésbé kifinomult megközelítése. Ahogy a neve is sugallja, a csapat egyik tagja manuálisan helyezi üzembe a legújabb kódmódosításokat. Ez a megközelítés hibalehetőséget jelent, megbízhatatlan, és a legtöbb tapasztalt mérnök antipatternnek tekinti.

Az MVP-megoldás első iterációja során gyakori a manuális üzembe helyezés az előző értékelés ellenére. Ha a megoldás rendkívül folyékony, és az ügyfelek visszajelzése ismeretlen, jelentős kockázatot jelent a teljes megoldás (vagy akár az alapvető hipotézis) alaphelyzetbe állítása. A manuális üzembe helyezés általános szabálya: nincs ügyféligazolás, nincs üzembe helyezés automatizálása.

A korai befektetés időt veszíthet. Ennél is fontosabb, hogy függőségeket hozhat létre a kiadási folyamathoz, amelyek ellenállóbbá teszik a csapatot a korai kimutatásokkal szemben. Az első néhány iteráció után vagy amikor az ügyfelek visszajelzései potenciális sikerre utalnak, gyorsan el kell fogadni egy fejlettebb üzembe helyezési modellt.

A hipotézis-ellenőrzés bármely szakaszában az Azure DevOps és az Azure Pipelines folyamatos teljesítést és folyamatos üzembe helyezési képességeket biztosít. Tudjon meg többet a folyamatos kézbesítésről, vagy tekintse meg a gyakorlati labort. A megoldásarchitektúra felgyorsíthatja a CI/CD-folyamatok létrehozását az Azure DevOpson keresztül.

Integrált mérések

Az ügyfelek hatásának mérésekor fontos tisztában lenni azzal, hogy az ügyfelek hogyan reagálnak a megoldás változásaira. Ezek az adatok, más néven telemetria, betekintést nyújtanak a felhasználó (vagy a felhasználók kohorsza) által a megoldás használata során végrehajtott műveletekbe. Ezekből az adatokból könnyen lekérhető a hipotézis mennyiségi ellenőrzése. Ezek a metrikák ezután a megoldás módosítására és részletesebb hipotézisek létrehozására használhatók. Ezek a finomabb módosítások segítenek a kezdeti megoldás kifejlődésében a későbbi iterációkban, ami végső soron a bevezetés nagy léptékű megismétléséhez vezet.

Az Azure-ban az Azure Monitor biztosítja azokat az eszközöket és felületet, amelyekkel összegyűjtheti és áttekintheti az ügyfélélményekből származó adatokat. Ezeket a megfigyeléseket és megállapításokat az Azure Boards használatával pontosíthatja.

Következő lépések

Miután megismerte a bevezetéshez szükséges CI/CD-folyamatok eszközeit és folyamatait, ideje megvizsgálni egy fejlettebb innovációs szemléletet: az eszközökkel való interakciót. Ez a szemlélet segíthet csökkenteni a fizikai és digitális élmények közötti akadályokat, így a megoldás még könnyebben alkalmazható.

Interakciók eszközökkel