Viktig information om Azure DevOps Server

---

| Utvecklarcommunity | Systemkrav och kompatibilitet | Licensvillkor | DevOps-blogg | SHA-256 hashar |

---

I den här artikeln hittar du information om den senaste versionen för Azure DevOps Server.

Mer information om hur du installerar eller uppgraderar en Azure DevOps Server-distribution finns i Azure DevOps Server Requirements (Azure DevOps Server-krav).

Om du vill ladda ned Azure DevOps Server-produkter går du till sidan Nedladdningar av Azure DevOps Server.

Direktuppgradering till Azure DevOps Server stöds från Azure DevOps Server 2019 eller Team Foundation Server 2015 eller senare. Om TFS-distributionen finns på TFS 2013 eller tidigare måste du utföra några interimssteg innan du uppgraderar till Azure DevOps Server 2022. Mer information finns på sidan Installera .

---

Versionsdatum för Azure DevOps Server: 9 december 2025

Azure DevOps Server RTW är en sammanslagning av felkorrigeringar och ändringar som stöder SQL Server 2025. Den innehåller alla funktioner i Azure DevOps Server RC som släpptes tidigare.

Du kan installera Azure DevOps Server direkt eller uppgradera från Azure DevOps Server 2022, 2020, 2019 eller Team Foundation Server 2015 eller senare.

Sammanfattning av nyheter i Azure DevOps Server RTW

• Sammanfogade lokaliseringsändringar.
• Ändringar som stöder SQL Server 2025.
• Ett problem har åtgärdats där långa namn på lagringsplatser eller grenar överskred kontrollens bredd i listrutan i konfigurationen av Code Tile widget på sidan Dashboards.
• Ett problem har åtgärdats där GitHubs PR-tillstånd felaktigt sparades som Stängd för både sammanfogade och icke-indelade pull-begäranden vid användning av webhooks. Systemet förlitar sig nu på den sammanställda booleska flaggan i webhookens payload för att korrekt registrera rätt tillstånd i databasen.
• Åtgärdade ett rekursivt egenskapsproblem som gjorde att Visual Studio låser sig under wit-länkningsscenarier (Work Item Tracking).
• Löste ett problem där sidan Agent Pool under Samlingsinställningar orsakade ett fel och misslyckades att läsas in när Analytics pausades eller inaktiverades. Sidan läses nu in korrekt oavsett analysstatus.

Versionsdatum för Azure DevOps Server RC: 7 oktober 2025

Sammanfattning av nyheter i Azure DevOps Server RC

Azure DevOps Server introducerar funktioner som vi tidigare har släppt i vår värdbaserade version av produkten. Du kan gå till enskilda avsnitt för att se alla nya funktioner för varje tjänst:

• Allmänt
• tavlor
• Repos
• Pipelines
• Testplaner
• Reporting
• Wiki

---

General

Kopiera kodblock till Urklipp

Som svar på din feedback i utvecklarcommunityn har vi introducerat knappen Kopiera till Urklipp för alla kodblock i renderad markdown. Den här förbättringen är tillgänglig på Wiki-sidor, markdown-filförhandsgranskningar i Repos, diskussioner och beskrivningar för pull-begäranden samt diskussioner om arbetsobjekt.

Behörighet för leveransplaner har lagts till

Som en del av våra pågående säkerhetsförbättringar har vi introducerat en ny behörighet på projektnivå för Hantera leveransplaner. Den här ändringen implementerades för att förhindra oavsiktlig läs-/skrivåtkomst för användare i gruppen Läsare.

Styrelser

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 är vi glada över att kunna introducera en ny funktion som effektiviserar hur AB#-länkar visas. Med den här uppdateringen visas AB#-länkar nu direkt i avsnittet Utveckling i GitHub-pull-begäranden, vilket gör det enklare att komma åt länkade arbetsobjekt utan att söka igenom beskrivningar eller kommentarer.

Dessa länkar visas bara när AB# ingår i beskrivningen av pull-begäran. Om du länkar direkt från ett arbetsobjekt visas de inte i avsnittet Utveckling. Om du tar bort AB#-länken från beskrivningen tas den dessutom bort från utvecklingskontrollen.

Förbättringar för sökning i GitHub-repositories

