Hogyan biztosítja a Microsoft a szoftvereket a DevOpsszal?

A Microsoft több évtizedes tapasztalattal rendelkezik a rendkívül skálázható szolgáltatások éles környezetekben történő biztosításában. Ahogy a Microsoft szolgáltatásai és környezetei bővültek, a teljesítési gyakorlatuk is folyamatosan bővült. Számos Microsoft-ügyfél is elfogadta és kihasználta ezeket a hatékony kézbesítési eljárásokat. Az alábbi alapvető DevOps-alapelvek és folyamatok bármilyen modern szoftverkézbesítési erőfeszítésre alkalmazhatók.

A DevOps kézbesítési folyamatainak megvalósítása érdekében a Microsoft a következő kezdeményezéseket fogadta el:

• Összpontosítson a szervezeti gondolkodásmódra és a teljesítés ütemére.
• Önálló, elszámoltatható csapatokat hozhat létre, amelyek rendelkeznek a funkciókkal, tesztelik és biztosítják a funkciókat.
• Válts a termelési környezetben végzett tesztelés és monitorozás felé.

Fókuszban a kézbesítés

A gyorsabb szállítás nyilvánvaló előnyt jelent, amelyet a szervezetek és a csapatok egyszerűen mérhetnek és értékelhetnek. A DevOps jellemző üteme rövid sprint ciklusokat foglal magában, amelyek rendszeres üzembe helyezést tartalmaznak a produkciós környezetben.

A rövid futamok termékstabilitásának hiányától tartva egyes csapatok stabilizálási időszakokat kompenzáltak a futamciklusok végén. A mérnökök a lehető legtöbb funkciót akarták szállítani a sprint során, ezért olyan teszttartozást halmoztak fel, amelyet a stabilizáció során kellett megoldaniuk. Azok a csapatok, amelyek a futam során kezelték az adósságukat, támogatniuk kellett az adósságot felépített csapatokat. A többletköltségek a szállítási folyamatokon keresztül a gyártásig jutnak el.

A stabilizálási időszak eltávolítása gyorsan javította a csapatok adósságának kezelését. Ahelyett, hogy a kulcskarbantartási munkákat a stabilizációs időszakba tolták volna, azok a csapatok, amelyek adósságot halmoztak fel, a következő sprint során az adósságcéljaik elérésére kellett összpontosítsanak. Csapatok gyorsan megtanulták kezelni a tesztelési adósságukat a sprintek során. A funkciók akkor érhetők el, ha már bizonyítottak, és megérik az üzembe helyezés költségeit.

Folyamatok teljes automatizálása

A fejlesztési csapatok jelentős része azonnal nyerhet, ha teljesen automatizálja a folyamatokat a kódtárból az éles környezetbe. Az Automatizálás magában foglalja a folyamatos integrációs (CI) kiadási folyamatokat, az automatizált tesztelést és a folyamatos teljesítést (CD).

Előfordulhat, hogy a Teams kerüli az üzembe helyezést, mert nehéz, de minél ritkábban telepítik, annál nehezebb. Minél több idő van a telepítések között, annál több probléma halmozódhat fel. Ha a kód nem friss, üzembe helyezési adósság van.

A gyakori üzembe helyezéssel egyszerűbb kisebb adattömbökben dolgozni. Ez az ötlet utólag nyilvánvalónak tűnhet, de abban az időben ellenintuitívnak tűnhet. A gyakori kiadások arra is ösztönzik a csapatokat, hogy a hatékonyabb és megbízhatóbb üzembehelyezési eszközök és folyamatok létrehozását priorizálják.

Házon belüli eszközök használata

A Microsoft az általuk buildelt kiadáskezelési rendszert használja, és az ügyfeleknek szállítja. Egyetlen befektetés javítja a csapat termelékenységét és a Microsoft termékeit is. A másodlagos rendszer használata lesiphonozná a fejlesztési és szállítási sebességet.

A csapat önállósága és elszámoltathatósága

Nincsenek konkrét fő előrehaladási mutatók (KPI-k) a csapat termelékenységét vagy teljesítményét mérik, vagy hogy egy szolgáltatás jó úton halad-e. A csapatoknak képesnek kell lenniük saját terveik és hátralékaik kezelésére, miközben módot kell találniuk a szervezeti célokhoz való igazodásra.

Fontos, hogy közvetlenül kommunikáljon a csapatokkal a haladás nyomon követése érdekében. Az eszközöknek elő kell segíteniük a kommunikációt, de a kommunikáció legátlátottabb módja a beszélgetés.

Szolgáltatások rangsorolása

Fontos cél, hogy a funkciókra összpontosítsunk. Az ütemezések felmérhetik, hogy egy adott időszakban mennyi csapat és egyén képes megfelelően teljesíteni a feladatokat, de egyes funkciók korábban is elérhetők lesznek, és néhány később is elérhető lesz. Csapatok rangsorolhatják a munkát, hogy a legfontosabb funkciók a produkciós környezetbe kerüljenek.

Mikroszolgáltatások használata

A mikroszolgáltatások különböző technikai előnyöket kínálnak, amelyek javítják és egyszerűsítik a teljesítést. A mikroszolgáltatások természetes határokat is biztosítanak a csapat tulajdonjogához. Ha egy csapat önállóan fektet be egy mikroszolgáltatásba, rangsorolhatja a funkciók megvalósítását és az adósságkezelést. A Teams az olyan tényezőkre összpontosíthat, mint a verziószámozás, függetlenül a mikroszolgáltatástól függő általános szolgáltatásoktól.

