Not
Åtkomst till denna sida kräver auktorisation. Du kan prova att logga in eller byta katalog.
Åtkomst till denna sida kräver auktorisation. Du kan prova att byta katalog.
Roadmap
I följande avsnitt beskrivs nya funktioner som är under utveckling för vår Azure Boards-integrering med GitHub.
Kodningsagent: Utvecklare kan anropa Copilot direkt från ett Azure Boards-arbetsobjekt, välja en GitHub-mållagringsplats och -gren och skapa en pull-begäran som förblir länkad till det ursprungliga arbetsobjektet. Detta ger spårbarhet från början till slut, från arbetsplanering genom kodändringar.
Anpassade agenter för kodningsagent: När du använder kodningsagenten från ett arbetsobjekt kan användarna välja från en uppsättning anpassade agenter.
Fjärr-MCP-server: Vi introducerar en värdbaserad, fjärransluten MCP-server som exponerar en begränsad uppsättning verktyg från den lokala Azure DevOps MCP-servern. Den här första versionen fokuserar på grundläggande plattformsfunktioner och de vanligaste verktygen för arbetsobjekt, vilket gör det möjligt för kunder att integrera med Azure DevOps utan att köra eller hantera en lokal MCP-server.
Gränsökning: Den aktuella gränsen för GitHub-lagringsplatser som kan anslutas till ett enda Azure Boards-projekt ökas från 1 000 till 2 000 lagringsplatser, vilket ger större flexibilitet för större organisationer och komplexa GitHub-integreringar.
Levererade funktioner
Lokal MCP-server för Azure DevOps
Den lokala MCP-servern för Azure DevOps ger förbättrad inloggning och auktorisering, nya och förfinade verktyg och introducerar "domäner" för att hjälpa till att omfångsverktyg och hantera klientgränser.
Azure DevOps MCP Server fungerar som en brygga mellan AI-assistenter som GitHub Copilot och Azure DevOps, så att användarna på ett säkert sätt kan komma åt och interagera med arbetsobjekt, wikis, testplaner med mera i sin egen miljö.
Besök Azure DevOps MCP Server-lagringsplatsen för installationsinstruktioner, exempel och riktlinjer för bidrag.
Buggkorrigeringar förbättrar GitHub-integrering och säkerhet
Den här sprinten löste vi flera kritiska buggar för att förbättra säkerheten och tillförlitligheten för Azure Boards GitHub-integreringar:
- Flera problem som rör hantering av åtkomsttoken har åtgärdats, inklusive oförmågen att återkalla token, användning av för generösa omfång och avsaknad av tokenverifiering.
- Åtgärdade sårbarheter för behörighetseskalering i både GitHub-anslutnings- och grenskapandeflöden
- Beständig lagring av GitHub-PAT:n har tagits bort efter frånkoppling för att förhindra oavsiktlig åtkomst
- Eliminering av användningen av jokerteckensursprung i CORS-konfigurationen för att framtvinga strängare säkerhetskontroller.
- Förbättrad hemlig hantering genom att rotera GitHub-klienthemligheter och stoppa global delning mellan organisationer
- Förbättrad loggning och granskning vid borttagning av tjänstanslutningar
- Löst potentiella informationsläckor orsakade av felkonfigurerade webhooks
GitHub-integrering: Omnämnanden av pull-begäranden
Du kan nu använda ! omnämnanden för att referera till och diskutera GitHub-pull-begäranden direkt från alla stora textfält eller kommentarer.
GitHub-integrering: Stöd för tillståndsövergång
Vi har utökat stödet för att länka GitHub-pull-begäranden till Azure Boards-arbetsobjekt. Tidigare stöddes endast nyckelordet Fixes AB#{ID} . Med den här uppdateringen kan du nu använda {State or Category} AB#{ID} för att automatiskt överföra arbetsobjekt till önskat tillstånd vid sammanslagning.
Om beskrivningen av GitHub-pullbegäran innehåller ett tillståndsnamn (till exempel Validate AB#1234) uppdateras det länkade arbetsobjektets tillstånd som ett resultat. Om tillståndsnamnet inte känns igen kontrollerar vi om det matchar en tillståndskategori (till exempel Resolved). I så fall övergår arbetsobjektet till det första tillgängliga tillståndet inom den kategorin.
Om inget matchande tillstånd eller kategori hittas ignoreras nyckelordet och tillståndet för arbetsobjektet uppdateras inte.
Till sist fortsätter nyckelordet Fixes AB#{ID} att fungera som förväntat och återgår till standardläge "Stängt".
GitHub-integrering: Förbättringar som länkar till ändringar, grenar och pull-förfrågningar
Vi förbättrar kontinuerligt Boards + GitHub-integreringen för att minska användbarhetsluckorna och anpassa oss till den erfarenhet du är bekant med i Azure Repos.
Med den här uppdateringen införde vi flera förbättringar för att effektivisera hur grenar, pull requests och commits är länkade till arbetsobjekt:
När en GitHub-gren är länkad till ett arbetsobjekt länkas alla associerade pull-begäranden automatiskt. Du behöver inte använda AB#manuellt.
När en pull request har slagits ihop kopplas merge-commiten automatiskt till det relevanta arbetsobjektet.
Om grenen tas bort när pull-begäran har sammanfogats tas grenlänken bort automatiskt från arbetsobjektet.
De här förbättringarna gör det enklare att spåra din utvecklingsprocess och upprätthålla rena och uppdaterade arbetsobjektassociationer.
GitHub-integrering: Visa byggstatus för YAML-pipelines
Vi strävar efter att uppnå funktionsparitet mellan YAML och klassiska pipelines. En viktig funktion som saknades var möjligheten att tillhandahålla en "Integrerad i build"-länk när lagringsplatsen finns i GitHub. Med den senaste versionen har vi åtgärdat den här klyftan genom att lägga till ett alternativ i YAML-pipelineinställningar som du kan kontrollera:
När bygget har slutförts visas motsvarande länk automatiskt på de associerade arbetsobjekten, vilket förbättrar den totala spårbarheten.
GitHub-integrering: Länka sammanslagningscommitten
Nu länkar vi sammanfogningsuppgiften automatiskt till motsvarande arbetsobjekt när en pull-begäran har slutförts.
Öka gränsen för anslutna GitHub-lagringsplatser
Under de senaste månaderna har vi förbättrat både användarupplevelsen och skalbarheten för att ansluta dina GitHub-lagringsplatser till ett Azure DevOps-projekt. I den här sprinten höjde vi maxgränsen från 500 till 1 000 lagringsplatser, vilket ger dig ännu större kapacitet att hantera dina projekt.
Insikter om GitHub-pullbegäran
Vi har förbättrat integreringen mellan GitHub-pull-begäranden och Azure Boards. Förutom att visa öppna och stängda statusar kan du nu se om en pull-begäran är i utkastläge, behöver granskas och status för kontroller. Allt utan att behöva öppna pull-begäran.
Om du vill aktivera den här funktionen kontrollerar du att du går till boards-appen i GitHub för att acceptera de begärda uppdaterade behörigheterna för läs- och skrivåtkomst till Kontroller.
Förbättringar för sökning i GitHub-repositories
Att ansluta ett Azure DevOps-projekt till en GitHub-organisation är nu optimerat, särskilt för dem med tusentals lagringsplatser. Sök- och urvalsupplevelsen eliminerar risken för timeout-fel och gör anslutningsprocessen smidigare och effektivare.
Skapa GitHub-gren från arbetsobjekt
Nu kan du skapa en GitHub-gren direkt från ett arbetsobjekt i Azure DevOps. Länken "Ny GitHub-gren" är tillgänglig när en GitHub-anslutning har konfigurerats för projektet. Den här länken är tillgänglig i alla snabbmenyer för arbetsobjekt, inklusive formulär för arbetsobjekt, kort, kvarvarande uppgifter och frågor. Om du vill skapa en ny gren anger du grennamnet och väljer önskad lagringsplats och basgren.
Lägg till länk till GitHub commit eller pull-begäran
Länka arbetsobjekt till GitHub genom att söka efter och välja önskad lagringsplats och öka detaljnivån för att hitta och länka till den specifika pull-begäran eller incheckningen. Du behöver inte längre flera fönsterändringar och kopiera/klistra in (även om du fortfarande har det alternativet).
AB#-länkar på GitHub-pull-begäranden
Som en del av våra pågående förbättringar av Azure Boards + GitHub-integreringen förhandsgranskar vi en funktion som förbättrar upplevelsen med AB#-länkar. Med den här uppdateringen visas dina AB#-länkar nu direkt i avsnittet Utveckling i GitHub-pull-begäran. Det innebär att du kan visa länkade arbetsobjekt utan att behöva gå igenom beskrivning eller kommentarer, vilket ger enklare åtkomst till dessa AB#-länkar.
Dessa länkar är endast tillgängliga när du använder AB# i beskrivningen av pull-begäran. De visas inte om du länkar direkt från pull-begäran från arbetsobjektet. Om du tar bort AB#-länken från beskrivningen tas den också bort från utvecklingskontrollen.