Vi har förbättrat processen för att ansluta ett Azure DevOps-projekt till en GitHub-organisation, särskilt fördelaktigt för dem med tusentals lagringsplatser. Tidigare kan du ha stött på utmaningar som timeout-fel och långa väntetider. Den här uppdateringen optimerar sök- och urvalsupplevelsen, vilket eliminerar risken för timeout-fel och gör anslutningsprocessen smidigare och effektivare.

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 det här gapet 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.

REST API-stöd för att ansluta GitHub-lagringsplatser

Vi introducerar nya REST API-slutpunkter som gör att du kan automatisera tillägg och borttagning av GitHub-lagringsplatser i dina Azure DevOps Projects. Dessutom ökade vi lagringsplatsens gräns per anslutning från 500 till 2 000 vid användning av dessa slutpunkter.

Dessa slutpunkter omfattar:

• Visa en lista över aktuella anslutningar
• Lista anslutna lagringsplatser
• Lägga till och ta bort lagringsplatser

Vi har också angett exempelkod som hjälper dig att komma igång.

Ändra för att ta bort områdes- och iterationsvägar

Att ta bort ett område eller en iterationssökväg kan vara störande. Det kan flytta arbetsobjekt till en ny sökväg och kan leda till att team förlorar åtkomst till sina tavlor och kvarvarande uppgifter. Trots varningar och uppmaningar tas sökvägar ibland bort utan att helt förstå konsekvenserna. För att åtgärda detta har vi ändrat beteendet: Sökvägar för område och iteration kan nu bara tas bort om de inte längre används av några arbetsobjekt.

Förbättrad tagghantering i arbetsobjektformulär

Tagghantering i Azure Boards har förbättrats för att ge en mer effektiv upplevelse. Borttagna taggar visas inte längre i den föreslagna listan över arbetsobjektformulär, vilket säkerställer att endast aktiva taggar visas.

Förbättrat bildstöd i kommentarer för arbetsobjekt

Vi har förbättrat vårt stöd för att klistra in bilder i kommentarer för arbetsobjekt. Nu kan du klistra in bilder direkt från källor som Microsoft Teams, e-postmeddelanden och Word-dokument i diskussionsavsnittet i ett arbetsobjekt

REST API-gräns för kommentarer till arbetsobjekt

För att förbättra säkerheten har en ny gräns angetts för hur många kommentarer som kan läggas till i arbetsobjekt via REST-API:et. Varje arbetsobjekt har nu stöd för högst 1 000 kommentarer via API:et. Den här begränsningen gäller endast rest-API:et och användarna kan fortfarande lägga till kommentarer manuellt via webbgränssnittet, även utöver tröskelvärdet på 1 000 kommentarer.

Gränsen för leveransplaner har ökat

Vi har ökat det maximala antalet leveransplaner per projekt från 1 000 till 1 500.

Repos

Ny inställning för att inaktivera skapandet av TFVC-lagringsplatser

Under de senaste åren har inga nya funktioner lagts till i Team Foundation Version Control (TFVC) eftersom Git har blivit det föredragna versionskontrollsystemet i Azure Repos. Alla de senaste förbättringarna av säkerhet, prestanda och tillgänglighet har gjorts uteslutande för Git-lagringsplatser, vilket leder till en kontinuerlig minskning av TFVC-användningen. Medan vissa fortfarande förlitar sig på TFVC och vi inte tänker ta bort den här funktionsuppsättningen, planerar vi att gradvis fasa ut TFVC för nya projekt och projektsamlingar, samt för projekt som för närvarande inte använder TFVC.

Som en del av den här övergången introducerar vi en ny inställning för "Inaktivera skapande av TFVC-lagringsplatser", vilket bara påverkar skapandet av nya TFVC-lagringsplatser och inte påverkar befintliga.

Stöd för användargränssnitt för Git-undermoduler

Många team använder aktivt Git-undermoduler för att organisera sin kodbas. Vi är glada över att kunna dela med oss av att vi har lagt till stöd för Git-undermoduler i files-hubben. Nu kan du direkt navigera till en undermodullagringsplats med bara ett enda klick, exakt till den specifika incheckning som refereras från ditt superprojekt. När de används som en undermodul stöds följande Git-tjänster: Azure Repos, GitHub, GitLab och Bitbucket. Flera URL-format som anges i .gitmodules-filen stöds också, inklusive absoluta HTTPS-, SSH- och relativa URL:er.