Fő munka

A mérnökök külön ágakban dolgoznak. Az egyes ágak egyesítési adóssága mindaddig növekedett, amíg a mérnök meg nem próbálta integrálni az ágát a főágba. Minél több csapat és mérnök volt ott, annál nagyobb lett az integráció.

Ahhoz, hogy az integráció gyorsabban, folyamatosan és kisebb adattömbökben történjen, a mérnökök most már a főágban dolgoznak. A Gitre való költözés egyik fő oka az egyszerűsített elágaztatási Git-ajánlatok volt. A belső tervezés előnye a mélyági hierarchia és a hulladék megszüntetése volt. Az integrálással töltött időt most már a szállításba öntötték.

Funkciójelzők használata

Egyes funkciók még nem fejeződnek be teljesen a sprint üzembe helyezéséhez, de továbbra is kihasználhatják az éles környezetben történő tesztelés előnyeit. A Teams egyesítheti és üzembe helyezheti ezt a kódot funkciójelzőkkel , hogy bekapcsolja a funkciót bizonyos felhasználók, például a fejlesztői csapat vagy a korai bevezetést végzők egy kis szegmense számára. A funkciójelzők a teljes felhasználói bázissal kapcsolatos problémák kockázata nélkül szabályozzák az expozíciót, és segíthetnek a csapatoknak annak meghatározásában, hogy a funkció befejeződik-e és hogyan.

Tesztelés éles környezetben

A produkciós környezetekben történő tesztelés felé való eltolódás segít biztosítani, hogy az előzetes tesztek érvényesek legyenek, és hogy a folyamatosan változó produkciós környezetek készen álljanak a telepítések kezelésére.

Műszeres tesztek és metrikák

Függetlenül attól, hogy egy alkalmazást hol telepítik, fontos mindent instrumentálni. Az instrumentáció nemcsak a problémák azonosításában és megoldásában segít, hanem felbecsülhetetlen értékű információt biztosít a használatról és arról, hogy mit érdemes a jövőben hozzáadni.

Rugalmassági minták tesztelése

Az összetett telepítések egyik kockázata a kaszkádelvű meghibásodások, amikor az egyik komponens meghibásodása a függő komponensek meghibásodását okozza, és ez így folytatódik, amíg az egész rendszer összeomlik. Fontos tisztában lenni azzal, hogy hol találhatók a kritikus meghibásodási pontok (SPOF-ek). Meg kell érteni, hogyan háríthatók el, és tesztelni kell a kárenyhítési folyamatokat, különösen éles környezetben.

A megfelelő metrikák kiválasztása

A metrikák tervezése nehéz lehet. Gyakori hiba, hogy túl sok metrikát vesznek fel, hogy ne maradjon ki semmi. Ez azonban egy adott igénynek nem megfelelő metrikák értékének figyelmen kívül hagyásához vagy bizalmatlanságához vezethet. Ehelyett a Microsoft csapatai időt vesznek igénybe a siker méréséhez szükséges adatok meghatározásához. Előfordulhat, hogy a Teams metrikákat ad hozzá vagy módosít, de a cél megértése az elejétől megkönnyíti ezt a folyamatot.

A metrika alapja mellett a csapatok mérlegelik, hogy mire van szükségük a mérőszám méréséhez. A felhasználói nyereség sebessége vagy gyorsulása például hasznosabb metrika lehet, mint a felhasználók teljes száma. A metrikák projektenként eltérőek, de a leghasznosabbak azok, amelyek üzleti döntéseket ösztönözhetnek.

Metrikák használata a munka irányításához

A Microsoft a legmagasabb vezetői szintű értékelésekkel rendelkező metrikákat is tartalmaz. Hathetente a szervezetek bemutatják, hogyan haladnak az egészségi állapot, az üzleti teljesítmény, a forgatókönyvek és az ügyféltelemetria terén. A szervezetek megvitatják a metrikákat a vezetőkkel és a csapatokkal.

A szervezet egész területén a csapatok megvizsgálják az aktívan részt vevő felhasználói metrikákat, hogy meghatározzák, mit jelentenek a funkcióik szempontjából. A csapatok nem csak a funkciók bevezetésére összpontosítanak, hanem arra is, hogy figyelemmel kísérjék, hogyan használják azokat az emberek. A csapatok ezen metrikák segítségével módosíthatják a hátralékokat, és megállapíthatják, hogy a funkcióknak több munkára van-e szükségük a célok eléréséhez.

Kézbesítési irányelvek

• Soha nem egyenes vonal az A-ból B-be jutni, és B sem a vég.
• Mindig lesznek visszalépések és hibák.
• Tekintse meg a visszalépéseket tanulási lehetőségként a folyamat adott részének végrehajtásához szükséges taktikák módosításához.
• Idővel minden csapat fejleszti a DevOps-gyakorlatokat a tapasztalatokra építve és a változó igényeknek való megfeleléshez igazodva.
• A legfontosabb, hogy az érték átadására összpontosítson mind a végfelhasználók, mind a kézbesítési folyamat számára.