Összegzés

  • 3 perc

Ebben a modulban egy üzembehelyezési mintát definiált, amely automatikusan lehetővé teszi az új alkalmazásfunkciók zökkenőmentes bevezetését a felhasználók számára. A jó üzembe helyezési minta segíthet minimalizálni az állásidőt. Emellett lehetővé teszi, hogy fokozatosan új funkciókat vezessen be a felhasználók számára.

Számos üzembehelyezési minta közül választhat. A választott üzembehelyezési minta az üzembe helyezés okaitól és az erőforrásoktól függ. Vannak a canary testers a helyén? Sötét indítást alkalmaz, és olyan tesztelőket választ, akik nem tudják, hogy tesztelők? Ha megbízható tesztelőkészlettel rendelkezik, amely fokozatosan növekszik egy kis készletről egy nagyobb készletre, akkor választhat egy progresszív expozíciós üzembe helyezést. Vagy ha tudni szeretné, hogy az egyik verzió jobban teljesít-e, mint egy másik verzió, választhatja az A/B tesztelést.

A Tailspin csapata úgy döntött, hogy implementálja a kék-zöld üzembehelyezési mintát a Azure-alkalmazás Service üzembehelyezési pontjaival. Az üzembehelyezési pontok olyan élő alkalmazások, amelyek saját gazdagépnevekkel rendelkeznek. A csapat két üzembehelyezési pontot tud felcserélni. A felcseréléssel azonnal előléptethetik az éles környezet változásait. Bár a csapat nem áll készen arra, hogy közzétehesse a webhelyét a nyilvánosság számára, bebizonyította, hogy állásidő nélkül is hozzájuthat új funkciókhoz a felhasználók számára.

Bónuszként ebben a modulban azt is megtanulta, hogyan továbbíthat egy nem szándékos módosítást egy Git-véglegesítés visszaállításával, majd a visszaállított módosítás folyamaton keresztüli leküldésével.

Milyenek a csapat eredményei?

A Meglévő szoftverfejlesztési folyamat felmérése modulban Mara elvégezte az értékáram-leképezési gyakorlatot. A gyakorlat segített a csapatnak elemezni az aktuális kiadási ciklus folyamatát.

Ne feledje, hogy a tevékenységarány vagy a hatékonyság a folyamatidő és a teljes átfutási idő osztva:

$${Tevékenységarány\ =\ }{\dfrac{Feldolgozási\ idő}{Teljes\ átfutási\ idő}}$$

A Tailspin webcsapata kezdetben ezt a metrikát használta annak megállapítására, hogy 23 százalékban hatékonyak.

A csapat először csökkentett néhány hatékonysági hatékonyságot a folyamatos integráció (CI) megvalósításakor. A folyamatos kézbesítés (CD) alkalmazásával a hatékonysági hiányosságok még tovább csökkentek.

A korábbi képzési tervekben a csapat csökkentette a következőt:

  • Az új funkciókhoz szükséges forrásvezérlő beállítása. A szükséges idő három napról nulla napra ment.

    A csapat ezt a fejlesztést úgy érte el, hogy a központi forrásvezérlésről a Gitre vált, amely az elosztott forrásvezérlés egyik formája. Az elosztott forrásvezérlő használatával nem kell megvárniuk a fájlok zárolásának feloldását.

  • A kód Amita, a tesztelő számára történő kézbesítésének időtartama. A szükséges idő két napról nulla napra emelkedett.

    A csapat ezt a fejlesztést úgy érte el, hogy áthelyezte a buildelési folyamatot az Azure Pipelinesba. Az Azure Pipelines automatikusan értesíti az Amitát, ha elérhető egy build. A fejlesztőknek már nem kell frissíteniük Amita számolótábláját, hogy értesítsék.

  • Az az idő, amíg Amita teszteli az új funkciókat. A szükséges idő három napról egy napra ment.

    A csapat ezt a fejlesztést a kód egységtesztelésével érte el. Egységteszteket futtatnak minden alkalommal, amikor a változás áthalad a buildelési folyamaton, így kevesebb hiba és regresszió éri el az Amitát. A csökkentett számítási feladat azt jelenti, hogy Amita gyorsabban tudja elvégezni az egyes manuális teszteket.

Az ebben a képzési tervben létrehozott kiadási folyamat, amelyet Ön és a csapat készített, csökkentették:

  • A build tesztelési szakaszba való beolvasásához szükséges idő. A szükséges idő három napról egy napra ment.

    A csapat ezt úgy érte el, hogy egy ütemezett eseményindító használatával minden nap 3:00-kor üzembe helyezi a tesztelést .

  • A tesztelt build előkészítésbe való beolvasásához szükséges idő. A szükséges idő két napról nulla napra emelkedett.

    A csapat ezt a javulást úgy érte el, hogy a tesztszakaszhoz hozzáadta a funkcionális tesztelés egyik formáját, a Selenium UI-teszteket . Ezek az automatizált tesztek sokkal gyorsabbak, mint a manuális verziók.

  • A jóváhagyott build üzembe helyezéséhez szükséges idő az előkészítéstől az élettartamig. A szükséges idő egy napról egy napnál rövidebbre csökkent.

    A csapat ezt a fejlesztést úgy érte el, hogy manuális jóváhagyási ellenőrzéseket adott hozzá a folyamathoz. Amikor a felügyelet kijelentkezik, Tim kiadhatja a módosításokat az előkészítésből az élő állapotba.

Ezek a módosítások 22 napról 10 napra csökkentik az átfutási időt. Amikor ezeket a számokat az egyenletbe helyettesítjük:

$${Activity\ ratio\ =\ }{\dfrac{5\ days}{10\ days}}{ = 0,50}$$

Szorozza meg az eredményt 100 százalékkal, és 50 százalékos csökkenést kapunk.

Bár mindig van hova fejlődni, ez a változás egy győzelem a csapat számára. Az ügyfelek nemcsak gyorsabban kapnak értéket, a Tailspin csapata kevesebb időt tölt várakozással, és több időt tölt azzal, amit a legjobban élvez: olyan funkciókat kínál, amelyeket az ügyfeleik imádni fognak.

További információ

Az alábbi további forrásokból többet tudhat meg az App Service-ről, az üzembehelyezési pontokról és a módosítások visszaállításáról: