Dela via

Nya analysrapporter och Azure Boards-appen för Slack – Sprint 155 Update

  • Artikel

I Sprint 155-uppdateringen av Azure DevOps presenterar vi nya Azure Boards-rapporter för att göra det enklare för dig att spåra viktiga mått för ditt team. De nya rapporterna visas på fliken Analys i naven hubbarna för Boards, Backlog och Sprint. Rapporterna är fullständigt interaktiva och du kan justera dem efter dina behov.

Vi är också glada att kunna presentera den nya Azure Boards-appen för Slack. Med appen kan du övervaka aktivitet i arbetsuppgifter och skapa arbetsuppgifter från din Slack-kanal.

Mer information finns i listan Funktioner nedan.

Nyheter i Azure DevOps

Funktioner

Allmänt:

Azure Boards:

Azure Repos:

Azure Artifacts:

Azure Pipelines:

  YAML-pipelines med flera steg

  Värdbaserade virtuella datorer

Kubernetes

Testa

  Azure-upplevelsen

Integreringar

Allmänt

Bjud in GitHub-samarbetspartner i Azure DevOps

Nu kan du bjuda in medarbetare från GitHub till Azure DevOps när du är inloggad med din GitHub-identitet. Du kan söka efter och bjuda in andra GitHub-användare från startsidan för Project och från sidan Användare i organisationsinställningarna.

Invite GitHub collaborators into Azure DevOps.

Den här funktionen måste vara aktiverad för befintliga organisationer via en inställning under Principer i organisationsinställningarna. Den är dock aktiverad som standard för organisationer som skapats av en GitHub-identitet.

Enable for existing organizations.

Kommentar

Den här funktionen är inte tillgänglig för icke-GitHub-användare, även om principen är aktiverad.

Mer information om hur du bjuder in gruppmedlemmar finns i dokumentationen här. Om du har problem med att ansluta till Azure DevOps med GitHub kan du läsa vanliga frågor och svar om felsökning av autentisering och inbjudan till GitHub-användare.

Azure-tavlor

Få information om teamets hälsostatus med tre nya Azure Boards-rapporter

Du kan inte åtgärda det du inte kan se. Därför vill du hålla ett öga på tillståndet och hälsotillståndet för deras arbetsprocesser. Med dessa rapporter gör vi det enklare för dig att spåra viktiga mått med minimal ansträngning i Azure Boards.

De tre nya interaktiva rapporterna är: Burndown, Cumulative Flow Diagram (CFD) och Velocity. Du kan se rapporterna på den nya analysfliken.

Mått som sprint burndown, arbetsflöde och teamhastighet ger dig insyn i teamets framsteg och hjälper dig att besvara frågor som:

  • Hur mycket arbete har vi kvar i den här sprinten? Är vi på rätt spår för att slutföra det?
  • Vilket steg i utvecklingsprocessen tar längst tid? Kan vi göra något åt det?
  • Hur mycket arbete ska vi planera för nästa sprint baserat på tidigare iterationer?

Kommentar

Diagrammen som tidigare visades i rubrikerna har ersatts med dessa förbättrade rapporter.

De nya rapporterna är helt interaktiva och gör att du kan justera dem efter dina behov. Du hittar de nya rapporterna under fliken Analys i varje hubb.

  • Bränningsdiagrammet finns under Sprints-hubben .

    Analytics tab in Sprint hub.

  • CFD- och Velocity-rapporterna kan nås från fliken Analys under Tavlor och kvarvarande uppgifter genom att klicka på relevant kort.

    CFD and velocity reports in boards.

Med de nya rapporterna har du mer kontroll och information om ditt team. Nedan följer några exempel:

  • Sprint Burndown- och Velocity-rapporterna kan ställas in för att använda antal arbetsobjekt eller summan av återstående arbete.
  • Du kan justera tidsramen för sprintbrännningen utan att påverka projektdatumen. Så om ditt team vanligtvis tillbringar den första dagen av varje sprintplanering kan du nu matcha diagrammet för att återspegla det.
  • Burndown-diagrammet har nu en vattenstämpel som visar helger.
  • Med CFD-rapporten kan du ta bort brädkolumner som Design för att få mer fokus på det flöde som teamen har kontroll över.

Här är ett exempel på CFD-rapporten som visar flödet för de senaste 30 dagarna av kvarvarande uppgifter i Stories.

Example of the CFD report.

