Mellékleteink: HUP | Gamekapocs
Keres

Gitre áll át a Microsoft

Gálffy Csaba, 2017. február 08. 11:30

A belső átszervezésekkel együtt a szervezeti együttműködés is sokat változott a Microsofton belül, ezzel mindennél sürgetőbbé vált egy egységes, közös fejlesztői eszközrendszer kiépítése. A korábbi sokszínűséget egységes megoldás váltja, meglepő elemekkel.

Az elmúlt másfél évben alaposan átalakította belső fejlesztői szoftverkörnyezetét a Microsoft - lebbentette fel a fátylat az újdonságokról Brian Harry, a cég szoftvermérnöke hivatalos blogposztban. A rendkívül érdekes írás azt részletezi, hogy hogyan vezetett be egységes ALM-megoldást a vállalat a teljes fejlesztői közösségnek, a Windowstól az Office-on át az Azure-ig.

"Kissé kaotikus volt, ha őszinték akarunk lenni"

A Microsoft hivatalos álláspontja eddig az volt, hogy szoftverfejlesztésre a cég saját rendszerét, a Team Foundation Servert (TFS) használja, amely a Visual Studióval szoros együttműködésben képes forráskód-menedzsmentre, projektmenedzsmentre, automatizált build folyamatok végrehajtására és számtalan más feladatra is. A gyakorlatban azonban ez nem épp így volt: csak néhány csapat használta ki teljesen a TFS-t, sok fejlesztői csoport saját egyedi eszközöket készített a mindennapi munkához.

Az eredmény szélsőséges sokszínűség, rengeteg párhuzamos, hasonló feladatot ellátó eszköz fejlesztése, a csapatok közötti kooperáció megnehezítése. A HR-ben is gondot okozott ez, külső fejlesztőket fel kell készíteni a Microsoft-eszköztárak használatára, de még a csapatok közötti váltásokat is megnehezíti ez a sokszínűség.

Erre lett megoldás az egységes műszaki rendszer (One Engineering System, 1ES) bevezetése. Ez egy olyan közös fejlesztői eszközrendszer, amely a forráskód- és verziókezeléstől a feladatok kiosztásáig, a buildek és release-ek készítéséig, tesztelésig mindent képes ellátni. De ennél sokkal komplexebb feladatokra is képes, mint a telemetria, a bétatesztek, a lokalizáció/fordítás, aláírások kezelése, statikus elemzés, stb. Gyakorlatilag ez a rendszer képes összefogni a szoftverfejlesztéssel kapcsolatos teljes tevékenységkört - pontosan ez is az 1ES célja.

Saját és hozott anyagból

Az 1ES kidolgozásakor az egyik legfontosabb doktrína, hogy "azt használjuk, amit fejlesztünk és azt fejlesztjük, amit használunk" - vagyis a cég ahol lehet, saját bolti termékeit igyekszik bevezetni. Ez persze nem teljesen fedi a valóságot, de követendő célként már megfogalmazódott az 1ES tervezésekor.

A fentiek alapján az új fejlesztői eszközrendszer alapját a Visual Studio Team Services adja, ez az a gerinc, amelyre a többi szolgáltatást felfűzte a csapat. Ehhez kapcsolódóan a feladatok kiosztására is a Team Services-t használja a Microsoft, az elmúlt egy évben néhány ezerről 50 ezer fölé nőtt a rendszert használók száma, köztük a teljes Windows csapattal - amely önmagában több millió feladattal növelte az adatbázist, viszont mára gyakorlatilag a fejlesztés koordinálása ezen az egy rendszeren keresztül zajlik.

A legizgalmasabb kérdés azonban nem ez, hanem a forráskód-kezelés. Ebben ugyanis a Microsoft mérnökei erősen megosztottak - a TFVC (Team Foundation Version Control), a saját, belső használatú Source Depot, a Mercurial és a Git is szóba került. Az erőteljes vitát nem is sikerült megnyugtatóan, konszenzussal zárni, felsőbb döntésre végül a Git lett a nyertes, ez lesz belátható időn belül a Microsoft szabványos verziókezelő megoldása.

Skálázni a Gitet

A Gittel kapcsolatos nagy probléma viszont a skálázódás. A Microsoft szoftveres projektjei a legnagyobbak közé tartoznak a világon, sok százmillió soros forráskóddal, sok tízezer állománnyal. A Git viszont elosztott verziókezelő, lényege, hogy minden kliens rendelkezik a teljes repóval a helyi gépen - ez elképzelhetetlen lenne egy Windows méretű projekt esetében, csak a szinkronizálás néhány száz gigabájt, a változások keresése pedig perceket vesz igénybe.

(forrás: MSPowerUser)

Az egyik első ötlet a komponensekre bontás, vagyis a teljes projekt helyett egy-egy komponens képezzen egy-egy repót (kódtárat). Ez nagyon jól működik moduláris rendszerek (például microservice-alapú backend) esetében, egy szorosan összefüggő kódbázisnál azonban nem jó megoldás. Ráadásul gyakran fordul elő, hogy egy fejlesztő a teljes kódbázist érintő módosítás-hullámot végez, ez pedig nem hatékony sok repón át.

Maradt tehát az egységes repó skálázása. Erre legalább két, később zsákutcának bizonyuló próbálkozást tettek a Microsoft mérnökei. Az egyik (és legtovább jutó) próbálkozás a Git almodulok (submodule) használatával összefogni sok repót egy szuperrepóvá. Mintegy 6 hónapnyi munka után vált egyértelművé, hogy ez a megközelítés nem fog működni, a rendszer túl komplex és túl törékeny lett, amely rosszul kezelte az egyedi eseteket.

