GitHub agent appokkal vinné a fejlesztési munkafolyamatokat a pull requestekbe

Kevesebb váltás a pull request körül

A GitHub bejegyzése szerint a fejlesztők gyakran több külön eszköz között viszik át ugyanazt a kontextust, amikor egy változtatást felmérnek, megvalósítanak, kivezetnek és kiadás előtt ellenőriznek. A vállalat erre mutat példát az agent appokkal, amelyek a GitHubon belül, ugyanazon platformra és futtatási környezetre építve működnek, mint a GitHub saját Copilot cloud agentje.

A bemutatott helyzet egy termék ingyenes próbaidős beléptetési folyamatáról szól, ahol felmerül, hogy az „invite your teammates” lépést opcionálissá kellene tenni. A GitHub példája négy kérdés köré rendezi a munkát: helyes-e maga a módosítás, tiszták-e az érintett függőségek, hogyan lehet biztonságosan bevezetni, és biztonságos-e éppen telepíteni.

Amplitude, Endor Labs, LaunchDarkly és PagerDuty a GitHubon belül

A GitHub példájában a fejlesztő először az Agents fülön kérdezi meg az Amplitude agentet, hogy a csapatmeghívási lépés teljesítése összefügg-e a későbbi tölcsérbeli sikerrel, szegmensekre bontva. A válasz alapján a csapatfelhasználóknál erősebb a későbbi megtartással való kapcsolat, míg az egyéni felhasználóknál nincs ilyen korreláció. Ez indokolja az újraszűkítést: az egyéni regisztrációknál elhalasztanák a lépést, a csapatoknál megtartanák.

A megvalósítás közben a Copilot egy vázlatos pull requestet nyit. Mivel a módosítás az onboardingfolyamat függőségeit is érinti, a fejlesztő egy kommentben az Endor Labs agentet kéri meg, hogy vizsgálja meg az érintett függőségeket. A GitHub leírása szerint az agent azonosítja a módosított függőségeket, ellenőrzi az ismert sérülékenységeket és a szélesebb csomagkockázatot, majd a pull requestben válaszol.

A bevezetésnél a LaunchDarkly agent kap feladatot: hozzon létre egy defer-team-invite nevű, boolean típusú feature flaget, amelynek alapértéke false, célcsoportja a solo-intent regisztráció, a bevezetés pedig internal, majd 5%, 25% és 100%. A GitHub szerint az agent létrehozza a flaget a LaunchDarklyban, és commitként hozzáadja a kódmegvalósítást felülvizsgálatra. Ha a célkörnyezet jóváhagyást igényel, közvetlen módosítás helyett jóváhagyási kérelmet hoz létre.

Kiadási kockázat és Marketplace-elérhetőség

A kiadás előtt a példában a fejlesztő a PagerDuty agentet kéri meg, hogy mérje fel a pull request telepítési kockázatát az onboarding szolgáltatáshoz. Az agent a GitHub leírása szerint összerendeli a repozitóriumot a PagerDuty szolgáltatással, ellenőrzi az aktív incidenseket, áttekinti az előző 90 nap eseményeit, és összeveti a pull request fájljait a korábbi incidensekben érintett területekkel. A bemutatott esetben a kockázat alacsony, nincs aktív incidens, és nincs érdemi kapcsolat a jelenlegi változtatásokkal, ezért a javaslat a folytatás.

A GitHub szerint az agent appok a GitHub Marketplace-en érhetők el. Telepítés után engedélyezhetők a szervezet számára, majd feladathoz rendelhetők egy issue-ban, megemlíthetők pull request kommentben elemzéshez vagy művelethez, illetve kiválaszthatók a repozitórium Agents fülén.

A bejegyzés további induló agent appokat is felsorol: a Packfiles agentje a back­logot olvassa és migrációs stratégiát épít, a Miro agentje a vizuális együttműködést kapcsolja össze a kódmunkafolyamatokkal, a Bright Security agentje end-to-end dinamikus biztonsági tesztelést kezel a GitHubon belül, a SonarQube agentje elemzést, quality gate-eket és javítást hoz az agent sessionökbe, az Octopus Deploy agentje pedig telepítési hibákat azonosíthat, diagnosztizálhat és oldhat meg.

Mit jelent ez a fejlesztőknek

A GitHub üzenete szerint az agent appok nem váltják le a meglévő eszközöket: a fejlesztőcsapatok továbbra is használhatják az Amplitude, a LaunchDarkly, az Endor Labs és a PagerDuty szolgáltatásait. A változás az, hogy ezek az eszközök közvetlenül a GitHub-munkafolyamatokban jelenhetnek meg, amikor a kontextusukra vagy képességeikre szükség van.

A forrás alapján ez főként a kontextusváltás csökkentéséről szól. A termékadatok ellenőrzése, a függőségek kockázatának vizsgálata, a feature flag beállítása és a telepítési kockázat felmérése ugyanahhoz a pull requesthez kapcsolódva történhet. Így a GitHub a fejlesztők és az agentek közös koordinációs felületévé válhat a munka következő lépéseinek eldöntéséhez.