A Microsoft fejlesztése a DevOps használatával

A Microsoft arra törekszik, hogy a One Engineering System használatával egy Git-elágaztatási és kiadási folyamaton alapuló, szilárd DevOps-folyamattal hozza létre és telepítse az összes Microsoft-terméket. Ez a cikk kiemeli a gyakorlati megvalósítást, azt, hogy a rendszer hogyan skálázható a kis szolgáltatásoktól a nagy platformfejlesztési igényekig, valamint a rendszer különböző Microsoft-csapatok általi használatának tanulságait.

A szabványosított fejlesztési folyamat bevezetése ambiciózus vállalkozás. A Különböző Microsoft-szervezetek követelményei nagyban eltérnek egymástól, és a szervezeteken belüli különböző csapatok követelményei mérete és összetettsége skálázható. Ezeknek a változatos igényeknek a kielégítése érdekében a Microsoft törzs alapú elágaztatási stratégiát használ a termékek gyors fejlesztéséhez, rendszeres üzembe helyezéséhez és a módosítások biztonságos, éles környezetbe történő bejuttatásához.

A Microsoft a One Engineering System részeként platformmérnöki alapelveket is alkalmaz.

A Microsoft kiadási folyamata

Minden szervezetnek meg kell egyeznie egy szabványos kódkiadási folyamattal, hogy biztosítsa a csapatok közötti konzisztenciát. A Microsoft kiadási folyamata magában foglalja a DevOps-folyamatokat a fejlesztéstől a kiadásig. A kiadási folyamat alapvető lépései az ágazás, leküldés, lekéréses kérelem és egyesítés.

Branch

Hiba kijavításához vagy funkció implementálásához a fejlesztő létrehoz egy új ágat a fő integrációs ágon kívül. A Git egyszerűsített elágaztatási modell ezeket a rövid élettartamú témakörágakat hozza létre minden kód-hozzájáruláshoz. A fejlesztők korán kötelezettséget vállalnak, és feature flagek használatával elkerülik a hosszú ideig futó funkcióágakat.

Átirányítás

Ha a fejlesztő készen áll a változások integrálására és a csapat többi tagjának való elküldésére, leküldi a helyi ágat a kiszolgáló egyik ágára, és megnyit egy lekéréses kérelmet. A több száz fejlesztővel rendelkező adattárak több száz ágon dolgoznak, és elnevezési konvenciót használnak a kiszolgálói ágakhoz a keveredés és az ágburjánzás enyhítése érdekében. A fejlesztők általában létrehoznak users/<username>/feature nevű ágakat, ahol <username> a fiókjuk neve.

Lekéréses kérelem

A lekéréses kérelmek vezérlő témakörága egyesül a fő ágban, és gondoskodik arról, hogy az ágszabályzatok teljesüljenek. A lekéréses kérelem folyamata létrehozza a javasolt módosításokat, és egy gyorstesztet futtat. Az első és a második szintű tesztcsomagok öt perc alatt körülbelül 60 000 tesztet futtatnak. Ez nem a Microsoft teljes tesztmátrixa, de elég ahhoz, hogy gyorsan magabiztosságot adjon a lekéréses kérelmekben.

Ezután a csapat többi tagja áttekinti a kódot, és jóváhagyja a módosításokat. A kódellenőrzés ott veszi fel a helyét, ahol az automatizált tesztek abbahagyták, és különösen hasznos az architekturális problémák észleléséhez. A manuális kódvizsgálatok biztosítják, hogy a csapat többi mérnöke is betekinthessen a változásokba, és hogy a kódminőség továbbra is magas legyen.

Egyesítés

Miután a lekéréses kérelem megfelel az összes buildszabályzatnak, és a véleményezők kijelentkeztek, a témakörág összeolvad a fő integrációs ágba, és a lekéréses kérelem befejeződött.

