A digitális találmányok bevezetésének elősegítése

Az innováció végső próbája az ügyfél reakciója a találmányára. Igaznak bizonyult a hipotézis? Az ügyfelek használják a megoldást? Képes a skálázódásra, hogy megfeleljen a felhasználók kívánt százalékának igényeihez? Ami igazán fontos, az az, hogy visszatérnek-e? Ezek közül a kérdések közül egyik sem kérdezhető fel a minimálisan működőképes termék (MVP) megoldás üzembe helyezéséig.

Ebben a cikkben arra összpontosítunk, hogy a bevezetést folyamatos integrációval és folyamatos üzembe helyezési (CI/CD) folyamateszközökkel segítsük. A folyamatos integráció a kód naponta többszöri automatizálása egy frissített projekt érdekében. A folyamatos üzembe helyezés a funkciók automatikus kézbesítése a nap folyamán.

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-folyamatok lesznek ismerősek. Ez a cikk kiindulópontot teremt a felhőbevezetési csapatok számára, amelyek az innovációt és a visszajelzési ciklusokat táplálják. Ez a kiindulási pont a termékek és a csapatok kifejlődése során erőteljesebb CI/CD- vagy DevOps-megközelítéseket eredményezhet.

Az ügyfelekre gyakorolt hatás mérésében leírtak szerint a hipotézisek pozitív érvényesítése iterációt és meghatározást igényel. Ennek a CI/CD cikknek az a célja, hogy minimalizálja a technikai csúcsokat, amelyek lassítják az innovációt, miközben biztosítja, hogy a legjobb gyakorlatokat követve dolgozzunk. Ez segít a csapatnak a jövőbeli sikerek kialakításában, miközben az aktuális ügyféligényeket is kielégíti.

Az elfogadás és a digitális innováció támogatása: Érettsé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 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 folyamatosan kezelhetők iterációkkal.
• 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ástelepítés: Megoldások üzembe helyezése, hogy a csapat gyorsan megoszthassa a módosításokat az ügyfelekkel.
• Integrált mérés: Tanulási metrikák hozzáadása a visszajelzési ciklushoz a teljes csapat egyértelmű elemzéséhez.

A technikai kiugró csúcsok 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észletesebbek lesznek. Az Azure-ban a GitHub és az Azure DevOps lehetővé teszi a kis csapatok számára, hogy 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 a "nagy terv, kis kezdet" megközelítést mutatja be, amely lehetővé teszi a bevezetést ezen alapelvek között.

Megosztott megoldás

Az ügyfelekre gyakorolt hatás mérésében leírtak szerint a hipotézisek pozitív érvényesítése iterációt és meghatározást igényel. Minden innovációs ciklus során sokkal több hibát fog tapasztalni, mint a győzelem. Ez várható. Ha azonban az ügyfélnek szüksége, hipotézise és megoldása nagy léptékben igazodik, a világ gyorsan megváltozik.

A digitális találmányok és innovációk skálázása során nincs több értékes eszköz, mint a megoldás közös kódbázisa. Sajnos nem lehet megbízható módon megjósolni, hogy melyik iteráció vagy melyik MVP fogja eredményezni a győztes kombinációt. Ezért még soha nem korai közös kódbázist vagy -adattárat létrehozni. Ez az egyetlen technikai csúcs , amelyet nem szabad késleltetni. Mivel a csapat különböző MVP-megoldásokon keresztül halad végig, 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 lefelé húzják a tanulási metrikákat, 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-adattár funkciója git - vagy TFVC-adattár létrehozásához 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ához. Ez részben az ügyfelek hatásának mérésével valósul meg. Ez beszélgetéseket és közvetlen tesztelést igényel az ügyféllel. Mindkettő olyan visszajelzést hoz létre, amelyet hatékonyan kell kezelni.

Minden visszajelzési pont egy lehetséges megoldás az ügyfél igényére. Ennél is fontosabb, hogy a közvetlen ügyfél-visszajelzések minden apró részlete lehetőséget ad a partnerség javítására. Ha a visszajelzés egy MVP-megoldásba kerül, ezt ünnepelje meg az ügyféllel. Még ha néhány visszajelzés nem is végrehajtható, az a döntés, hogy észrevehetően áttetsző módon háttérbe szorítjuk a visszajelzést, a növekedési gondolkodásmódot és a folyamatos tanulást mutatja.

