Összefoglalás

  • 3 perc

Ebben a modulban egy üzembehelyezési mintát definiált, az új alkalmazásfunkciók felhasználók számára történő zökkenőmentes bevezetésének automatizált módjaként. 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 kanári tesztelők a rendszerben? 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 az Azure App Service üzembehelyezési pontjaival. központi telepítési pontok olyan élő alkalmazások, amelyek saját gazdagépnevekkel rendelkeznek. A csapat két üzembehelyezési pontot tud felcserélni. Felcseréléssel azonnal végrehajthatják a termelési változtatásokat. 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 mozdíthat előre egy nem szándékos módosítást egy Git-commit visszaállításával és a visszaállított változtatás folyamaton keresztüli leküldésével.

Hogyan teljesít a csapat?

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

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

$${Tevékenységi\ arány\ =\ }{\dfrac{Folyamatidő}{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ághiányt 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ásának időtartama. A szükséges idő három naprólnulla napra.

    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ólnulla napra.

    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őtartam három naprólegy napra.

    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 Ön és a csapat által a képzési útvonal keretében létrehozott kiadási folyamat csökkentette:

  • A build Teszt szakaszába való eljutásához szükséges idő. A szükséges idő három naprólegy napra.

    A csapat ezt úgy érte el, hogy egy ütemezett eseményindítót használ a teszt minden nap 3:00-kor történő üzembe helyezéshez.

  • Azt az időtartamot, amely alatt a tesztelt build a előkészítésikörnyezetbe kerül. A szükséges idő két naprólnulla napra.

    A csapat úgy érte el ezt a javulást, hogy a tesztelési szakaszhoz hozzáadott Selenium felhasználói felületi teszteket, egy funkcionális tesztelési formát. Ezek az automatizált tesztek sokkal gyorsabbak, mint a manuális verziók.

  • A jóváhagyott build elő készítésből élőbe történő átállásához szükséges idő. A szükséges idő egy naprólkevesebb mint egy napra.

    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 vezetőség jóváhagyja, Tim kiadhatja a módosításokat a tesztkörnyezetből éles környezetbe.

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:

$${Tevékenységi\ arány\ =\ }{\dfrac{5\ nap}{10\ nap}}{ = 0{,}50}$$

Szorozza meg az eredményt 100 százalékkal, és 50%-os csökkenté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.

Tudj meg többet

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: