Viktig information om Azure DevOps Server 2022

| Developer Community | Systemkrav och kompatibilitet | licensvillkor | DevOps Blogg | SHA-256 Hashes |

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 2022 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 2022 Update 0.1 Patch 5: 14 november 2023

Vi har släppt en korrigering för Azure DevOps Server 2022 Update 0.1 som innehåller korrigeringar för följande.

• Utökade listan över tillåtna tecken i PowerShell-uppgifter för Aktivera verifiering av argument till shell-uppgifter.
• Åtgärda ett problem som gjorde att redigeringar av tjänstanslutningar var beständiga när du klickade på knappen Avbryt.

Versionsdatum för Azure DevOps Server 2022 Update 0.1 Patch 4: 10 oktober 2023

Vi har släppt en korrigering för Azure DevOps Server 2022 Update 0.1 som innehåller korrigeringar för följande.

• Åtgärdade ett fel som gjorde att pipelines fastnade genom att uppgradera modellen för pipelinekörning.
• En bugg har åtgärdats där identiteten "Analysis Owner" visades som Inaktiv identitet på datorer vid uppgradering av patchar.
• Rensningsjobbet för builden innehåller många uppgifter, som var och en raderar en artefakt för en build. Om någon av dessa aktiviteter misslyckades kördes ingen av de efterföljande aktiviteterna. Vi har ändrat det här beteendet för att ignorera aktivitetsfel och rensa så många artefakter som möjligt.

Versionsdatum för Azure DevOps Server 2022 Update 0.1 Patch 3: 12 september 2023

Vi har släppt en korrigering för Azure DevOps Server 2022 Update 0.1 som innehåller korrigeringar för följande.

• CVE-2023-33136: Sårbarhet för körning av fjärrkod i Azure DevOps Server.
• CVE-2023-38155: Sårbarhet för förhöjd behörighet i Azure DevOps Server och Team Foundation Server.

Versionsdatum för Azure DevOps Server 2022 Update 0.1 Patch 2: 8 augusti 2023

Vi har släppt en korrigering för Azure DevOps Server 2022 Update 0.1 som innehåller korrigeringar för följande.

• CVE-2023-36869: Azure DevOps Server Spoofing Vulnerability.
• En bugg har åtgärdats i SOAP-anrop där ArithmeticException kan höjas för XML-svar med stora metadata.
• Implementerade ändringar i redigeraren för tjänstanslutningar så att slutpunktstillståndet töms vid komponentens borttagning.
• Åtgärdat problem med relativa länkar som inte fungerar i Markdown-filer.
• Ett prestandaproblem har åtgärdats, där programnivån tog längre tid än normalt att starta upp när ett stort antal taggar var definierade.
• Åtgärdade fel TF400367 på sidan Agentpooler.
• En bugg har åtgärdats där Analysis Owner-identiteten visade sig vara Inaktiv identitet.
• Ett oändligt loopfel har åtgärdats på CronScheduleJobExtension.

Versionsdatum för Azure DevOps Server 2022 Update 0.1 Patch 1: 13 juni 2023

Vi har släppt en korrigering för Azure DevOps Server 2022 Update 0.1 som innehåller korrigeringar för följande.

• CVE-2023-21565: Azure DevOps Server Spoofing Vulnerability.
• CVE-2023-21569: Azure DevOps Server Spoofing Vulnerability.
• En bugg med redigeraren för tjänstanslutningar har åtgärdats. Nu töms tillståndet för slutpunkten vid komponentens borttagning.
• Åtgärdade ett problem där frånkoppling eller anslutning av samlingen misslyckades och rapporterade följande fel: 'TF246018: Databasåtgärden överskred tidsgränsen och har avbrutits.'

Versionsdatum för Azure DevOps Server 2022 Update 0.1: 9 maj 2023

Azure DevOps Server 2022.0.1 är en sammanställning av felkorrigeringar. Den innehåller alla korrigeringar i Azure DevOps Server 2022.0.1 RC som släpptes tidigare. Du kan installera Azure DevOps Server 2022.0.1 direkt eller uppgradera från Azure DevOps Server 2022 eller Team Foundation Server 2015 eller senare.

Versionsdatum för Azure DevOps Server 2022 Update 0.1 RC: 11 april 2023

Azure DevOps Server 2022.0.1 RC är en samling av felkorrigeringar. Den innehåller alla korrigeringar i Azure DevOps Server 2022-korrigeringar som tidigare släppts. Du kan installera Azure DevOps Server 2022.0.1 direkt eller uppgradera från Azure DevOps Server 2022 eller Team Foundation Server 2015 eller senare.

Den här versionen innehåller korrigeringar för följande buggar:

• Uppgraderade Git Virtual File System (GVFS) från till v2.39.1.1-micorosoft.2 för att åtgärda en säkerhetsrisk.
• Testdata togs inte bort, vilket gjorde att databasen växte. Med den här korrigeringen uppdaterade vi lagringen av byggdata för att förhindra att ny obunden testdata skapas.
• Uppdateringar av AnalyticCleanupJob, jobbstatusen var Stoppad och nu rapporterar vi Slutförd.
• Fixat att kommandot "tfx extension publish" misslyckades med felet "Den angivna nyckeln fanns inte i ordlistan".
• Implementerade en arbetsrunda för att åtgärda ett fel vid åtkomst till tillägget Team Calendar.
• CVE-2023-21564: Sårbarhet för skriptkörning mellan webbplatser i Azure DevOps Server
• CVE-2023-21553: Sårbarhet för körning av fjärrkod i Azure DevOps Server
• MSBuild- och VSBuild-uppgifter har uppdaterats för att stödja Visual Studio 2022.
• Uppdatera metodiken för inläsning av återautentisering för att förhindra XSS-hotvektorn.
• Azure DevOps Server 2022 Proxy rapporterar följande fel: VS800069: Den här tjänsten är endast tillgänglig i lokala Azure DevOps.
• Tillgänglighetsproblem för shelvsets via webbgränssnittet har åtgärdats.
• Åtgärdat problem som krävde omstart av tfsjobagent-tjänsten och Azure DevOps Server-programpoolen efter uppdatering av SMTP-relaterade inställningar i Azure DevOps Server Management Console.
• Meddelanden skickades inte för PAT sju dagar före förfallodatumet.