Az Azure DevOps tartalmazza a visszajelzések kérésének, megadásának és kezelésének módjait. Ezek az eszközök központosítják a visszajelzéseket, hogy a csapat lépést tehessen és nyomon követhesse egy transzparens visszajelzési ciklust.

Folyamatos integráció

A folyamatos integráció a kód naponta többszöri automatizálása egy frissített projekthez. Ahogy a bevezetések mérete és a hipotézis egyre közelebb kerül a valódi innovációhoz nagy léptékben, a vizsgálandó kisebb hipotézisek száma általában gyorsan növekszik. A pontos visszajelzési ciklusok é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 el kell lépnie az innovációhoz és a növekedéshez, amelyhez több fejlesztőre van szükség az alapvető hipotézis változatainak teszteléséhez. A későbbi fázisbeli fejlesztési erőfeszítésekhez akár több fejlesztőcsapatra is szükség lehet, és mindegyik egy megosztott megoldás felé épít. A folyamatos integráció az első lépés az összes mozgó alkatré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 közösen dolgozzanak ki olyan megosztott megoldásokat, amelyek pontos és megbízható visszajelzési ciklusokat biztosítanak.

Az Azure DevOps és az Azure Pipelines csak néhány lépéssel biztosít folyamatos integrációs képességeket a GitHubon vagy más adattárakban. 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ármilyen megoldásban hamis pozitív vagy hamis negatívumokat okozhatnak. A váratlan hibák könnyen a felhasználói bevezetési metrikák félreértelmezéséhez vezethetnek. Olyan negatív visszajelzéseket is generálhatnak az ügyfelektől, amelyek nem tükrözik pontosan a hipotézis tesztelését.

Az MVP-megoldás korai iterációi során hibák várhatók. A korai alkalmazók még bájosnak is találhatják őket. 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ése. Mindkettőt kódszintű egységtesztekkel és manuális elfogadási tesztekkel lehet elvégezni az üzembe helyezés előtt. Ezek együttesen biztosítják a megbízhatóság bizonyos eszközeit a teszteléshez. Érdemes megpróbálni automatizálni egy jól definiált összeállítá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ához kapcsolódó 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 üzemeltetéséhez.

Megoldás üzembe helyezése

A bevezetés elősegítésének talán legérthetőbb aspektusa a megoldás ügyfeleknek való kiadásának szabályozása. Ha önkiszolgáló vagy automatizált folyamatot biztosít egy megoldás ügyfeleknek való kiadásához, felgyorsítja a visszajelzési ciklust. Ha lehetővé teszi az ügyfelek számára a megoldás változásainak gyors kezelését, 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 telepítve lesznek egy termelési környezethez hasonló környezetbe. A fejlesztők, az üzleti döntéshozók és a csapat többi tagja ezzel a környezettel ellenőrizheti, hogy a munkájuk éles üzemre kész-e. Ezzel a módszerrel tesztelheti a hipotézist az ügyfelekkel anélkül, hogy befolyásolná a folyamatban lévő üzleti tevékenységeket.
• A manuális üzembe helyezés a kiadáskezelés legkevésbé kifinomult megközelítése. Ahogy a név is sugallja, a csapat egyik tagja manuálisan telepíti a legutóbbi kódmódosításokat. Ez a megközelítés hibaérzékeny, megbízhatatlan, és a legtöbb tapasztalt mérnök hibás tervezési mintának 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ési automatizálás.

A korai befektetés időt veszthet. Ennél is fontosabb, hogy függőségeket hozhat létre a kiadási csővezetékre, ami ellenállóbbá teheti a csapatot egy korai irányváltással 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 üzemi 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. További információ 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álatakor 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 későbbi iterációkban való kifejlődésében, ami végső soron a bevezetés nagy léptékű ismétléséhez vezet.

Az Azure Monitor eszközöket és felületet biztosít az ügyfélélmények adatainak gyűjtéséhez és áttekintéséhez. Ezeket a megfigyeléseket és megállapításokat az Azure Boards segítségével továbbfejlesztheti, hogy finomítsa a teendőlistát.

Következő lépések

Miután megismerte az elfogadás elősegítéséhez szükséges CI/CD eszközöket és folyamatokat, eljött az ideje, hogy megvizsgáljon egy fejlettebb innovációs fegyelmet: az eszközökkel való interakciót. Ez a szemlélet segíthet csökkenteni a fizikai és a digitális élmények közötti korlátokat, így a megoldás még egyszerűbbé válik.

Eszközök használata