Diagrammet Velocity kan nu spåras för alla kvarvarande nivåer. Nu kan du till exempel lägga till både funktioner och epos, medan krav endast stöds innan föregående diagram. Här är ett exempel på en hastighetsrapport för de senaste 6 iterationerna av kvarvarande funktioner.

Example of a velocity report.

Azure Boards-app för Slack

Vi är glada att kunna presentera den nya Azure Boards-appen för Slack. Med den här appen kan du övervaka aktiviteten för arbetsobjekt och skapa arbetsobjekt från Slack-kanalen.

Med appen kan du konfigurera och hantera händelseprenumerationer, inklusive skapande och uppdateringar av arbetsobjekt, samt få meddelanden om dessa händelser i Slack-kanalen. Konversationerna i Slack-kanalen kan användas för att skapa arbetsobjekt. Du får också personliga meddelanden när arbetsobjekt tilldelas dig. Dessutom kan du starta diskussioner med förhandsversioner av url:er för arbetsobjekt.

Azure Boards app for Slack.

Om du vill installera Azure Boards-appen klickar du här.

Anpassa Taskboard-kolumner

Vi är glada över att kunna meddela att vi har lagt till ett alternativ så att du kan anpassa kolumnerna i Aktivitetstavlan. Nu kan du lägga till, ta bort, byta namn på och ändra ordning på kolumnerna.

Om du vill konfigurera kolumnerna i aktivitetstavlan går du till Kolumnalternativ.

Customizing columns on the taskboard.

Den här funktionen prioriterades baserat på ett förslag från utvecklarcommunityn.

Växla mellan att visa eller dölja slutförda underordnade arbetsuppgifter i de kvarvarande uppgifterna

Många gånger, när du förfinar kvarvarande uppgifter, vill du bara se objekt som inte har slutförts. Nu kan du visa eller dölja slutförda underordnade objekt i kvarvarande uppgifter.

Om växlingsknappen är aktiverad visas alla underordnade objekt i ett slutfört tillstånd. När växlingsknappen är inaktiverad döljs alla underordnade objekt i slutfört tillstånd från kvarvarande uppgifter.

Show or hide child items on the backlog.

Nu kan du enkelt komma åt dina nyligen besökta tavlor, kvarvarande uppgifter, frågor och sprintar från sökrutan genom att aktivera sökrutan i Azure Boards.

Activate the instant search box.

Dessutom kan du söka efter tavlor, kvarvarande uppgifter, frågor och sprintar i projektet genom att skriva brädnamnet i sökrutan. Nu är de tavlor som betyder mest för dig bara ett klick bort.

Search for a board name.

De senaste taggarna visas när du taggar ett arbetsobjekt

När du taggar ett arbetsobjekt visas nu upp till fem av de senast använda taggarna. Detta gör det enklare att lägga till rätt information i dina arbetsobjekt.

Most recent used tags displayed when tagging a work item.

Azure-lagringsplatser

Förbättrade filtreringsalternativ för kodsökning

Tidigare har kodsökningen stödt 39 kodsökningsfilter, till exempel kommentar: och def:. Data antydde att det fanns många filter som inte användes, därför tar vi bort några filter och sammanfogar andra. Med den här uppdateringen minskade vi antalet filter till 19. Detta hjälper till genom att göra kodsökningsfrågor effektivare och minska övrig övrig oreda i gränssnittet.

Code search filter options.

Nu till exempel func: maps to method:, d.v.s. om du söker efter func:AccountAdmin mappas resultatet till metoden:AccountAdmin. På samma sätt mappas macrodef: och macroref: till makro:. Å andra sidan har filter som union: och org: blivit inaktuella på grund av bristande användning.

Kodtäckningsmått och grenprinciper för pull-begäranden

Nu kan du se kodtäckningsmått för ändringar i vyn pull-begäran (PR). Detta säkerställer att du har testat ändringarna på ett korrekt sätt genom automatiserade tester. Täckningsstatus visas som en kommentar i PR-översikten. Du kan visa information om täckningsinformation för varje kodrad som ändras i fildiffvyn.

Code coverage metrics and branch policy for pull requests

View details of coverage information for every code line that is changed.