Az egyesítés után más elfogadási tesztek is futnak, amelyek több időt vesznek igénybe. Ezek a hagyományos utóellenőrzési tesztek alaposabb ellenőrzést végeznek. Ez a tesztelési folyamat jó egyensúlyt teremt a lekéréses kérelmek felülvizsgálata során végzett gyors tesztek és a teljes tesztlefedettség között a kiadás előtt.

Különbségek a GitHub Flow-tól

A GitHub Flow egy népszerű csomagtartóalapú fejlesztési kiadási folyamat a szervezetek számára a Git skálázható megközelítésének implementálásához. Egyes szervezetek azonban úgy vélik, hogy az igényeik növekedésével el kell térniük a GitHub Flow egyes részeitől.

A GitHub Flow gyakran figyelmen kívül hagyott része például az, hogy a lekéréses kérelmeket termelési környezetbe kell üzembe helyezni tesztelési célból, mielőtt egyesítenék őket a fő ágba. Ez a folyamat azt jelenti, hogy az összes lekéréses kérelem az üzembe helyezési sorban várakozik az egyesítéshez.

Egyes csapatok több száz fejlesztővel dolgoznak folyamatosan egyetlen adattárban, akik naponta több mint 200 lekéréses kérelmet hajthatnak végre a főágban. Ha minden lekéréses kérelemhez a világ több Azure-adatközpontjának üzembe helyezése szükséges tesztelés céljából, a fejlesztők a szoftverek írása helyett az ágak egyesítésére várnak.

Ehelyett a Microsoft-csapatok tovább fejlesztenek a főágban, és időzített kiadásokra kötik fel az üzembe helyezéseket, általában háromhetes sprint-ütemhez igazítva.

Megvalósítás részletei

A Microsoft kiadási folyamatának néhány fontos implementációs részlete:

Git-adattár stratégiája

A különböző csapatok különböző stratégiákkal kezelik a Git-adattárakat. Egyes csapatok a kódjuk többségét egy Git-adattárban tartják. A kód összetevőkre van bontva, amelyek mindegyike saját gyökérszintű mappában található. A nagy összetevők, különösen a régebbi összetevők több alösszetevővel is rendelkezhetnek, amelyek külön almappákkal rendelkeznek a szülőösszetevőn belül.

Mellékadattárak

Egyes csapatok a kiegészítő adattárakat is kezelik. A GitHubon fejlesztik például az ügynököket és a feladatokat, a VS Code-bővítményt és a nyílt forráskódú projekteket . A konfigurációmódosítások egy külön tárhelyre kerülnek be. Más csomagok, amelyektől a csapat függ, más helyekről származnak, és a NuGeten keresztül lesznek felhasználva.

Monorepo vagy multirepo

Míg egyes csapatok egyetlen monolitikus adattárat választanak, a monolitikus adattárat, más Microsoft-termékek több adattárat használnak. A Skype-ban például több száz kis adattár található, amelyek különböző kombinációkban összefűzve számos különböző ügyfelet, szolgáltatást és eszközt hoznak létre. Különösen a mikroszolgáltatásokat használó csapatok esetében a több adattár lehet a megfelelő megközelítés. A monolitként indult régebbi termékek esetében a monorepo megközelítés általában a legegyszerűbb áttérés a Gitre, és ez tükröződik a kódszervezetükben.

Kiadási ágak

A Microsoft kiadási folyamata biztosítja, hogy a fő ág mindig építhető maradjon. A fejlesztők rövid életű témakörágakban dolgoznak, amelyek a következőbe egyesülnek main: . Ha egy csapat készen áll a szállításra, akár a futam végén, akár egy nagyobb frissítéshez, új kiadási ágat indít el a fő ágról. A kiadási ágak soha nem egyesülnek vissza a fő ágba, ezért előfordulhat, hogy fontos változtatásokat igényelnek.

Az alábbi ábra a rövid élettartamú ágakat kék színnel és a kiadási ágakat fekete színnel jeleníti meg. Egy olyan ág jelenik meg pirossal, amelynek véglegesítését cseresznyeszedésre van szükség.