Versionsdatum för Azure DevOps Server 2022 Patch 4: 13 juni 2023

Vi har släppt en korrigering för Azure DevOps Server 2022 som innehåller korrigeringar för följande.

• CVE-2023-21565: Azure DevOps Server Spoofing Vulnerability.
• CVE-2023-21569: Azure DevOps Server Spoofing Vulnerability.
• En bugg med redigeraren för tjänstanslutningar har åtgärdats. Nu töms tillståndet för slutpunkten vid komponentens borttagning.
• Åtgärdade ett problem där frånkoppling eller anslutning av samlingen misslyckades och rapporterade följande fel: 'TF246018: Databasåtgärden överskred tidsgränsen och har avbrutits.'

Versionsdatum för Azure DevOps Server 2022 Patch 3: 21 mars 2023

Vi har släppt en korrigering (19.205.33506.1) för Azure DevOps Server 2022 som innehåller korrigeringar för följande.

• Åtgärdat problem som krävde omstart av tfsjobagent-tjänsten och Azure DevOps Server-programpoolen efter uppdatering av SMTP-relaterade inställningar i Azure DevOps Server Management Console.
• Kopiera 'endpoint state' till redigeringspanelen för tjänstslutpunkt istället för att skicka det som referens.
• Tidigare, när du redigerade tjänstanslutningar, bevarades redigeringarna i användargränssnittet efter att du har valt knappen Avbryt. Med den här korrigeringen har vi korrigerat i Notification SDK för när ett team har meddelandeleverans inställd på Leverera inte. Om meddelandeprenumerationen i det här scenariot har konfigurerats med alternativet Team-inställningsleverans får gruppmedlemmarna inte meddelandena. Det finns inget behov av att utöka identiteterna under teamet ytterligare för att kontrollera medlemmarnas inställningar.

Versionsdatum för Azure DevOps Server 2022 Patch 2: 14 februari 2023

Vi har släppt en korrigering för Azure DevOps Server 2022 som innehåller korrigeringar för följande.

• CVE-2023-21564: Sårbarhet för skriptkörning mellan webbplatser i Azure DevOps Server
• MSBuild- och VSBuild-uppgifter har uppdaterats för att stödja Visual Studio 2022.
• Uppdatera metodiken för att implementera återautentisering för att förhindra en eventuell XSS-attackvektor.
• Azure DevOps Server 2022 Proxy rapporterar följande fel: VS800069: Den här tjänsten är endast tillgänglig i lokala Azure DevOps.

Versionsdatum för Azure DevOps Server 2022 Patch 1: 24 januari 2023

Vi har släppt en korrigering för Azure DevOps Server 2022 som innehåller korrigeringar för följande.

• Testdata togs inte bort, vilket gjorde att databasen växte. Med den här korrigeringen uppdaterade vi lagringen av byggdata för att förhindra att ny obunden testdata skapas.
• Uppdateringar av AnalyticCleanupJob, jobbstatusen var Stoppad och nu rapporterar vi Slutförd.
• Korrigerade felet i kommandot "tfx extension publish" som misslyckades med att ge felet "Den angivna nyckeln fanns inte i ordboken".
• Implementerade en arbetsrunda för att åtgärda ett fel vid åtkomst till tillägget Team Calendar.

Utgivningsdatum för Azure DevOps Server 2022: 6 december 2022

Azure DevOps Server 2022 är en sammanställning av felkorrigeringar. Den innehåller alla funktioner i Azure DevOps Server 2022 RC2 och RC1 som släpptes tidigare.

Versionsdatum för Azure DevOps Server 2022 RC2: 25 oktober 2022

Azure DevOps Server 2022 RC2 är en samling av felkorrigeringar. Den innehåller alla funktioner i Azure DevOps Server 2022 RC1 som släpptes tidigare.

Stöd för offentliga RSA-nycklar har förbättrats för att stödja sha2-typer av offentliga nycklar utöver SHA1-SSH-RSA som vi tidigare stödde.

Nu stöds offentliga nyckeltyper:

• SSH-RSA
• RSA-SHA2-256
• RSA-SHA2-512

Åtgärd krävs

Om du implementerade arbetet för att aktivera SSH-RSA genom att uttryckligen ange den i .ssh/config1 filen måste du antingen ta bort PubkeyAcceptedTypeseller ändra den så att den använder antingen RSA-SHA2-256 eller RSA-SHA2-512 eller båda. Du hittar information om vad du ska göra om du fortfarande uppmanas att ange ditt lösenord och GIT_SSH_COMMAND="ssh -v" git fetch inte visar någon algoritm för ömsesidig signatur i dokumentationen här.

Stöd för elliptiska nycklar har ännu inte lagts till och kvarstår som en mycket efterfrågad funktion i vår backlog.

Lanseringsdatum för Azure DevOps Server 2022 RC1: 9 augusti 2022

Sammanfattning av nyheter i Azure DevOps Server 2022

Azure DevOps Server 2022 introducerar många nya funktioner. Några av höjdpunkterna är:

• Leveransplaner
• Visa rätt persona på comminlänkar
• Nya kontroller för miljövariabler i pipelines
• Generera obegränsade token för förgreningsversioner
• Nya TFVC-sidor
• Gruppera efter taggar som är tillgängliga i diagramwidgetar

Du kan också gå till enskilda avsnitt för att se alla nya funktioner för varje tjänst:

• tavlor
• Repos
• Pipelines
• Rapportering

Styrelser

Delivery Plans (leveransplaner)

Vi är glada över att kunna meddela att leveransplaner nu ingår i Azure DevOps Server. Leveransplaner levererar på 3 viktiga scenarier:

• En tidslinjevy över planen
• Arbetets förlopp
• Beroendespårning

Nedan visas de viktigaste funktionerna. Filtrering, markörer och fältkriterier ingår också i leveransplaner.

Det finns två huvudvyer: komprimerade och expanderade

Med leveransplan 2.0 kan du visa alla arbetsobjekt i din plan på en tidslinje med start- och måldatum eller iterationsdatum. Prioritetsordningen är start- och måldatum följt av iteration. På så sätt kan du lägga till arbetsobjekt på portföljnivå som Epic som ofta inte definieras till en iteration.

Det finns två huvudvyer i den komprimerade vyn och den expanderade vyn. Du kan också zooma in och ut ur planen genom att klicka på förstoringsglaset i den högra sidan av planen.

Det finns två huvudvyer i den komprimerade vyn och den expanderade vyn. Du kan också zooma in och ut ur planen genom att klicka på förstoringsglaset till höger i planen.

• Komprimerad vy

  Den komprimerade vyn visar alla arbetsobjektskort som har komprimerats , vilket innebär att inte all kortinformation visas. Den här vyn är användbar för en övergripande vy över arbetet i planen. Om du vill dölja kortfälten klickar du på kortikonen bredvid förstoringsikonerna till höger i planen.

  Här är ett exempel på en plan som växlar mellan de komprimerade och expanderade vyerna.

  

• Expanderad vy

  Den expanderade vyn visar förloppet för ett arbetsobjekt genom att räkna antalet underordnade och länkade objekt och visa hur stor procentandel som har slutförts. För närvarande bestäms förloppet av antalet arbetsobjekt.

  Här är ett exempel på en plan med hjälp av en utökad vy. Observera förloppsstaplarna och slutförandegraden.

  

Beroendespårning

Beroendespårning baseras på föregående och efterföljande länkar som definieras i arbetsobjekt. Om dessa länkar inte har definierats visas inga beroendelinjer. När det finns ett beroendeproblem med ett arbetsobjekt är beroendelänkikonen röd.

• Visa beroenden

  Specifika beroenden visas via beroendepanelen som visar alla beroenden för arbetsobjektet, inklusive riktningen. Ett rött utropstecken anger ett beroendeproblem. Om du vill ta upp panelen klickar du bara på beroendelänkikonen i det övre högra hörnet av kortet. Här är exempel på beroenden.

  

  

• Beroendelinjer

  Beroenden mellan arbetsobjekt visualiseras med riktningspillinjer mellan respektive arbetsobjekt. Flera beroenden visas som flera rader. En röd linje indikerar ett problem.

  Här följer några exempel.

  

  Här är ett exempel på ett arbetsobjekt med flera beroenden och det fungerar även med komprimerad vy.

  

  När det uppstår ett problem är linjefärgen röd, och det är även beroendeikonen.

  Här är ett exempel.

  

Kortdesign

Kort kan nu utformas med hjälp av regler, till exempel Kanban-tavlorna. Öppna inställningarna för planen och klicka på Formatmallar. I fönstret Format klickar du på + Lägg till formateringsregel för att lägga till regeln och klickar sedan på Spara. Det kan finnas upp till 10 regler och varje regel kan ha upp till 5 satser.

• Före

• Efter

Mer information om leveransplaner finns i dokumentationen här.

Borttagna objekt på arbetsobjektshubben

Arbetsobjekthubben är platsen där du kan se en lista över objekt som du har skapat eller som har tilldelats dig. Den innehåller flera anpassade pivot- och filterfunktioner för att effektivisera listning av arbetsobjekt. En av de främsta klagomålen i pivoten Tilldelad till mig är att den visar borttagna arbetsobjekt. Vi är överens om att borttagna arbetsobjekt inte längre är av värde och inte bör finnas i kvarvarande uppgifter. I den här sprinten döljer vi alla borttagna objekt från vyerna Tilldelade till mig på arbetsobjekthubben.

Visa rätt persona på commit-länkar

Utvecklingsavsnittet i ett arbetsobjekt visar listan över relevanta incheckningar och pull-begäranden. Du kan visa författaren till commit eller pull-begäran tillsammans med den tidpunkt den gjordes. Med den här uppdateringen har vi åtgärdat ett problem med att författarens avatar visas felaktigt i vyn.

Ta bort möjligheten att ladda ned en borttagen bifogad fil från arbetsobjekthistoriken

Vi har åtgärdat ett litet problem där användarna kunde ladda ned bifogade filer från arbetsobjektets historik, även efter att den bifogade filen togs bort från formuläret. När den bifogade filen har tagits bort kan den nu inte laddas ned från historiken, och inte heller kommer nedladdnings-URL:en att vara tillgänglig från REST API-svaret.

Värdet "Kommer inte att åtgärdas" har lagts till i fältet Felorsak

Precis som med alla andra typer av arbetsobjekt har typen Felarbetsobjekt ett väldefinierat arbetsflöde. Varje arbetsflöde består av tre eller flera tillstånd och en orsak. Orsaker anger varför objektet övergick från ett tillstånd till ett annat. Med den här uppdateringen har vi lagt till ett Will not fix reason-värde för felarbetsobjektstyperna i agilprocessen. Värdet blir tillgängligt som en orsak när buggar flyttas från Ny eller Aktiv till Löst. Du kan lära dig mer om hur du definierar, samlar in, sorterar och hanterar programbuggar i Dokumentation om Azure Boards.

Rörledningar

Borttagning av kvarhållningspolicyer per pipeline i klassiska byggprocesser