Dessutom kan lagringsplatsens ägare nu ange kodtäckningsprinciper och förhindra att stora, otestade ändringar slås samman till en gren. Önskade tröskelvärden för täckning kan definieras i en azurepipelines-coverage.yml inställningsfil som är incheckad i roten av lagringsplatsen och täckningsprincipen kan definieras med hjälp av den befintliga konfigurera en grenprincip för ytterligare tjänster i Azure Repos.

Define coverage thresholds.

Filtrera kommentarsaviseringar från pull-begäranden

Kommentarer i pull-begäranden kan ofta generera mycket brus på grund av meddelanden. Vi har lagt till en anpassad prenumeration som gör att du kan filtrera vilka kommentarsmeddelanden du prenumererar på efter kommentarsålder, kommentator, borttagen kommentar, nämnda användare, pull-begärandeförfattare, målgren och tråddeltagare. Du kan skapa dessa meddelandeprenumerationer genom att klicka på användarikonen i det övre högra hörnet och gå till Användarinställningar.

Filter comment notifications from pull requests.

Filter comment notifications in User settings.

Tjänstundantag för kommentarer för pull-begäranden

Nu kan du skapa tjänstkrokar för kommentarer i en pull-begäran baserat på lagringsplats och målgren.

Service hooks for pull request comments.

Azure Artifacts

Dela dina paket med offentliga feeds (förhandsversion)

Nu kan du skapa och lagra dina paket i offentliga feeds. Paket som lagras i offentliga feeds är tillgängliga för alla på Internet utan autentisering, oavsett om de är i din organisation eller till och med inloggade i en Azure DevOps-organisation. Läs mer om offentliga feeds i vår feeds-dokumentation eller gå direkt in i vår självstudiekurs för att dela paket offentligt.

Share your packages with public feeds.

Azure-pipelines

kustomize och kompose som bake-alternativ i KubernetesManifest-uppgift

kustomize (en del av Kubernetes sig-cli) låter dig anpassa råa, mallfria YAML-filer för flera syften och lämnar den ursprungliga YAML orörd. Ett alternativ för kustomize har lagts till under åtgärden Bake av KubernetesManifest så att alla mappar som innehåller kustomization.yaml-filer kan användas för att generera manifestfilerna som används i distributionsåtgärden för KubernetesManifest-uppgiften.

steps:
- task: KubernetesManifest@0
  name: bake
  displayName: Bake K8s manifests from Helm chart
  inputs:
    action: bake
    renderType: kustomize
    kustomizationPath: folderContainingKustomizationFile

- task: KubernetesManifest@0
  displayName: Deploy K8s manifests
  inputs:
    kubernetesServiceConnection: k8sSC1
    manifests: $(bake.manifestsBundle)

kompose omvandlar en Docker Compose-fil till en Kubernetes-resurs.

steps:
- task: KubernetesManifest@0
  name: bake
  displayName: Bake K8s manifests from Helm chart
  inputs:
    action: bake
    renderType: kompose
    dockerComposeFile: docker-compose.yaml

- task: KubernetesManifest@0
  displayName: Deploy K8s manifests
  inputs:
    kubernetesServiceConnection: k8sSC1
    manifests: $(bake.manifestsBundle)

Stöd för autentiseringsuppgifter för klusteradministratör i HelmDeploy-uppgifter

Tidigare använde HelmDeploy-uppgiften autentiseringsuppgifterna för klusteranvändare för distributioner. Detta resulterade i interaktiva inloggningsprompter och misslyckade pipelines för ett Azure Active Directory-baserat RBAC-aktiverat kluster. För att åtgärda det här problemet har vi lagt till en kryssruta som gör att du kan använda autentiseringsuppgifter för klusteradministratör i stället för autentiseringsuppgifter för klusteranvändare.

Package and deploy Helm charts showing the use cluster admin credentials checkbox.

Hantera pipeline-variabler i YAML-redigeraren

Vi har uppdaterat upplevelsen för att hantera pipelinevariabler i YAML-redigeraren. Du behöver inte längre gå till den klassiska redigeraren för att lägga till eller uppdatera variabler i YAML-pipelines.

Manage pipeline variables in YAML editor.

Nya fördefinierade variabler i YAML-pipeline

Med variabler får du ett bekvämt sätt att få viktiga databitar i olika delar av din pipeline. Med den här uppdateringen har vi lagt till några fördefinierade variabler i ett distributionsjobb. Dessa variabler anges automatiskt av systemet, begränsade till det specifika distributionsjobbet och är skrivskyddade.

  • Environment.Id – ID för miljön.
  • Environment.Name – Namnet på den miljö som distributionsjobbet riktar in sig på.
  • Environment.ResourceId – ID:t för resursen i miljön som distributionsjobbet riktar in sig på.
  • Environment.ResourceName – namnet på resursen i miljön som distributionsjobbet riktar in sig på.