Ágszabályzatok és engedélyek

A Git ágkezelési szabályok segítenek érvényesíteni a kiadási ág felépítését, és tisztán tartani a fő ágat. Az ágszabályzatok például megakadályozhatják a fő ágba irányuló közvetlen leküldéseket.

Az ághierarchia rendezettsége érdekében a csapatok engedélyekkel tiltják le az ágak létrehozását a hierarchia gyökérszintjén. Az alábbi példában mindenki létrehozhat ágakat olyan mappákban, mint a felhasználók/, szolgáltatások/és csapatok/. Csak a kiadáskezelők rendelkeznek engedéllyel ágak létrehozására a kiadások alatt/, és egyes automatizálási eszközök rendelkeznek engedéllyel az integrációhoz/ mappához.

Git-adattár munkafolyamata

Az adattáron és az ágszerkezeten belül a fejlesztők napi munkájukat végzik. A munkakörnyezetek csapatonként és egyénileg is nagy mértékben változnak. Egyes fejlesztők a parancssort részesítik előnyben, mások például a Visual Studiót, mások pedig különböző platformokon dolgoznak. A Microsoft-adattárakban érvényben lévő struktúrák és szabályzatok szilárd és konzisztens alapot biztosítanak.

Egy tipikus munkafolyamat a következő gyakori feladatokat foglalja magában:

Új funkció létrehozása

Egy új funkció létrehozása a szoftverfejlesztői feladat alapvető eleme. A folyamat nem Git-részei közé tartozik a telemetriai adatok megvizsgálása, egy terv és egy specifikáció készítése, valamint a tényleges kód megírása. Ezután a fejlesztő elkezdi használni az adattárat a legújabb véglegesítés mainszinkronizálásával. A fő ág mindig felépíthető, ezért garantáltan jó kiindulópont. A fejlesztő kivesz egy új szolgáltatáságat, módosítja a kódokat, véglegesíti, leküldi a kiszolgálóra, és elindít egy új lekéréses kérelmet.

Ágszabályzatok és -ellenőrzések használata

Lekéréses kérelem létrehozásakor az automatizált rendszerek ellenőrzik, hogy az új kód épül-e, nem tör-e fel semmit, és nem sérti-e a biztonsági vagy megfelelőségi szabályzatokat. Ez a folyamat nem akadályozza meg, hogy más munkák párhuzamosan történjenek.

Az elágaztatási szabályzatok és -ellenőrzések sikeres buildelést igényelhetnek, beleértve az átment teszteket, az érintett kódok tulajdonosai általi bejelentkezést , valamint számos külső ellenőrzést a vállalati szabályzatok ellenőrzéséhez a lekéréses kérelmek végrehajtása előtt.

Integráció a Microsoft Teams programmal

Számos csapat konfigurálja a Microsoft Teams-integrációt, amely bejelenti a fejlesztők csapattagjainak küldött új lekéréses kérelmet. Az érintett kódok tulajdonosai automatikusan hozzáadódnak véleményezőkként. A Microsoft-csapatok gyakran használnak opcionális véleményezőket olyan kódokhoz, amelyeket sokan érintenek, például a REST-ügyfélgenerálást és a megosztott vezérlőket, hogy szakértő szemmel láthassa ezeket a módosításokat.

Üzembe helyezés funkciójelzőkkel

Miután a véleményezők, a kódtulajdonosok és az automatizált rendszerek elégedettek lettek, a fejlesztő lezárhatja a lekéréses kérelmet. Egyesítési ütközés esetén a fejlesztő útmutatást kap az ütközéshez való szinkronizáláshoz, a javításhoz és a módosítások újraküldéséhez. Az automatizálás ismét a rögzített kódon fut, de az embereknek nem kell újra kijelentkezniük.