Nu kan du konfigurera kvarhållningsprinciper för både klassiska versioner och YAML-pipelines i Azure DevOps-projektinställningar. Kvarhållningsregler per pipeline för klassiska byggpipelines stöds inte längre. Det här är det enda sättet att konfigurera kvarhållning för YAML-rörledningar, men du kan även konfigurera kvarhållning för klassiska byggrörledningar för varje pipeline. Vi har tagit bort alla behållningsregler per pipeline för klassiska byggpipelines i en kommande uppdatering.

Vad detta innebär för dig: alla klassiska byggprocesser som tidigare hade kvarhållningsregler per byggprocess kommer att styras av kvarhållningsreglerna på projektnivå.

För att säkerställa att du inte förlorar några buildar när du uppgraderar kommer vi att skapa ett leasingavtal för alla buildar som finns vid tidpunkten för uppgraderingen och som inte har något leasingavtal.

Vi rekommenderar att du kontrollerar kvarhållningsinställningarna på projektnivå efter uppgraderingen. Om din pipeline specifikt kräver anpassade regler kan du använda en anpassad uppgift i pipelinen. Information om hur du lägger till retentionsavtal via en uppgift finns i dokumentationen om att ange kvarhållningsprinciper för byggen, utgivningar och tester.

Nya kontroller för miljövariabler i pipelines

Azure Pipelines-agenten söker igenom standardutdata efter särskilda loggningskommandon och kör dem. setVariable kan användas för att ange en variabel eller ändra en tidigare definierad variabel. Detta kan potentiellt utnyttjas av en aktör utanför systemet. Om din pipeline till exempel har ett steg som skriver ut listan över filer på en ftp-server kan en person med åtkomst till ftp-servern lägga till en ny fil, vars namn innehåller setVariable kommandot och få pipelinen att ändra sitt beteende.

Vi har många användare som förlitar sig på att ange variabler med hjälp av loggningskommandot i pipelinen. Med den här versionen gör vi följande ändringar för att minska risken för oönskad användning av setVariable kommandot.

• Vi har lagt till ett nytt konstruktionselement för uppgiftsförfattare. Genom att inkludera ett kodfragment, till exempel följande i task.json, kan en aktivitetsförfattare styra om några variabler anges av deras uppgift.

{
    "restrictions": {
        "commands": {
            "mode": "restricted"
        },
        "settableVariables": {
            "allowed": [
                "myVar",
                "otherVar"
            ]
        }
    },
}​ 

• Dessutom uppdaterar vi ett antal inbyggda uppgifter, till exempel ssh, så att de inte kan utnyttjas.

• Slutligen kan du nu använda YAML-konstruktioner för att styra om ett steg kan ange variabler.

steps:
- script: echo hello
  target:
    settableVariables: none

steps:
- script: echo hello
  target:
    settableVariables:
    - things
    - stuff

Generera obegränsade token för förgreningsversioner

GitHub Enterprise-användare använder ofta förgreningar för att bidra till en överordnad lagringsplats. När Azure Pipelines skapar bidrag från en förgrening av en GitHub Enterprise-lagringsplats begränsar den de behörigheter som beviljas till jobbåtkomsttoken och tillåter inte att pipelinehemligheter nås av sådana jobb. Mer information om säkerheten vid förgreningar finns i vår dokumentation.

Detta kan vara mer restriktivt än vad som önskas i sådana stängda miljöer, där användarna fortfarande kan dra nytta av en samarbetsmodell för inre källa. Du kan konfigurera en inställning i en pipeline för att göra hemligheter tillgängliga för förgreningar, men det finns ingen inställning för att styra omfånget för jobbåtkomsttoken. Med den här versionen ger vi dig kontrollen att generera en vanlig jobbåtkomsttoken även för byggnationer av forkar.

Du kan ändra den här inställningen från Utlösare i pipelineredigeraren . Innan du ändrar den här inställningen bör du se till att du förstår säkerhetskonsekvenserna av att aktivera den här konfigurationen.

Arkiv som en skyddad resurs i YAML-pipelines

Du kan organisera ditt Azure DevOps-projekt som värd för många underprojekt – var och en med sin egen Azure DevOps Git-lagringsplats och en eller flera pipelines. I den här strukturen kanske du vill styra vilka pipelines som kan komma åt vilka lagringsplatser. Låt oss till exempel säga att du har två lagringsplatser A och B i samma projekt och två pipelines X och Y som normalt bygger dessa lagringsplatser. Du kanske vill förhindra att pipeline Y kommer åt lagringsplatsen A. I allmänhet vill du att deltagarna i A ska styra vilka pipelines de vill ge åtkomst till.

Detta var delvis möjligt med Azure Git-lagringsplatser och pipelines, men det fanns ingen erfarenhet av att hantera det. Den här funktionen åtgärdar det gapet. Azure Git-lagringsplatser kan nu behandlas som skyddade resurser i YAML-pipelines, precis som tjänstanslutningar och agentpooler.

Som bidragsgivare till repo A kan du lägga till kontroller och pipeline-behörigheter till ditt repository. Det gör du genom att gå till projektinställningarna, välja Lagringsplatser och sedan din lagringsplats. Du kommer att märka en ny meny med namnet "Checkar", där du kan konfigurera någon av de inbyggda eller anpassade kontrollerna i form av Azure-funktioner.

Under fliken Säkerhet kan du hantera listan över pipelines som har åtkomst till lagringsplatsen.

När en YAML-pipeline använder en lagringsplats verifierar Azure Pipelines-infrastrukturen och ser till att alla kontroller och behörigheter uppfylls.

Behörigheter och kontroller av variabelgrupper och säkra filer