För närvarande kan du automatiskt länka arbetsobjekt till klassiska versioner. Detta var dock inte möjligt med YAML-pipelines. Med den här uppdateringen har vi åtgärdat den här klyftan. När du kör en pipeline med hjälp av kod från en angiven gren associerar Azure Pipelines automatiskt körningen med alla arbetsobjekt (som härleds via incheckningarna i koden). När du öppnar arbetsobjektet kan du se körningarna där koden för arbetsobjektet skapades. Om du vill konfigurera detta använder du inställningspanelen i en pipeline.

Avbryt ett steg i en körning av YAML-pipeline med flera steg

När du kör en YAML-pipeline i flera steg kan du avbryta körningen av en fas medan den pågår. Det här är användbart om du vet att fasen kommer att misslyckas eller om du har en annan körning som du vill starta. Den här funktionen är också en förutsättning för att vi ska kunna stödja ett nytt försök i ett misslyckat skede i framtiden.

Godkännanden i YAML-pipelines med flera steg

Vi fortsätter att förbättra YAML-pipelines i flera steg. Nu kan du lägga till manuella godkännanden i dessa pipelines. Infrastrukturägare kan skydda sina miljöer och söka manuella godkännanden innan en fas i en pipeline distribueras till dem. Med fullständig uppdelning av roller mellan ägare av infrastruktur (miljö) och program (pipeline) ser du till att du manuellt loggar ut för distribution i en viss pipeline och får central kontroll när du tillämpar samma kontroller för alla distributioner i miljön.

Approvals in multi-stage YAML pipelines.

Pipelinekörningarna som distribueras till utvecklingsmiljön stoppas för godkännande i början av fasen.

Pipeline runs deploying to dev will stop for approval.

Uppdateringar till värdbaserade pipelineavbildningar

Vi har gjort uppdateringar av flera av azure pipelines-värdbaserade VM-avbildningar. Mer information om de senaste versionerna finns här. Följande ändringar har lagts till som en del av den här uppdateringen:

  • För VS2017 och VS2019:

  • För Ubuntu 16.04:

    • Uppdaterade helm för att alltid hämta den senaste (inte längre fäst på v2.14.0)
    • Flera populära Docker-containrar har lagts till
    • Python har uppdaterats till version 2.7.16, 3.4.10, 3.5.7, 3.6.9, 3.7.4
    • Ändrade Standardsökvägar och miljövariabler för Rust

  • För alla bilder har en ImageVersion miljövariabel lagts till för avbildningens version

En fullständig lista över verktyg som är tillgängliga för en viss avbildning finns i Inställningar > Information om agentpooler>.

Förbättringar av DevOps Project för virtuella datorer

I den här uppdateringen har vi förbättrat arbetsflödet för virtuella DevOps Projects-datorer (VM) för att inkludera de virtuella datorer som inte uppfyller kvotbegränsningen per plats. Tidigare var du tvungen att välja den virtuella datorn efter namn och erbjudande. Nu har du en vy på begäran med mer information om de virtuella datorerbjudandena, till exempel kostnad/månad, RAM-minne, datadiskar osv. Det gör det enklare för dig att välja den virtuella dator som du behöver.

Enhancements to DevOps Project for virtual machine.

En enda värdbaserad pool

I den senaste sprinten meddelade vi att vi distribuerar en ny värdbaserad pool med namnet Azure Pipelines för att ersätta alla andra värdbaserade pooler – Hosted, Hosted VS2017, Hosted Ubuntu 1604, Hosted Windows 2019 med VS2019, Hosted macOS och Hosted macOS High Sierra. Den här ändringen implementeras med den här versionen.

Att ha flera värdbaserade pooler kan ibland vara förvirrande. Du får ingen korrekt bild av var samtidighet används. Om du till exempel har en samtidighet på 10 parallella jobb ser du 10 virtuella agenter i var och en av de värdbaserade poolerna, vilket inte är korrekt. När jobbet väntar på en specifik värdbaserad pool (t.ex. värdbaserad VS2017) med alla inaktiva agenter kan du tro att Azure Pipelines-tjänsten är bruten utan att inse att samtidigheten eventuellt förbrukas i andra värdbaserade pooler (t.ex. värdbaserad Ubuntu 1604).