Ny panel för "Hälsa och användning" i lagringsplatsens filhubb

I takt med att Git-lagringsplatserna växer ackumuleras incheckningar, blobbar och andra data, vilket kan öka belastningen på Azure DevOps-infrastrukturen, vilket påverkar prestanda och användarupplevelse. Att upprätthålla en felfri lagringsplats är nyckeln till att säkerställa konsekventa prestanda och tillförlitlighet.

För att stödja detta övervakar vi nu flera faktorer som lagringsplatsstorlek, incheckningsfrekvens, innehåll och struktur. Om din lagringsplats börjar belasta infrastrukturen kan du få ett meddelande med rekommendationer för korrigerande åtgärder. Genom att hantera din lagringsplats hälsa kan du förhindra avbrott och säkerställa smidiga åtgärder.

Om du vill kontrollera lagringsplatsens hälsa går du till Azure Repos, > Files och väljer "Hälsa och användning" på ellipsmenyn för att få åtkomst till panelen Lagringsplatshälsa och användning.

Konfigurera målgrenar för pull-begäranden

Det kan vara svårt att hantera flera grenar på en lagringsplats, särskilt när du skapar nya pull-begäranden. Med den nya funktionen Konfigurera målgrenar för pull-begäranden kan du nu ange en lista över önskade målgrenar, vilket säkerställer att förslag på pull-begäranden är mer exakta och relevanta. Detta hjälper till att effektivisera arbetsflödet och minskar risken för att rikta in sig på fel gren. Om du vill använda den här funktionen skapar du en .azuredevops/pull_request_targets.yml-fil i lagringsplatsens standardgren. Den här YAML-filen bör innehålla en lista med titeln pull_request_targets med de grennamn eller prefix som matchar kandidatgrenarna. Till exempel:

pull_request_targets:
  - main
  - release/*
  - feature/*

I den här konfigurationen prioriteras huvudgrenen, men grenar som börjar med release/eller feature/ kommer också att övervägas när det är lämpligt. Konfigurationen tillämpas i följande scenarier:

• Förslag på pull-begäran: När du har push-överfört en gren till Azure DevOps kan Repos-sidan föreslå att du skapar en pull-begäran från den grenen, där målgrenen väljs dynamiskt.
• URL för pull-begäran: När du navigerar direkt till sidan för att skapa pull-begäran med hjälp av en sourceRef-parameter men utelämnar targetRef-parametern väljer Azure DevOps en målgren baserat på det här dynamiska valet.

Vi rekommenderar att du endast inkluderar grenar som skyddas av pull-begärandeprinciper för att säkerställa konsekvens i den första överordnade historiken för tipsincheckningen.

Stöd för sjöjungfrudiagram i markdown-fil

Markdown-filer som innehåller sjöjungfrusyntax återges nu som diagram i filförhandsgranskningar i lagringsfilens webbläsare och i pull-begäranden. Detta kan hjälpa dig att lägga till mer omfattande dokumentation till dina lagringsplatser.

Sök pull-begäranden efter rubrik på sida med PR-lista

Sidan med pull-begäranden innehåller nu ett filter efter PR-rubrik, vilket gör det enklare att hitta specifika pull-begäranden.

Gles utcheckning för Azure Repos

Kommandot git sparse-checkout stöds nu i YAML-utcheckningsaktiviteten, tillsammans med det partiella klonfiltret, för att förbättra lagringsplatsens utcheckningsprestanda. Du kan använda egenskaperna sparseCheckoutDirectories och sparseCheckoutPatterns.

Om du ställer in sparseCheckoutDirectories aktiveras konläge, där utcheckningsprocessen använder katalogmatchning. Alternativt kan du ange en sparseCheckoutPatterns som aktiverar ett icke-konläge, vilket möjliggör mer komplex mönstermatchning.

Om båda egenskaperna anges initierar agenten konläge med katalogmatchning. Om ingen av egenskaperna anges i utcheckningsaktiviteten inaktiveras den glesa utcheckningsprocessen. Problem som uppstår vid körning av kommandon resulterar i att utcheckningen misslyckas. YAML-exempel för gles kassakonläge:

    checkout: repo
    sparseCheckoutDirectories: src
YAML example for sparse checkout non-cone mode:
YAMLCopy

   checkout: repo
   sparseCheckoutPatterns: /* !/img 

Viktigt!

Den sparsamma utcheckningsfunktionen kräver agent v3.248.0 (v4.248.0 för .NET 8) eller senare versioner.

Du hittar agenten på sidan med releaser.

Gör regler för tvärrepositorier skiftlägeskänsliga

Tidigare visade förhandsgranskningen av grenkandidater för principer för korslager resultat på ett skiftlägesokänsligt sätt, även om grenmatchningen var skiftlägeskänslig. Den här inkonsekvensen skapade potentiell feljustering, eftersom det kan verka som om vissa grenar skyddades när de inte var det. För att lösa det här problemet har vi uppdaterat grenmönsterförhandsvisningen så att den överensstämmer med tillämpningen av policyns skiftlägeskänsliga beteende.

Tidigare:

After:

ÄNDRINGAR av TFVC-incheckningsprinciper

Ny version (19.254) av Microsoft.TeamFoundationServer.ExtendedClient NuGet-paketet

NuGet Microsoft.TeamFoundationServer.ExtendedClient-paketet uppdaterades med nya TFVC-principklasser och metoder.

Principändringar

Vi gör ändringar i hur TFVC-incheckningsprinciper lagras i Azure DevOps, vilket också innebär uppdateringar av hur NuGet Microsoft.TeamFoundationServer.ExtendedClient kommunicerar med tjänsten. Om TFVC-projektet använder incheckningsprinciper migrerar du dessa principer till det nya formatet. Det finns två sätt att göra detta:

1. Använda Visual Studio.

Varning

Farliga vissa konsekvenser av en åtgärd.: Se till att du har uppdaterat Visual Studio till den senaste versionen innan du fortsätter (VS 2022, VS 2019 och VS 2017 med minimala versioner 17.14 Preview 3, 17.13.6, 17.12.7, 17.10.13, 17.8.20, 16.11.46, 15.9.72 stöder de nya principerna).

Om du vill skapa nya principer med hjälp av Visual Studio-projektadministratören bör du öppna Inställningar –> Teamprojekt –> Källkontroll –> Incheckningsprincip och lägga till ny princip (utan "föråldrad" markering) med samma parametrar som gamla:

2. Om du använder anpassad implementering av Microsoft.TeamFoundationServer.ExtendedClient för att kommunicera med servern följer du migreringsguiden. Migreringen krävs för att TFVC-incheckningen ska vara kompatibel med framtida Azure DevOps-versioner. För närvarande förblir både gamla (föråldrade) och nya principer giltiga och funktionella. Mer information om framtidsplaner finns i vårt blogginlägg.

Förbättring av GetRepository API

Vi har lagt till egenskapen creationDate i svaret från Lagringsplatser – Hämta lagringsplats-API:et som returnerar lagringsplatsens skapandedatum. Egenskapen är tillgänglig i API-versionerna 7.2-preview och senare.

Förbättringar av fråge-API:et för pull-begäranden

Vi har introducerat en ny etikettegenskap i svaret på Pull Request Query – Hämta API. Nu kan du ange om du vill inkludera etiketter (taggar) för relaterade pull-begäranden i varje fråga. En ny Include-egenskap är tillgänglig – om den är inställd på Etiketter innehåller svaret etiketter för de angivna PR:erna. Om det lämnas som null inkluderas inte etiketterna. Om du vill förhindra oavsiktliga fel kontrollerar du att NotSet inte uttryckligen har tilldelats . Detta resulterar i felaktig begäran.

Anmärkning

Resursanvändningen för berikning av etiketter beror på antalet tilldelade etiketter och deras längd. Att begära etiketter kan påverka hastighetsbegränsningen och öka nätverksbelastningen. För att optimera prestandan rekommenderar vi att du undviker onödiga etikettbegäranden.

Exempel på begäranens nyttolast

{
    "queries": [
        {
            "type": "lastMergeCommit",
            "include": "Labels",
            "items": [ 
                "0d6c9b2b524113113fced41aecbf8631a4649dec"
            ]
        },
        {
            "type": "lastMergeCommit",
            "items": [
                "b524113113f0dd41aecbf8631a4649dec6c9b2ce"
            ]
        }
    ]
}

Pipelines

TFX verifierar om en uppgift använder en End of Life Node-löpare

Taskförfattare använder TFX för att publicera tillägg. TFX har uppdaterats för att utföra valideringar på andra Node runner-versioner.

Tillägg som innehåller uppgifter med hjälp av en Node-version som når slutet av sin livslängd (EOL) (upp till och med Node 16) ser den här varningen:

Task < TaskName > är beroende av en aktivitetslöpare vilken är i slutet av sin livscykel och som kommer att tas bort i framtiden. Författare bör granska vägledningen för noduppgradering: https://aka.ms/node-runner-guidance

Få åtkomst till Azure Service Bus från pipelines med hjälp av Microsoft Entra-ID-autentisering

Nu kan du använda Microsoft Entra ID-autentisering för att få åtkomst till Azure Service Bus från Azure Pipelines. På så sätt kan du dra nytta av Azure RBAC för detaljerad åtkomstkontroll.

Identiteter som har åtkomst till Azure Service Bus måste beviljas en av de inbyggda Azure-rollerna för Azure Service Bus på den aktuella Service Bus.

PublishToAzureServiceBus@2 uppgift

De nya PublishToAzureServiceBus@2 uppgifterna kan konfigureras med hjälp av en Azure-tjänstanslutning. Skapa en Azure-tjänstanslutning och fyll i egenskaperna serviceBusQueueName och serviceBusNamespace för den nya uppgiften:

- task: PublishToAzureServiceBus@2
  inputs:
    azureSubscription: my-azure-service-connection
    serviceBusQueueName: my-service-bus-queue
    serviceBusNamespace: my-service-bus-namespace
    useDataContractSerializer: false
    messageBody: |
      {
        "foo": "bar"
      }

Serveraktiviteter

Anpassade serveruppgifter (agentlösa) som använder ServiceBus-körning kan ange en Azure-tjänstanslutning som EndpointId och utelämna ConnectionString. Se Redigering av serveraktivitet.

TFX verifierar om en uppgift använder en End of Life Node-löpare

Taskförfattare använder TFX för att publicera tillägg. TFX har uppdaterats för att utföra valideringar på andra Node runner-versioner.

Tillägg som innehåller uppgifter med hjälp av en Node-version som når slutet av sin livslängd (EOL) (upp till och med Node 16) ser den här varningen:

Task < TaskName > är beroende av en aktivitetslöpare vilken är i slutet av sin livscykel och som kommer att tas bort i framtiden. Författare bör granska vägledningen för noduppgradering: https://aka.ms/node-runner-guidance

Uppgifter som använder en end-of-life Node runner-version för att utföra avger varningar.

Pipelineuppgifter som förlitar sig på en nodversion som inte längre underhålls kommer att börja få varningar: Uppgiften TaskName-versionen är beroende av en Node-version (10) som har nått slutet av sin livscykel. Kontakta pluginägaren för en uppdaterad version av uppgiften. Uppgiftsansvariga bör gå igenom vägledningen för noduppgradering: https://aka.ms/node-runner-guidance För att undertrycka dessa varningar kan du ange en miljö- eller pipelinevariabel på antingen pipeline-nivå (jobb) eller aktivitetsnivå. Till exempel:

variables:
  AZP_AGENT_CHECK_IF_TASK_NODE_RUNNER_IS_DEPRECATED: false

DockerCompose@0 använder Docker Compose v2 i v1-kompatibilitetsläge

Docker Compose v1 når sin livslängd och tas bort från värdbaserade agenter 24 juli 2024. Vi har uppdaterat DockerCompose@0 uppgift för att använda Docker Compose v2 i v1-kompatibilitetsläge om Docker Compose v1 inte är tillgängligt på agenten.

Kompatibilitetsläget löser dock inte alla kompatibilitetsproblem. Se Migrera till Compose V2. Vissa användare behöver mer tid för att uppdatera sina Docker Compose-projekt för Docker Compose v2-kompatibilitet. I sådana fall följer du de här anvisningarna för att använda DockerComposeV0-aktiviteten med docker-compose v1. Obs! Den här guiden baseras på dokumentationen för att installera Compose som en fristående applikation. Använd docker-compose v1 på Windows. Lägg till PowerShell-steget i din pipeline för att ladda ner docker-compose v1.29.2 och använda detta med DockerComposeV0-uppgiften på Windows:

variables:
    dockerComposePath: C:\docker-compose

steps:
- powershell: |
    mkdir -f $(dockerComposePath)
    # GitHub now requires TLS1.2. In PowerShell, run the following
    [Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12
    Start-BitsTransfer -Source "https://github.com/docker/compose/releases/download/1.29.1/docker-compose-windows-x86_64.exe" -Destination $(dockerComposePath)\docker-compose.exe
  displayName: Download docker-compose
- task: DockerCompose@0
  inputs:
    containerregistrytype: 'Azure Container Registry'
    dockerComposeFile: '**/docker-compose.yml'
    action: 'Run a Docker Compose command'
    dockerComposeCommand: 'run'
    dockerComposePath: $(dockerComposePath)\docker-compose.exe