Az ág egyesül main, és az új kód a következő sprintben vagy fő kiadásban lesz üzembe helyezve. Ez nem jelenti azt, hogy az új funkció azonnal megjelenik. A Microsoft funkciójelzők használatával leválasztja az új funkciók üzembe helyezését és kitettségét.

Még ha a funkciónak még egy kicsit több munkára van szüksége, mielőtt készen áll a megjelenítésre, nyugodtan továbbléphet main , ha a termék buildel és üzembe helyez. Ha be van jelentkezve main, a kód egy hivatalos build részévé válik, ahol újra tesztelik, megerősítik, hogy megfelelnek a szabályzatnak, és digitálisan aláírták.

Az eltolás balra a problémák korai felismerésére szolgál

Ez a Git-munkafolyamat számos előnnyel jár. Először is, egyetlen fő ág létrehozása gyakorlatilag kiküszöböli az egyesítési adósságot. Másodszor, a pull request folyamata egy közös pontot jelent a tesztelés, a kódellenőrzés és a hibaészlelés érvényesítésére a fejlesztési folyamat korai szakaszában. Ez a bal oldali váltási stratégia segít lerövidíteni a visszajelzési ciklust a fejlesztőknek, mert percek, nem órák vagy napok alatt észleli a hibákat. Ez a stratégia az újrabontás megbízhatóságát is biztosítja, mivel minden módosítást folyamatosan tesztelünk.

Jelenleg egy több mint 200 lekéréses kérelemmel rendelkező termék napi 300+ folyamatos integrációs buildet hozhat létre, ami 24 óránként több mint 500 tesztet jelent. Ez a tesztelési szint a törzsalapú elágaztatási és kiadási munkafolyamat nélkül lehetetlen lenne.

Kiadás a futam mérföldköveinél

Az egyes futamok végén a csapat létrehoz egy kiadási ágat a főágból. A 129-es futam végén például a csapat létrehoz egy új kiadási ágat releases/M129. A csapat ezután éles környezetbe helyezi a sprint 129 ágat.

A kiadási ág létrehozása után a fő ág nyitva marad a fejlesztők számára, hogy egyesítsék a módosításokat. Ezek a módosítások három héttel később lesznek üzembe helyezve a következő sprint üzembe helyezés során.

Gyorsjavítások kiadása

Néha a módosításoknak gyorsan éles környezetbe kell mennie. A Microsoft általában nem ad hozzá új funkciókat a futam közepén, de néha gyorsan szeretne hibajavítást hozni a felhasználók letiltásának feloldásához. A problémák lehetnek kisebbek, például elírások, vagy elég nagyok ahhoz, hogy rendelkezésre állási problémát vagy élő webhelyeseményt okozzanak.

Ezeknek a problémáknak a kijavítása a normál munkafolyamattal kezdődik. A fejlesztő létrehoz egy ágat a main-ből, átnézeti a kódot, és végrehajtja a lekérési kérelmet az egyesítéshez. A folyamat mindig azzal kezdődik, hogy először main módosítjuk. Ez lehetővé teszi a javítás gyors létrehozását és helyi érvényesítését anélkül, hogy a kiadási ágra kellene váltania.

A folyamat követése azt is garantálja, hogy a módosítás bekerül a main-ba, ami kritikus fontosságú. A kiadási ágban egy hiba kijavítása anélkül, hogy a változást visszavezetnénk main, azt jelentené, hogy a hiba ismét előfordulna a következő üzembe helyezés során, amikor a sprint 130 kiadási ágak származnak main. Könnyen elfelejtheti frissíteni main, amikor kimaradás során zavar és stressz merül fel. A változtatások elsőként való bevezetése main azt jelenti, hogy a változtatások mindig megtalálhatók mind a fő ágban, mind a kiadási ágban.

A Git-funkciók lehetővé teszik ezt a munkafolyamatot. Ha azonnal üzembe szeretné helyezni a módosításokat az éles környezetben, miután a fejlesztő egyesít egy lekéréses kérelmet main, a lekéréses kérelem oldalával módosíthatja a kiadási ágat. Ez a folyamat létrehoz egy új pull requestet, amely a kiadási ágra irányul, és visszaküldi az imént egyesített main tartalmat.