Egy évvel ezelőtt ezért a csapat újra nekifutott a problémának: hogyan lehet a Gitet skálázni egyetlen repóval úgy, hogy a teljes Windows kódbázist ki tudja szolgálni az összes fejlesztő és build gép felé? "Mi lenne, ha virtualizálnánk a Gitet?" - teszi fel a kérdést Harry, egész pontosan virtualizálnánk a tárhelyet. Ez lett a Git Virtual File System (GVFS), amely lehetővé teszi, hogy egy kliens úgy klónozza a repót, hogy nem kell letöltenie a teljes forrást. Ahogy a fejlesztő elkezdi használni a rendszert, úgy a GVFS intelligens módon letölti transzparensen a megnyitott állományokat. A megközelítés egyetlen hátránya, hogy ehhez folyamatos hálózati kapcsolatot igényel, annak elvesztésével csak a már lementett fájlokhoz lehet hozzáférni - ez azonban elfogadható kompromisszumnak bizonyult.

A hozzáférés virtualizálásának nagy előnye, hogy a Git számára szinte teljesen transzparens lehet, vagyis úgy működhet, hogy a git.exe csupán minimális változást igényel. A Microsoft reményei szerint ezeket egyébként a Git szabad szoftveres közössége elfogadja majd, így azok bekerülnek majd a hivatalos kiadásba is, így nem kell forkolni (vagy párhuzamos pályán tartani) a Microsoft-féle megoldást. Ilyen változás például, hogy a Git szeret hozzányúlni a forrásfájlokhoz akkor is, amikor igazából erre semmi szükség nincs - ez kisebb, lokálisan tárolt projektek esetben nem gond, a GVFS-megközelítéssel azonban ez nem kompatibilis. Ezeket a fejlesztéseket és módosításokat a microsoftos csapat átadta a Git projektnek és várhatóan hamarosan bekerül a nyílt forráskódú szoftverbe.

Szintén szabad szoftver a GVFS, amelyet GitHubon publikált is már a Microsoft a szokásos MIT licenc alatt. A kulcselem, a GVFS kernel-szintű drivere azonban zárt kódú, tulajdonosi szoftver, így az implementáció nem egészében szabad szoftver. A megoldás szabadon kipróbálható, azonban Windows 10-re és VS 2015 Community Editionre (minimum) van hozzá szükség - a teljes lista a projekt oldalán olvasható. Fontos megjegyzés, hogy ekkora méretnél már van értelme a szerveroldali optimalizációnak is, ezeket a Microsoft nem hozta nyilvánosságra, a GVFS-hez szükséges protokollt azonban közzétette.

A rendszer egyébként a cégen belül már működik, a több, mint 40 Windows Source Depot szerveren tárolt kódot már sikerült migrálni a Git repóba, a használatbavétel pedig mindössze néhány perc.

Az "OneCore" hozadéka

Az új fejlesztés egyébként a Microsoft nagy átalakításának egyik "mellékterméke". A 2015-ös átszervezéssel ugyanis három nagy fejlesztési csoport jött létre, ezek egyike a Windows and Devices, amely immár egyetlen ernyő alatt vonja össze a változatos Windows-kiadásokat, a kliens-Windowst, az Xbox szoftverét, a mobilos (ARM) kiadást és a szerveres verziókat is. A nagy összevonás nem csak strukturális volt, a cég már korábban elkezdte a forkolt Windows-kiadások összevonását és egy közös kódalapra húzni - ez volt a hírek "Egy Windows" stratégia.

Eszerint minden Windows termék egy közös alapra épül, amelyet platformtól függően további rétegek egészítenek ki. Így a PC-s Windows esetében a közös alapra kerül rá a Win32-es futtatókörnyezet, az Xbox One esetében pedig a konzol-specifikus elemek. Ugyanígy a mobilos vagy szerveres Windowsnál is modulárisan áll össze a végső rendszer. Ennek megvalósítása elképesztően nehéz feladat volt, a rengeteg, egymással függőségi viszonyban lévő alrendszert szét kellett bontani. Tipikus példa erre az Internet Explorer, amelyre rengeteg egyéb komponens épült, így a szerveres kiadásból sem lehetett kihagyni a böngészőt.

Az ilyen függőségek megszüntetésével vált valósult meg az OneCore koncepciója: az a közös alap, ami minden Windows-kiadás alapját képezi. Az erre épülő rétegek pedig minden olyan elemet tartalmaznak, amely az adott funkcionalitáshoz szükséges - például a Windows 10 Mobile az okostelefonos működéshez szükséges részeket, az Xbox One pedig a konzolos elemeket. Hogy ez mekkora eredmény, azt nehéz túlragozni, a Microsoft tényleg elérte, hogy egyetlen közös magja legyen az összes Windows-kiadásnak, a HoloLenstől a notebookig. Persze fejlesztői szempontból ez nem sokat jelent, az egyes kiadások változatos futtatókörnyezeteket és API-kat támogatnak, a Microsoftot azonban sokkal agilisabb vállalattá teszi. Akit részletesebben is érdekel az elvégzett munka, annak érdemes az Ars Technica cikkét fellapozni.

Facebook

Mit gondolsz? Mondd el!

Adatvédelmi okokból az adott hír megosztása előtt mindig aktiválnod kell a gombot! Ezzel a megoldással harmadik fél nem tudja nyomon követni a tevékenységedet a HWSW-n, ez pedig közös érdekünk.