Use docker-compose v1 on Linux
Add the bash step to your pipeline to download Docker-Compose v1.29.2 and use it with the DockerComposeV0 task on Linux:
YAMLCopy
variables:
    dockerComposePath: /tmp/docker-compose

steps:
- bash: |
    sudo mkdir $(dockerComposePath)
    sudo curl -SL https://github.com/docker/compose/releases/download/1.29.2/docker-compose-linux-x86_64 -o $(dockerComposePath)/docker-compose
    sudo chmod 755 $(dockerComposePath)/docker-compose
  displayName: Download docker-compose
- task: DockerCompose@0
  inputs:
    containerregistrytype: 'Azure Container Registry'
    dockerComposeFile: $(Build.SourcesDirectory)/DockerComposeV0/docker-compose.yml
    action: 'Run a Docker Compose command'
    dockerComposeCommand: 'run'
    dockerComposePath: $(dockerComposePath)/docker-compose

Testplaner

Test- och feedbacktillägg i Manifest V3

Vi är glada över att kunna presentera en ny uppdatering av Azure DevOps Test and Feedback-tillägget för både Chrome och Edge. Den här uppdateringen övergår vår implementering från Manifest V2 till V3, i linje med Googles utfasningsschema för Manifest V2. Även om huvudfunktionerna i tillägget förblir oförändrade, förbättrar uppdateringen både säkerhet och prestanda.