Med den här ändringen ser du en enda värdbaserad pool som ger dig en korrekt bild av hur många jobb som körs i poolen. Vi planerar att rulla ut den här ändringen under de kommande sprintarna. Du behöver inte göra några ändringar i dina pipelines eftersom vi automatiskt omdirigerar jobb från de gamla värdbaserade poolerna till lämplig avbildning i den nya enhetliga poolen.

Visa rätt poolinformation om varje jobb

Tidigare, när du använde en matris för att expandera jobb eller en variabel för att identifiera en pool, hade vi problem med att visa rätt poolinformation på loggsidorna. Med den här uppdateringen har vi åtgärdat problemen som gjorde att felaktig poolinformation visades för vissa jobb.

Support i produkten för hantering av ”flaky test”

Flagnande tester kan påverka utvecklarnas produktivitet eftersom testfel kanske inte är relaterade till de ändringar som testas. De kan också påverka kvaliteten på levererad kod. Därför har vi lagt till produktsupport för flagnande testhantering. Den här funktionen stöder livscykeln från slutpunkt till slutpunkt med identifiering, rapportering och lösning. Flagnande testhantering stöder system- och anpassad identifiering.

Systemidentifiering är tillgängligt via VSTest-funktionen för omkörning av uppgifter. Ett flagnande test är ett test som ger olika resultat, till exempel pass eller fail, även om det inte finns några ändringar i källkods- eller körningsmiljön. Alla ytterligare körningar av test för samma gren markeras också som flagnande tills det är löst och omarkerat. Du kan också ansluta din anpassade identifieringsmekanism med hjälp av våra API:er. När ett test har identifierats som flagnande kan du hämta informationen i testrapporten i pipelinen. Du kan sedan avgöra om de flagnande testerna påverkar pipelinefelet. Som standard är flagnande testinformation tillgänglig som ytterligare metadata.

In-product support for flaky test management.

Här är ett exempel på en rapport med testsammanfattningen.

Example of a report with the test summary.

Mer information om flagnande testhantering finns i dokumentationen här.

Förbättringar av Distributionscenter för WebApp i Azure-portalen

Vi har förbättrat Distributionscenter för WebApp i Azure-portalen med stöd för pipelines med flera artefakter. Om en icke-primär artefakt av Azure Pipelines distribueras i webbappen får du nu relevant information från Azure-portalen. Du har också en djuplänk till den distribuerade lagringsplatsen för att navigera direkt till lagringsplatsen från Azure-portalen. Lagringsplatsen kan finnas i Azure Repos eller i GitHub.

CI-utlösare för nya förgreningar

Det har varit en lång väntande begäran om att inte utlösa CI-versioner när en ny gren skapas och när den grenen inte har ändringar. Föreställ dig följande exempel:

  • Du använder webbgränssnittet för att skapa en ny gren baserat på en befintlig gren. Detta utlöser omedelbart en ny CI-version om grenfiltret matchar namnet på den nya grenen. Detta är oönskat eftersom innehållet i den nya grenen är detsamma jämfört med den befintliga grenen.
  • Du har en lagringsplats med två mappar – app och dokument. Du konfigurerar ett sökvägsfilter för CI så att det matchar "app". Med andra ord vill du inte skapa en ny version om en ändring har push-överförts till dokument. Du skapar en ny gren lokalt, gör några ändringar i dokument och push-överför sedan grenen till servern. Vi använde för att utlösa en ny CI-version. Detta är oönskat eftersom du uttryckligen bad om att inte söka efter ändringar i dokumentmappen. Men på grund av hur vi hanterade en ny grenhändelse verkar det som om även en ändring har gjorts i appmappen.

Nu har vi ett bättre sätt att hantera CI för nya grenar för att lösa dessa problem. När du publicerar en ny gren letar vi uttryckligen efter nya incheckningar i den grenen och kontrollerar om de matchar sökvägsfiltren.

Terraform-integrering med Azure Pipelines

Terraform är ett verktyg med öppen källkod för att utveckla, ändra och versionshantera infrastrukturen på ett säkert och effektivt sätt. Terraform kodifierar API:er till deklarativa konfigurationsfiler så att du kan definiera och etablera infrastruktur med ett konfigurationsspråk på hög nivå. Du kan använda Terraform-tillägget för att skapa resurser för alla större infrastrukturleverantörer: Azure, Amazon Web Services (AWS) och Google Cloud Platform (GCP).

