A Vercel Agent már Slackben is képes vizsgálni és javítani a hibákat

A Vercel Agent mostantól Slackben is elérhető, ahol a csatornák és szálak beszélgetéseiből kiindulva vizsgálhatja az incidenseket, kódot írhat és változtatásokat készíthet elő. A Vercel for Slack nyilvános bétája Pro és Enterprise csapatok számára indult el.
- A Vercel Agent már Slack-csatornákban, szálakban és közvetlen üzenetekben is használható.
- Az Agent hozzáfér a Vercel-projektek telepítéseihez, buildjeihez, naplóihoz és metrikáihoz.
- Pull requesteket vizsgálhat, hibákat javíthat és döntéseket tesztelt pull requestté alakíthat.
- A kód- és konfigurációmódosítások csak jóváhagyott terv után indulhatnak el.
- A nyilvános béta Pro és Enterprise csapatok számára érhető el.
A beszélgetésből indul a hibakeresés
A Vercel augusztus 19-én jelentette be, hogy a Vercel Agent beköltözött a Slackbe. A felhasználók egy csatornában, szálban vagy közvetlen üzenetben említhetik meg az @Vercel fiókot, az ügynök pedig elolvassa az addigi beszélgetést, és a Vercel-projektekhez kapcsolódó környezettel együtt válaszol.
Az Agent hozzáfér a telepítések, buildfolyamatok, naplók, metrikák, konfigurációk, kódellenőrzések és pull requestek releváns információihoz. Így egy csapat közvetlenül abban a szálban kérdezhet rá, miért hibásodott meg egy telepítés, mi okoz futásidejű hibát, vagy melyik módosítás állhat egy incidens hátterében.
A Vercel példája szerint egy telepítés után megugró pénztárhibáknál az Agent összevetheti a hibák időpontját a telepítéssel, azonosíthatja az érintett pull requestet, majd megmutathatja, melyik fájl módosítása milyen viselkedéshez vezetett. A diagnózis ugyanabban a csatornában jelenik meg, ahol a riasztás érkezett, így a csapat tagjai ugyanazt az információt látják.
Kódírás, pull requestek és üzemeltetési műveletek
A Vercel Agent nem áll meg a hibák magyarázatánál. Segíthet a sikertelen build- és CI-folyamatok javításában, a pull requestek felülvizsgálatában, valamint egy beszélgetésben meghozott döntés tesztelt pull requestté alakításában.
A pull requestek ellenőrzésekor a szál teljes beszélgetése kontextusként szolgál. A Vercel egyik példájában az Agent a diffen kívül talált hibát, amely miatt ugyanaz a cím kétszer jelent meg a felületen. Ha a csapat úgy dönt, hogy szükség van javításra, az Agent módosíthatja a pull requestet, a változtatás pedig jóváhagyásra váró javaslatként érkezik vissza.
Az üzemeltetésben az Agent többek között telepítések visszaállítását, konfigurációfrissítést, funkciókapcsolók kezelését és szokatlan használati problémák felderítését készítheti elő. A rendszer alapértelmezés szerint csak olvas, és nem lépi túl a kérelmező jogosultságait.
Minden változtatás jóváhagyáshoz kötött
Ha egy feladat kódot vagy konfigurációt módosítana, az Agent előbb tervet készít. Ebben leírja, mi fog történni, melyik projektet érinti a művelet, és milyen hatókörben hajtja végre. A változás csak a csapat egyik tagjának jóváhagyása után indul el.
A jóváhagyott műveletet az Agent a saját identitásával hajtja végre, a napló pedig rögzíti, ki kérte, ki hagyta jóvá és mi futott le. A Vercel szerint a jóváhagyás után az Agent ideiglenes hozzáférést kap a terv végrehajtásához, majd ismét csak olvasási módban működik.
Egy bemutatott esetben egy frissítés után elavult adatokat mutató gyorsítótárat kellett üríteni. A terv csak az érintett útvonalra és annak alútvonalaira vonatkozott, a webhely többi részének gyorsítótára érintetlen maradt, és a művelet addig nem futott le, amíg valaki jóvá nem hagyta.
Elérhetőség és használat
A Vercel for Slack nyilvános bétája Pro és Enterprise csapatok számára érhető el. A használathoz a Slack alkalmazást a Vercel Marketplace-ben kell megnyitni, össze kell kapcsolni a kívánt Slack-munkaterületet, majd engedélyezni kell a hozzáférést. Az első használatkor a Vercel-fiókba is be kell jelentkezni.
A szolgáltatás a Vercel Agent díjszabását követi. A béta alatt korlátozott számú egyszerű kérés ingyenes, a fizetős munkát igény szerint számlázzák. A Vercel külön figyelmeztet arra, hogy az Agent hibázhat, ezért a javasolt változtatásokat jóváhagyás előtt át kell nézni.
A felhasználók kezdetben egyszerű kérdésekkel próbálhatják ki az eszközt, például egy hibás build vagy egy vizsgált hiba kapcsán. A csapat így ugyanabban a beszélgetésben kaphat diagnózist, dönthet a következő lépésről, majd jóváhagyhatja a kód- vagy konfigurációmódosítást.


