A GitLab ügynökökre szabná a nagy kódtárak kezelését

Az ügynökök új terhelést hoznak a Git számára

A GitLab fejlesztői blogja az Anthropic közelmúltbeli mérnöki bejegyzésére hivatkozik, amely szerint az ügynökalapú kódolás olyan terhelést helyezett a forráskód-kezelésre, amelyre a Git eredetileg nem készült fel. Az Anthropic monorepozitóriumában a beolvasztások száma a májusi napi körülbelül 2500-ról szeptemberre napi több mint 30 000-re emelkedett.

Az Anthropic erre válaszul saját, Scion nevű rendszert épített. A megoldás abból indul ki, hogy az ügyfelek csaknem mindegyike folyamatosan online működő ügynök. A vállalat egyértelművé tette, hogy a Scion nem a Git leváltására készült, és a Git-kompatibilitás sem volt tervezési célja. A rendszer azokat a skálázási problémákat célozza, amelyek a következő hat-tizenkét hónapban általánossá válhatnak.

A GitLab szerint a Git-platformok úgy is fejlődhetnek, hogy megőrzik a Git-kompatibilitást, miközben több műveletet végeznek a szerveroldalon.

Elosztott háttérrendszer a nagy repozitóriumokhoz

A GitLab következő generációs SCM-terve a fejlesztők által már használt Git protokollt tartja meg alapként. A háttérrendszer több számítási csomóponton skálázható, a felületek pedig az egyes feladatokhoz szükséges fájlokat és előzményeket kérhetik le az ügynökök számára. Ez csökkentheti a teljes repozitóriumok ismételt klónozásának szükségességét.

Az architektúra különválasztja a számítási kapacitást és a repozitóriumok tárolását. Az adatokat objektumtároló őrzi, a kéréseket pedig állapotmentes számítási csomópontok szolgálják ki helyi gyorsítótárakból. A kapacitás új csomópontok hozzáadásával bővíthető, az összetevők pedig a szabványos S3 API-n keresztül kommunikálnak.

A GitLab.com mellett önállóan kezelt környezetekben is futtatható lenne a rendszer, az olyan elszigetelt, úgynevezett air-gapped infrastruktúrákat is beleértve, ahol a repozitórium adatai nem hagyják el a szervezet saját környezetét. A GitLab korai belső tesztjei szerint egyes munkafolyamatok legfeljebb 50-szer gyorsabban futottak, feleannyi tokent használtak, és akár 1000-szer kevesebb hálózati forgalmat generáltak.

A cél a változtatások eredetének követése

A GitLab tervei szerint a forráskód-kezelésnek azt is rögzítenie kell, milyen utasítások és döntések formálták az ügynök munkáját. A vállalat olyan munkamenetnaplót készítene, amely a munka közben gyűjti össze ezt a kontextust.

Minden munkamenet kapcsolatban maradna az általa létrehozott commitokkal és merge requestekkel, squash vagy rebase után is. A felülvizsgálók így a módosításokat a hozzájuk tartozó háttérrel együtt láthatnák, és könnyebben azokra a pontokra összpontosíthatnának, amelyek emberi döntést igényelnek.

A tervek között szerepel az is, hogy az ágazati szabályok az ügynökazonosságokra is vonatkozzanak. A csapatok ez alapján szabályozhatnák, mely ügynökök módosíthatnak bizonyos kódrészleteket. A GitLab szerint ezek a képességek átláthatóbbá tennék, hogyan készült, vizsgálták felül és irányították az ügynökök munkája.

A Git közösségi fejlesztésére építenek

A GitLab a fejlesztéseit jelentős részben a Git közösségi projektjébe küldi vissza, mert a vállalat szerint a skálázási javítások így minden ügyfelet és szolgáltatót segíthetnek. A GitLab az utóbbi kiadásokban a Git legnagyobb vállalati hozzájárulójaként írja le magát.

A Git 2.54-ben a GitLab egy bővíthető felületet szállított az objektumtároláshoz, majd több objektum-adatbázis alrendszert is e felület mögé helyezett. A Git 2.56-ban a konzisztencia-ellenőrzések, a karbantartási műveletek és a packfile-ok előállítása is a felület mögé került. A vállalat ugyanezt az absztrakciót a nagy bináris fájlok kezelésére is kiterjesztené.

A GitLab korai hozzáférést kínál következő generációs SCM-megoldásához. Az érdeklődők saját, jelenleg nagy terhelést okozó repozitóriumaikon tesztelhetik a rendszert. A bejelentés jövőre vonatkozó állításokat is tartalmaz, amelyekre a vállalat szerint kockázatok, bizonytalanságok és más tényezők hatással lehetnek.