Gitre áll át a Microsoft

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.

A Gitlab mint DevSecOps platform (x) Gyere el Radovan Baćović (Gitlab, Data Engineer) előadására a november 7-i DevOps Natives meetupon.

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.