Du kan använda olika typer av delade resurser i YAML-pipelines. Exempel är tjänstanslutningar, variabelgrupper, säkra filer, agentpooler, miljöer eller lagringsplatser. För att skydda en pipeline från att komma åt en resurs kan resursens ägare konfigurera behörigheter och kontroller på den resursen. Varje gång en pipeline försöker komma åt resursen utvärderas alla konfigurerade behörigheter och kontroller. Dessa skydd har varit tillgängliga för tjänstanslutningar, miljöer och agentpooler ett tag. De har nyligen lagts till i lagringsplatser. Med den här versionen lägger vi till samma skydd till variabelgrupper och säkra filer.

Om du vill begränsa åtkomsten till en variabelgrupp eller en säker fil till en liten uppsättning pipelines använder du funktionen Pipelines-behörigheter .

Om du vill konfigurera kontroller eller godkännanden som ska utvärderas varje gång en pipeline körs använder du funktionen Godkännanden och kontroller för bibliotek .

Ändringar i automatiskt skapande av miljöer

När du skapar en YAML-pipeline och refererar till en miljö som inte finns skapar Azure Pipelines automatiskt miljön. Det här automatiska skapandet kan ske i användarkontexten eller i systemkontexten. I följande flöden känner Azure Pipelines till att användaren utför åtgärden:

• Du använder guiden skapa YAML-pipeline i Azure Pipelines-webbmiljön och refererar till en miljö som inte har skapats ännu.
• Du uppdaterar YAML-filen med hjälp av Azure Pipelines-webbredigeraren och sparar pipelinen när du har lagt till en referens till en miljö som inte finns. I vart och ett av ovanstående fall har Azure Pipelines en tydlig förståelse för hur användaren utför åtgärden. Därför skapar den miljön och lägger till användaren i administratörsrollen för miljön. Den här användaren har alla behörigheter för att hantera miljön och/eller för att inkludera andra användare i olika roller för att hantera miljön.

I följande flöden har Azure Pipelines inte information om användaren som skapar miljön: du uppdaterar YAML-filen med en annan extern kodredigerare, lägger till en referens till en miljö som inte finns och sedan utlöser en pipeline för kontinuerlig integrering. I det här fallet känner Inte Azure Pipelines till användaren. Tidigare hanterade vi det här fallet genom att lägga till alla projektdeltagare i miljöadministratörsrollen. Alla medlemmar i projektet kunde sedan ändra dessa behörigheter och hindra andra från att komma åt miljön.

Vi har fått din feedback om att bevilja administratörsbehörighet för en miljö till alla medlemmar i ett projekt. När vi lyssnade på din feedback hörde vi att vi inte ska skapa en miljö automatiskt om det inte är klart vem användaren som utför åtgärden är. Med den här versionen har vi gjort ändringar i hur miljöer skapas automatiskt:

• Framöver skapar pipelinekörningar inte automatiskt en miljö om den inte finns och om användarkontexten inte är känd. I sådana fall misslyckas pipelinen med ett fel om att miljön inte hittades. Du måste skapa miljöerna i förväg med rätt säkerhet och kontrollera konfigurationen innan du använder den i en pipeline.
• Pipelines med känd användarkontext skapar fortfarande miljöer automatiskt precis som tidigare.
• Slutligen bör det noteras att funktionen för att automatiskt skapa en miljö bara lades till för att förenkla processen att komma igång med Azure Pipelines. Den var avsedd för testscenarier och inte för produktionsscenarier. Du bör alltid skapa produktionsmiljöer i förväg med rätt behörigheter och kontroller och sedan använda dem i pipelines.

Ta bort Insights-dialogen från byggprocessen

Baserat på din feedback har dialogrutan för task/pipeline Insights som visas när du navigerar genom byggpipelinen tagits bort för att förbättra arbetsflödet och göra processen smidigare. Pipelineanalysdata är fortfarande tillgängliga så att du får de insikter du behöver.

Stöd för sekventiella distributioner i stället för endast den senaste när du använder låskontroller för exklusiv åtkomst

I YAML-pipelines används kontroller för att styra körningen av steg på skyddade resurser. En av de vanliga kontrollerna som du kan använda är en exklusiv låskontroll. Med den här kontrollen kan endast en enda körning från pipelinen fortsätta. När flera körningar försöker distribuera till en miljö samtidigt avbryter kontrollen alla gamla körningar och tillåter att den senaste körningen distribueras.

Att avbryta gamla körningar är en bra metod när dina versioner är kumulativa och innehåller alla kodändringar från tidigare körningar. Det finns dock vissa pipelines där kodändringar inte är kumulativa. Med den här nya funktionen kan du välja att tillåta att alla körningar fortsätter och distribueras sekventiellt till en miljö, eller bevarar det tidigare beteendet att avbryta gamla körningar och bara tillåta den senaste. Du kan ange det här beteendet med hjälp av en ny egenskap som heter lockBehavior i YAML-pipelinefilen. Värdet sequential innebär att alla körningar hämtar låset sekventiellt till den skyddade resursen. Värdet runLatest innebär att endast den senaste körningen hämtar låset till resursen.

Följ dessa steg om du vill använda exklusiv låskontroll med sequential distributioner eller runLatest:

1. Aktivera den exklusiva låskontrollen i miljön (eller en annan skyddad resurs).
2. I YAML-filen för pipelinen anger du en ny egenskap med namnet lockBehavior. Detta kan anges för hela pipelinen eller för en viss fas:

Ställ in på en scen:

stages:
- stage: A
  lockBehavior: sequential
  jobs:
  - job: Job
    steps:
    - script: Hey!

Ställ in på pipelinen:

lockBehavior: runLatest
stages:
- stage: A
  jobs:
  - job: Job
    steps:
    - script: Hey!

Om du inte anger en lockBehaviorantas den vara runLatest.

Stöd för Quebec-versionen av ServiceNow