Mer information finns i vårt senaste blogginlägg om den här uppdateringen. Test- och feedbacktillägg i Manifest V3

Azure Test Runner version 1.2.2

Azure Test Plans släppte en korrigering i 1.2.2 för ett nytt problem i testplaner där Azure Test Runner (ATR) upplevde startfel i Chrome version 130. Det här problemet uppstod på grund av chromes extra stöd för icke-speciella schema-URL:er, vilket påverkade ATR-användarflödet. Med den här uppdateringen löses regressionsfelet och ATR-funktionerna återställs. Mer information om den här regressionsbuggen finns i den här problemspåraren i Chromium.

Vi rekommenderar att du använder webbprogram för förbättrade funktioner. Om du hittar några funktioner som saknas i webbappen vill vi gärna höra av dig. Dela din feedback med oss!

Sömlös integrering av byggpipeline för testfallskörning

Vi har förenklat körningsprocessen för testfall genom att sömlöst integrera konfigurationer av byggpipelines. Byggdefinitioner och ID:er som anges på testplansnivå sprids nu automatiskt till Web Runner, vilket eliminerar behovet av manuell konfiguration varje gång. Den här förbättringen sparar tid och ökar effektiviteten så att du kan fokusera på mer kritiska uppgifter.

Återställa borttagna testplaner och testpaket med hjälp av REST API