A cherry-pick funkció használatával gyorsan megnyílik egy pull request, amely biztosítja az ágszabályzatok nyomon követhetőségét és megbízhatóságát. A cherry-pick a kiszolgálón is végrehajtható anélkül, hogy le kellene tölteni a kiadási ágakat egy helyi számítógépre. A kiszolgálón módosításokat végezhet, egyesítési ütközéseket javíthat, vagy kisebb módosításokat hajthat végre a két ág közötti különbségek miatt. A Teams közvetlenül a böngészőalapú szövegszerkesztőből vagy a lekéréses kérelem egyesítési ütközési bővítményéből szerkesztheti a módosításokat a fejlettebb felhasználói élmény érdekében.

Ha egy lekéréses kérelem megcélozza a kiadási ágat, a csapatkód újra megvizsgálja, kiértékeli az ágszabályzatokat, teszteli a lekéréses kérelmet, és egyesíti azt. Az egyesítés után a javítás percek alatt üzembe lesz helyezve a kiszolgálók első gyűrűjében . Innen a csapat fokozatosan üzembe helyezi a javítást több fiókra az üzembehelyezési körök használatával. Ahogy a módosítások egyre több felhasználóra települnek, a csapat figyeli a sikerességet, és ellenőrzi, hogy a módosítás kijavítja-e a hibát, miközben nem vezet be semmilyen hiányosságot vagy lassulást. A javítás végül az összes Azure-adatközpontban üzembe lesz helyezve.

Ugrás a következő futamra

A következő három hétben a csapat befejezi a funkciók hozzáadását a 130-as sprinthez, és felkészül a módosítások üzembe helyezésére. Létrehozzák az új kiadási ágat releases/M130 az main alapján, majd telepítik azt.

Ezen a ponton valójában két ág van a termelésben. A gyűrűalapú üzembe helyezéssel biztonságosan hozhatja el a változásokat az éles környezetben, a gyors gyűrű megkapja a sprint 130-at, a lassú gyűrűs kiszolgálók pedig a 129-ben maradnak, miközben az új változtatásokat éles környezetben érvényesítik.

Az üzembe helyezés közepén bekövetkező változások gyorsjavításához két különböző kiadás, a sprint 129-es kiadás és a sprint 130-es kiadás gyorsjavítása szükséges. A csapat portolja és telepíti a gyorsjavítást mindkét kiadási ágra. A 130-as ág gyorsjavítással újra üzembe kerül azokra a gyűrűkre, amelyek már frissítve lettek. A 129 ág újra üzembe helyezi a gyorsjavítást a külső gyűrűkre, amelyek még nem frissítettek a következő sprint verziójára.

Az összes gyűrű üzembe helyezése után a régi sprint 129 ágat elhagyják, mert a sprint 129 ágba gyorsjavításként bevezetett módosítások a main-ben is megtörténtek. Tehát ezek a változások az releases/M130 ágban is megjelennek.

Összefoglalás

A kiadási folyamat modellje annak a lényege, hogy a Microsoft hogyan fejleszt a DevOps segítségével az online szolgáltatások nyújtásához. Ez a modell egy egyszerű, törzsalapú elágaztatási stratégiát használ. Ahelyett azonban, hogy a fejlesztők elakadtak egy üzembehelyezési sorban, és arra várnak, hogy egyesítsék a módosításokat, a Microsoft kiadási folyamata lehetővé teszi a fejlesztők számára a folyamatos munkát.

Ez a kiadási modell lehetővé teszi az új funkciók rendszeres üzembe helyezését az Azure-adatközpontokban a Microsoft-kódbázisok mérete és a rajtuk dolgozó fejlesztők száma ellenére. A modell lehetővé teszi a gyorsjavítások gyors és hatékony élesbe állítását is.