Azure Pipelines har en befintlig integrering med ServiceNow. Integreringen förlitar sig på en app i ServiceNow och ett tillägg i Azure DevOps. Nu har vi uppdaterat appen så att den fungerar med Quebec-versionen av ServiceNow. Både klassiska pipelines och YAML-pipelines fungerar nu med Quebec. För att säkerställa att den här integreringen fungerar uppgraderar du till den nya versionen av appen (4.188.0) från Service Now Store. Mer information finns i Integrera med ServiceNow Change Management.

Nya YAML-villkorsuttryck

Det blev enklare att skriva villkorsuttryck i YAML-filer med hjälp av ${{ else }} och ${{ elseif }} uttryck. Nedan visas exempel på hur du använder dessa uttryck i YAML-pipelines-filer.

steps:
- script: tool
  env:
    ${{ if parameters.debug }}:
      TOOL_DEBUG: true
      TOOL_DEBUG_DIR: _dbg
    ${{ else }}:
      TOOL_DEBUG: false
      TOOL_DEBUG_DIR: _dbg

variables:
  ${{ if eq(parameters.os, 'win') }}:
    testsFolder: windows
  ${{ elseif eq(parameters.os, 'linux' }}:
    testsFolder: linux
  ${{ else }}:
    testsFolder: mac

Stöd för wildcards i sökvägsfilter

Jokertecken kan användas när du anger inkluderings- och exkluderingsgrenar för CI- eller PR-utlösare i en YAML-pipelinefil. De kan dock inte användas när du anger sökvägsfilter. Du kan till exempel inte inkludera alla sökvägar som matchar src/app/**/myapp*. Detta har påpekats som en olägenhet av flera kunder. Den här uppdateringen fyller det här tomrummet. Nu kan du använda jokertecken (**, *eller ?) när du anger sökvägsfilter.

Standardagentspecifikationen för pipelines är Windows-2022

Avbildningen windows-2022 är redo att vara standardversionen för windows-latest-etiketten i Microsoft-värdbaserade Azure Pipelines-agenter. Hittills har den här etiketten pekat på windows-2019-agenter. Den här ändringen kommer att lanseras under en period av flera veckor med början den 17 januari. Vi planerar att slutföra migreringen senast i mars.

Azure Pipelines har stöd windows-2022 sedan september 2021. Vi har övervakat din feedback för att förbättra bildstabiliteten windows-2022 och nu är vi redo att ange den som den senaste.

Bilden windows-2022 innehåller Visual Studio 2022. En fullständig lista över skillnader mellan windows-2022 och windows-2019finns i GitHub-problemet. För en fullständig lista över programvara som är installerad på avbildningen, kontrollera här.

Byte av namn på pipeline-mapp validerar behörigheter

Mappar som innehåller pipelines kan byta namn. Det går nu bara att byta namn på en mapp om användaren har redigeringsbehörigheter för minst en pipeline i mappen.

Uppgraderingsplanering för Pipelines Agent runtime

Vad är pipelineagenten?

Azure DevOps Pipeline Agent är programvaran som körs på en pipelinevärd för att utföra pipelinejobb. Den körs på Microsofts värdbaserade agenter, skalningsuppsättningsagenter och lokalt installerade agenter. I det senare fallet installerar du det själv. Pipelineagenten består av en lyssnare och arbetare (implementerad i .NET), arbetaren kör uppgifter som implementeras antingen i Node eller PowerShell och är därför värd för dessa körningar för dem.

Kommande uppgradering till .NET 6 & Red Hat 6 utfasning

Med lanseringen av .NET 6 kan vi dra nytta av dess nya plattformsoberoende funktioner. Mer specifikt kommer vi att kunna tillhandahålla intern kompatibilitet för Apple Silicon och Windows Arm64. Därför planerar vi att övergå till .NET 6 för Pipeline Agent (Lyssnare och Arbetare) under de kommande månaderna.

På grund av ett antal begränsningar som detta medför tar vi bort Stöd för Red Hat Enterprise Linux 6 från vår agent den 30 april 2022.

Uppdateringar av azure-filkopieringsaktivitet

Vi lanserar en ny version av Azure File Copy-aktiviteten. Den här uppgiften används för att kopiera filer till Microsoft Azure Storage-blobar eller virtuella datorer (VM). Den nya versionen har flera uppdateringar som ofta har begärts av communityn:

• AzCopy-verktygets version har uppdaterats till 10.12.2, som har stöd för filinnehållstyper. När du kopierar PDF, Excel, PPT eller någon av mime-typerna som stöds är därför filens innehållstyp korrekt inställd.

• Med den nya versionen av AzCopy kan du också konfigurera en inställning för att rensa målet när måltypen är Azure Blob. Om du anger det här alternativet tas alla mappar/filer i containern bort. Eller om ett blobprefix anges tas alla mappar/filer i prefixet bort.

• Den nya versionen av uppgiften förlitar sig på Az-moduler som är installerade på agenten i stället för AzureRM-moduler. Detta tar bort en onödig varning i vissa fall när du använder uppgiften.

Ändringarna är en del av en viktig versionsuppdatering för den här uppgiften. Du måste uttryckligen uppdatera dina pipelines för att använda den nya versionen. Vi har valt att uppdatera huvudversionen för att säkerställa att vi inte bryter några pipelines som fortfarande är beroende av AzureRM-moduler.

Nya tilläggspunkter för Pipelines informationsvy

Vi har lagt till två nya utökningspunkter som du kan rikta in dig på i dina tillägg. Med de här utökningspunkterna kan du lägga till en anpassad knapp i pipelinehuvudet och en anpassad meny i en pipelinemapp:

• Anpassad knapp i pipelinehuvudet: ms.vss-build-web.pipelines-header-menu
• Anpassad meny i en pipelinemapp: ms.vss-build-web.pipelines-folder-menu

Om du vill använda dessa nya utökningspunkter lägger du helt enkelt till ett nytt bidrag som riktar sig till dem i manifestfilen för Azure DevOps-tilläggetvss-extension.json.

Till exempel:

"contributions": [
        {
            "id": "pipelinesFolderContextMenuTestItem",
            "type": "ms.vss-web.action",
            "description": "Custom menu on a pipeline folder",
            "targets": [
                "ms.vss-build-web.pipelines-folder-menu"
            ],
            "properties": {
                "text": "Test item",
                "title": "ms.vss-code-web.source-item-menu",
                "icon": "images/show-properties.png",
                "group": "actions",
                "uri": "main.html",
                "registeredObjectId": "showProperties"
            }
        },
        {
            "id": "pipelinesHeaderTestButton",
            "type": "ms.vss-web.action",
            "description": "Custom button in the pipeline header",
            "targets": [
                "ms.vss-build-web.pipelines-header-menu"
            ],
            "properties": {
                "text": "Test item",
                "title": "ms.vss-code-web.source-item-menu",
                "icon": "images/show-properties.png",
                "group": "actions",
                "uri": "main.html",
                "registeredObjectId": "showProperties"
            }
        }
]

Resultatet blir:

• Anpassad knapp i pipelinehuvudet

  

• Anpassad meny i en pipelinemapp

  

Förbättrad migrering till Azure DevOps Services

När du kör en import från Azure DevOps Server till Azure DevOps Services måste du tänka på att Azure DevOps inte längre stöder kvarhållningsregler per pipeline. Med den här uppdateringen tog vi bort dessa principer när du migrerar till Azure DevOps Services från din lokala Azure DevOps Server. Mer information om hur du konfigurerar kvarhållningsprinciper finns i vår dokumentation om hur du anger kvarhållningsprinciper för versioner, versioner och tester.

Förbättring av REST API för pipelineskörningar

Tidigare returnerade REST-API:et Pipelines Runs endast lagringsplatsen self . Med den här uppdateringen returnerar REST API:et Pipelines Runs alla lagringsplatsresurser i en version.

Utökade YAML Pipelines-mallar kan nu få kontextinformation för steg, jobb och implementeringar.

Med den här uppdateringen lägger vi till en ny templateContext egenskap för job, deploymentoch stage YAML-pipelinekomponenter som ska användas tillsammans med mallar.

Här är ett scenario för att använda templateContext:

• Du använder mallar för att minska kodduplicering eller för att förbättra säkerheten för dina pipelines

• Mallen tar som parameter en lista över stages, jobseller deployments

• Mallen bearbetar indatalistan och utför vissa transformeringar på var och en av stegen, jobben eller distributionerna. Den anger till exempel den miljö där varje jobb körs eller lägger till ytterligare steg för att framtvinga efterlevnad

• Bearbetningen kräver att ytterligare information skickas av pipelineförfattaren till mallen för varje steg, jobb eller distribution i listan

Nu ska vi titta på ett exempel. Anta att du redigerar en pipeline som kör tester från slutpunkt till slutpunkt för validering av pull-begäranden. Målet är att bara testa en komponent i systemet, men eftersom du planerar att köra slutpunkt-till-slutpunkt-tester behöver du en miljö där fler av systemets komponenter är tillgängliga och du måste ange deras beteende.

Du inser att andra team har liknande behov, så du bestämmer dig för att extrahera stegen för att konfigurera miljön i en mall. Koden ser ut så här:

testing-template.yml

parameters: 
- name: testSet
  type: jobList

jobs:
- ${{ each testJob in parameters.testSet }}:
  - ${{ if eq(testJob.templateContext.expectedHTTPResponseCode, 200) }}:
    - job:
      steps:
        - script: ./createSuccessfulEnvironment.sh ${{ testJob.templateContext.requiredComponents }}
        - ${{ testJob.steps }}
  - ${{ if eq(testJob.templateContext.expectedHTTPResponseCode, 500) }}:
    - job:
      steps:
        - script: ./createRuntimeErrorEnvironment.sh ${{ testJob.templateContext.requiredComponents }}
        - ${{ testJob.steps }}

Vad mallen gör är att för varje jobb i parametern testSet anger den svaret för systemets komponenter som anges av ${{ testJob.templateContext.requiredComponents }} för att returnera ${{ testJob.templateContext.expectedHTTPResponseCode }}.

Sedan kan du skapa en egen pipeline som sträcker sig testing-template.yml som i följande exempel.

sizeapi.pr_validation.yml

trigger: none

pool:
  vmImage: ubuntu-latest

extends:
  template: testing-template.yml
  parameters:
    testSet:
    - job: positive_test
      templateContext:
        expectedHTTPResponseCode: 200
        requiredComponents: dimensionsapi
      steps:
      - script: ./runPositiveTest.sh
    - job: negative_test
      templateContext:
        expectedHTTPResponseCode: 500
        requiredComponents: dimensionsapi
      steps:
      - script: ./runNegativeTest.sh

Den här pipelinen kör två tester, en positiv och en negativ. Båda testerna kräver att komponenten dimensionsapi är tillgänglig. Jobbet positive_test förväntar sig att dimensionsapi koden återlämnar HTTP 200, medan negative_test förväntar sig att den återlämnar HTTP 500.

Hanterade tjänstkonton för supportgrupp som agenttjänstkonto

Azure Pipelines-agenten har nu stöd för grupphanterade tjänstkonton på lokalt installerade agenter i Windows.

Grupphanterade tjänstkonton tillhandahåller centraliserad lösenordshantering för domänkonton som fungerar som tjänstkonton. Azure Pipelines-agenten kan identifiera den här typen av konto så att inget lösenord krävs under konfigurationen:

.\config.cmd --url https://dev.azure.com/<Organization> `
             --auth pat --token <PAT> `
             --pool <AgentPool> `
             --agent <AgentName> --replace `
             --runAsService `
             --windowsLogonAccount <DOMAIN>\<gMSA>

Informationskörningar

En informationskörning anger att Azure DevOps inte kunde hämta en YAML-pipelines källkod. En sådan körning ser ut så här.

Azure DevOps hämtar en YAML-pipelines källkod som svar på externa händelser, till exempel en push-överföring eller som svar på interna utlösare, till exempel för att kontrollera om det finns kodändringar och starta en schemalagd körning eller inte. När det här steget misslyckas skapar systemet en informationsrapport. Dessa körningar skapas endast om pipelinens kod finns på en GitHub- eller BitBucket-lagringsplats.

Det går inte att hämta en pipelines YAML-kod på grund av:

• Lagringsplatsens leverantör drabbas av ett avbrott
• Begäranstryckning
• Autentiseringsproblem
• Det går inte att hämta innehållet i pipelinens .yml-fil

Läs mer om Informationskörningar.

REST API-egenskapen retentionRules för Build Definition är föråldrad

I rest-API:ets svarstyp BuildDefinition för build definition markeras retentionRules egenskapen nu som föråldrad eftersom den här egenskapen alltid returnerar en tom uppsättning.

Repos

Nya TFVC-sidor

Vi har uppdaterat olika sidor i Azure DevOps för att använda en ny webbplattform med målet att göra upplevelsen mer konsekvent och mer tillgänglig för de olika tjänsterna. TFVC-sidor har uppdaterats för att använda den nya webbplattformen. Med den här versionen gör vi de nya TFVC-sidorna allmänt tillgängliga.

Inaktivera en lagringsplats

Kunder har ofta begärt ett sätt att inaktivera en lagringsplats och hindra användare från att komma åt dess innehåll. Du kanske till exempel vill göra detta när:

• Du hittade en hemlighet på lagringsplatsen.
• Ett genomsökningsverktyg från tredje part fann att en lagringsplats inte var kompatibel.

I sådana fall kanske du tillfälligt vill inaktivera lagringsplatsen medan du arbetar för att lösa problemet. Med den här uppdateringen kan du inaktivera en lagringsplats om du har behörighet att ta bort lagringsplats . Genom att inaktivera en lagringsplats:

• Kan visa lagringsplatsen i listan över lagringsplatser
• Det går inte att läsa innehållet i lagringsplatsen
• Det går inte att uppdatera innehållet på lagringsplatsen
• Se ett meddelande om att lagringsplatsen har inaktiverats när de försöker komma åt lagringsplatsen i Azure Repos-användargränssnittet

När nödvändiga åtgärder har vidtagits kan användare med behörigheten Ta bort lagringsplats återaktivera lagringsplatsen. Om du vill inaktivera eller aktivera en lagringsplats går du till Projektinställningar, väljer Lagringsplatser och sedan den specifika lagringsplatsen.

Konfigurera grenskreatörer så att de inte får "Hantera behörigheter" på sina grenar

När du skapar en ny gren får du "Hantera behörigheter" för den grenen. Med den här behörigheten kan du ändra behörigheter för andra användare eller tillåta ytterligare användare att bidra till den grenen. En grenskapare kan till exempel använda den här behörigheten för att tillåta att en annan extern användare gör ändringar i koden. Eller så kan de tillåta att en pipeline (byggtjänstidentitet) ändrar koden i den grenen. I vissa projekt med högre efterlevnadskrav bör användarna inte kunna göra sådana ändringar.

Med den här uppdateringen kan du konfigurera alla lagringsplatser i ditt teamprojekt och begränsa grenskapare från att få behörigheten "Hantera behörigheter". Det gör du genom att gå till projektinställningarna, välja Lagringsplatser och sedan Inställningar för alla lagringsplatser eller en specifik lagringsplats.

Den här inställningen är aktiverad som standard för att efterlikna det befintliga beteendet. Men du kan stänga av den om du vill använda den nya säkerhetsfunktionen.

Förhindra användare av förgreningar från att rösta på sina överordnade pull-begäranden

Med Azure Repos kan användare med läsbehörighet på en lagringsplats förgrena lagringsplatsen och göra ändringar i sin förgrening. För att skicka en pull-begäran med sina ändringar i uppströms behöver användarna behörigheten "bidra till pull-begäranden" i uppströms. Den här behörigheten styr dock också vem som kan rösta på pull-begäranden på den överordnade lagringsplatsen. Därför kan du hamna i situationer där en användare, som inte är deltagare i lagringsplatsen, kan skicka en pull-begäran och göra så att den sammanfogas beroende på hur du konfigurerar förgreningsprinciperna.

I projekt som främjar en modell för inre källor är förgrening och bidrag ett vanligt mönster. För att skydda och höja upp det här mönstret ytterligare ändrar vi behörigheten att rösta på en pull-begäran från "bidra till pull-begäranden" till "bidra". Den här ändringen görs dock inte som standard i alla projekt. Du måste anmäla dig och välja en ny princip på lagringsplatsen med namnet "Strikt röstläge" för att växla den här behörigheten. Vi rekommenderar att du gör det om du förlitar dig på gafflarna i Azure Repos.

Rapportering

Gruppera efter taggar som är tillgängliga i diagramwidgetar

Diagramwidgeten Gruppera efter taggar är nu tillgänglig som standard för alla kunder. När du använder diagramwidgeten finns det nu ett alternativ för taggar. Användare kan visualisera sin information genom att välja alla taggar eller en uppsättning taggar i widgeten.

Visa typer av anpassade arbetsobjekt i burndown-widgeten

Tidigare kunde du inte se anpassade arbetsobjektstyper som konfigurerats i burn down-panelen och summerats eller räknats av ett anpassat fält. Med den här uppdateringen har vi åtgärdat problemet, och nu kan du se anpassade typer av arbetsobjekt i burndown-widgeten.

Feedback

Vi vill gärna höra från dig! Du kan rapportera ett problem eller ge en idé och spåra det via Utvecklarcommunityn och få råd om Stack Overflow.