Återställ enkelt borttagna testplaner och testpaket med nya API:er för självbetjäning. Vi introducerar GET- och PATCH-API:er som gör att du kan söka efter borttagna testplaner eller paket och återställa dem tillsammans med deras underordnade objekt – allt utan att behöva kundsupport. Med dessa API:er kan du snabbt återställa av misstag borttagna testarbetsobjekt, vilket minskar stilleståndstiden och förbättrar produktiviteten. Körningsartefakter återställs inte, men alla relaterade testplaner, sviter och testfall kan enkelt föras tillbaka till din arbetsyta. Den här självbetjäningsfunktionen ger dig större kontroll över testhantering och effektiviserar återställningsprocessen, vilket gör det snabbare och effektivare att återställa kritiska testtillgångar.

Exportera testfall med anpassade kolumner i XLSX

Nu kan du exportera testfall med anpassade kolumner i XLSX. Baserat på din feedback stöder testplaner export av testfall med anpassade kolumner, vilket ger dig större flexibilitet och kontroll över de data du delar och analyserar. Den här förbättringen hjälper dig att skräddarsy exporten efter dina behov, så att den information du exporterar är relevant och användbar.

Nya sorteringsfunktioner i katalogen Testplaner

Katalogen Testplaner erbjuder nu förbättrade sorteringsalternativ! Med den här uppdateringen kan du snabbt organisera varje kolumn alfanumeriskt, vilket ger ett effektivt sätt att hitta och komma åt dina data.

Ångra teststeg i webb- och skrivbordsprogram

Ta kontroll över testfallskörningen med det nya alternativet Ångra. Du kan enkelt återställa teststegstatusar med ett enkelt dubbelklicka, vilket ger dig mer flexibilitet och kontroll under testkörningar. Inga fler omstarter av testfall för att åtgärda oavsiktliga klick – det är bara att ångra och fortsätta arbetsflödet utan avbrott.

Vi introducerar också tangentbordsvänliga navigerings- och hjälpmedelsförbättringar för att säkerställa att den här funktionen fungerar sömlöst för alla användare, inklusive de som förlitar sig på hjälpmedelstekniker. Den här förbättringen hjälper dig att spara tid, minska frustrationen och fokusera på att köra tester effektivt.

Publicera kodtäckningsresultat v2-uppgiftsförbättringar

Med den här versionen innehåller vi flera förbättringar av v2-uppgiften:

• Utökat stöd för olika kodtäckningsformat, inklusive: .coverage,.covx,.covb,.cjson,.xml,.lcov och pycov1.

• Generering av en omfattande cjson-fil (och en kodtäckningsrapport) som innehåller detaljerad information om kodtäckning, till exempel filnamn, rader som omfattas/inte omfattas osv.

Stöd för diff-täckning (PR-täckning): v2 kan generera pr-kommentarer för difftäckning för flera språk i samma pipeline.

v2-aktiviteten stöder nu aktiviteten Byggkvalitetskontroll, som inte stöds i v1-aktiviteten.

Stöd för YAML-pipelines i testplaner

Förutom klassiska pipelines kan du nu använda YAML-pipelines när du konfigurerar dina testplaner eller kör automatiserade tester från testplaner.

Den här begäran har prioriterats baserat på följande förslagstickets från Utvecklargemenskapen.

• Tillåt att YAML-pipeline används i testplansinställningar

• Köra automatiserade tester från Azure-testplaner med YAML-pipeline

Rapportering

Data om rollup kolumner som är tillgängliga i backlog

Vi har uppdaterat aggregatkolumner för att visa den senaste tillgängliga datan. Tidigare kan dessa kolumner visas tomma för ofta uppdaterade arbetsobjekt, vilket orsakar förvirring. Du ser också en tidsstämpel som anger när data senast uppdaterades. Även om en viss fördröjning i analysbearbetningen är normal, syftar dessa förbättringar till att ge transparens och en bättre upplevelse när du arbetar med rollupkolumner.

 

Wiki-sida

Förbättra klistring av HTML-baserat innehåll i Wiki-sidor

Vi har gjort det enklare att klistra in HTML-baserat innehåll i Wikis. Nu konverteras HTML-element som länkar, listor, tabeller, bilder, Excel-blad, Microsoft Teams-meddelanden, e-postmeddelanden och Azure Data Explorer-frågor automatiskt till Markdown-syntax för smidigare redigering.