Mer information om Terraform-tillägget finns i dokumentationen här.

Terraform integration with Azure Pipelines.

Integrering med Google Analytics

Med Ramverket för Google Analytics-experiment kan du testa nästan alla ändringar eller variationer på en webbplats eller app för att mäta dess inverkan på ett specifikt mål. Du kan till exempel ha aktiviteter som du vill att användarna ska slutföra (t.ex. göra ett köp, registrera dig för ett nyhetsbrev) och/eller mått som du vill förbättra (t.ex. intäkter, sessionsvaraktighet, avvisningsfrekvens). Med de här aktiviteterna kan du identifiera ändringar som är värda att implementera baserat på den direkta inverkan de har på funktionens prestanda.

Google Analytics-experimenttillägget för Azure DevOps lägger till experimentsteg i bygg- och versionspipelines, så att du kontinuerligt kan iterera, lära dig och distribuera i snabbare takt genom att hantera experimenten kontinuerligt samtidigt som du får alla DevOps-fördelar med Azure Pipelines.

Du kan ladda ned Google Analytics-experimenttillägget från Marketplace.

Integration with Google Analytics.

Cachelagring av pipeline (offentlig förhandsversion)

Med cachelagring av pipeline kan du spara resultatet av en tidskrävande åtgärd, till exempel en paketåterställning eller en beroendekompilering, och återställa den igen under nästa körning av en pipeline. Detta kan resultera i snabbare versioner.

Mer information finns i blogginlägget med det fullständiga meddelandet här.

Variabelgrupp- och variabelhanteringskommandon för pipelines

Det kan vara svårt att porta YAML-baserade pipelines från ett projekt till ett annat eftersom du behöver konfigurera pipelinevariablerna och variabelgrupperna manuellt. Men med kommandon för pipelinevariabelgrupp och variabelhantering kan du nu skripta konfigurationen och hanteringen av pipelinevariabler och variabelgrupper som i sin tur kan vara versionsstyrda, så att du enkelt kan dela instruktionerna för att flytta och konfigurera pipelines från ett projekt till ett annat.

Kör pipeline för en PR-gren

När du skapar en PR kan det vara svårt att kontrollera om ändringarna kan bryta pipelinekörningen på målgrenen. Men med möjligheten att utlösa en pipelinekörning eller köa en bygge för en PR-gren kan du nu validera och visualisera de ändringar som går in genom att köra den mot målpipelinen. Mer information finns i az pipelines run and az pipelines build queue command documentation (Az pipelines run and az pipelines build queue command documentation).

Hoppa över den första pipelinekörningen

När du skapar pipelines vill du ibland skapa och checka in en YAML-fil och inte utlösa pipelinekörningen eftersom det kan leda till en felaktig körning på grund av en mängd olika orsaker – infrastrukturen är inte redo eller behöver skapa och uppdatera variabel-/variabelgrupper osv. Med Azure DevOps CLI kan du nu hoppa över den första automatiserade pipelinekörningen när du skapar en pipeline genom att inkludera parametern --skip-first-run. Mer information finns i dokumentationen om az pipeline create-kommandot.

Kommandoförbättring för tjänstslutpunkt

Cli-kommandon för tjänstslutpunkt stöds endast för konfiguration och hantering av azure rm- och github-tjänstslutpunkt. Med den här versionen kan du dock med tjänstslutpunktskommandon skapa valfri tjänstslutpunkt genom att tillhandahålla konfigurationen via filen och tillhandahålla optimerade kommandon – az devops service-endpoint github och az devops service-endpoint azurerm, som ger förstklassigt stöd för att skapa tjänstslutpunkter av dessa typer. Mer information finns i kommandodokumentationen.

Nästa steg

Kommentar

Dessa funktioner kommer att distribueras under de kommande två till tre veckorna.

Gå över till Azure DevOps och ta en titt.

Gå till Azure DevOps

Så här ger du feedback

Vi vill gärna höra vad du tycker om de här funktionerna. Använd feedbackmenyn för att rapportera ett problem eller ge ett förslag.

Make a suggestion

Du kan också få råd och dina frågor som besvaras av communityn på Stack Overflow.

Tack,

Sam Guckenheimer