Viktig information om Azure DevOpsServer 2020 Update 1

Developer Community | Systemkrav | licensvillkor | DevOps Blog | SHA-1 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-krav. Om du vill ladda ned Azure DevOps-produkter går du till sidan Azure DevOps Server-nedladdningar.

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

---

Uppgradera säkert från Azure DevOps Server 2019 till Azure DevOps Server 2020

Azure DevOps Server 2020 introducerar en ny pipelinekörning (build) kvarhållningsmodell som fungerar baserat på inställningar på projektnivå.

Azure DevOps Server 2020 hanterar byggkvarhållning på olika sätt, baserat på kvarhållningsprinciper på pipelinenivå. Vissa principkonfigurationer leder till att pipelinekörningar tas bort efter uppgraderingen. Pipelinekörningar som har behållits manuellt eller som behålls av en release tas inte bort efter uppgraderingen.

Läs vårt blogginlägg för mer information om hur du på ett säkert sätt uppgraderar från Azure DevOps Server 2019 till Azure DevOps Server 2020.

Versionsdatum för Azure DevOps Server 2020 Update 1.2 Patch 15: 11 mars 2025

Fil	SHA-256 Hash
devops2020.1.2patch15.exe	66B6FDE4949C0B7A87B20F3BC8E0673774401929D8B75E37F599DFF8BA74ABE5

Vi har släppt Patch 15 för Azure DevOps Server 2020 Update 1.2 för att inkludera följande:

• Uppdatera uppgifter på grund av Edgio CDN-utfasning. Mer information finns i blogginlägget Växla CDN-leverantörer.

Versionsdatum för Azure DevOps Server 2020 Update 1.2 Patch 14: 12 november 2024

Fil	SHA-256 Hash
devops2020.1.2patch14.exe	89AF4B1FCA1E2BD813A42F0D3E568E64AB470E5FD0A2F87F9E4894B8CA361420

Vi har släppt Patch 14 för Azure DevOps Server 2020 Update 1.2 för att inkludera en uppgradering till ett sårbart beroende.

Versionsdatum för Azure DevOps Server 2020 Update 1.2 Patch 13: 12 mars 2024

Fil	SHA-256 hash
devops2020.1.2patch13.exe	55B0A30EABD66EB22AA6093B7750EF3CFEFE79423018E304503CE728158F56F6

Vi har släppt Patch 13 för Azure DevOps Server 2020 Update 1.2 som innehåller korrigeringar för följande:

• Löste ett problem där proxyservern slutade fungera efter installationen av Korrigering 12.

Versionsdatum för Azure DevOps Server 2020 Update 1.2 Patch 12: 13 februari 2024

Fil	SHA-256 Hash
devops2020.1.2patch12.exe	C4C9EEBBDD3B07C36658C9F78AEA57A980AA633F99DF2A3AD5036F957F095E53

Vi har släppt Patch 12 för Azure DevOps Server 2020 Update 1.2 som innehåller korrigeringar för följande:

• Ett fel har åtgärdats där diskutrymmet som används av proxycachemappen beräknades felaktigt och mappen inte rensades korrekt.
• CVE-2024-20667: Sårbarhet för körning av fjärrkod i Azure DevOps Server.

Versionsdatum för Azure DevOps Server 2020 Update 1.2 Patch 11: 12 december 2023

Fil	SHA-256 Hash
devops2020.1.2patch11.exe	C47B9C898C2E08527F1DDC3E7A5E67F1A11C3AFF860DE9B5FF3DD8718C3AAE87

Vi har släppt Patch 11 för Azure DevOps Server 2020 Update 1.2 som innehåller korrigeringar för följande:

• En bugg har åtgärdats där säkerhetsarv för fördistributionens godkännande inte fungerade i stegen i pipelines.

Versionsdatum för Azure DevOps Server 2020 Update 1.2 Patch 10: 14 november 2023

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

• Utökade gruppen av tillåtna tecken för PowerShell-uppgifter för Aktivera validering av shell-uppgifter och argumentparameter.

Anteckning

För att implementera korrigeringar för den här korrigeringen måste du följa ett antal steg för att manuellt uppdatera uppgifter.

Installera korrigeringar

Viktig

Vi släppte uppdateringar till Azure Pipelines-agenten med Patch 8 som släpptes den 12 september 2023. Om du inte installerade agentuppdateringarna enligt beskrivningen i versionsanteckningarna för Patch 8, rekommenderar vi att du installerar dessa uppdateringar innan du installerar Patch 10. Den nya versionen av agenten efter installationen av Patch 8 blir 3.225.0.

Konfigurera TFX

1. Följ stegen i ladda upp uppgifter till dokumentationen för projektsamlingen för att installera och logga in med tfx-cli.

Uppdatera uppgifter med TFX

Fil	SHA-256 Hash
Tasks20231103.zip	389BA66EEBC32622FB83402E21373CE20AE040F70461B9F9AF9EFCED5034D2E5

1. Ladda ned och extrahera Tasks20231103.zip.
2. Ändra katalogen till de extraherade filerna.
3. Kör följande kommandon för att ladda upp uppgifterna:

tfx build tasks upload --task-zip-path AzureFileCopyV1.1.230.0.zip
tfx build tasks upload --task-zip-path AzureFileCopyV2.2.230.0.zip 
tfx build tasks upload --task-zip-path AzureFileCopyV3.3.230.0.zip 
tfx build tasks upload --task-zip-path AzureFileCopyV4.4.230.0.zip 
tfx build tasks upload --task-zip-path AzureFileCopyV5.5.230.0.zip 
tfx build tasks upload --task-zip-path BashV3.3.226.2.zip 
tfx build tasks upload --task-zip-path BatchScriptV1.1.226.0.zip 
tfx build tasks upload --task-zip-path PowerShellV2.2.230.0.zip 
tfx build tasks upload --task-zip-path SSHV0.0.226.1.zip 
tfx build tasks upload --task-zip-path WindowsMachineFileCopyV1.1.230.0.zip 
tfx build tasks upload --task-zip-path WindowsMachineFileCopyV2.2.230.0.zip 

Krav för pipeline

Om du vill använda det nya beteendet måste en variabel AZP_75787_ENABLE_NEW_LOGIC = true anges i pipelines som använder de berörda uppgifterna.

• Angående klassisk

  Definiera variabeln på variabelfliken i pipelinen.

• YAML-exempel:

variables: 
- name: AZP_75787_ENABLE_NEW_LOGIC 
  value: true 

Versionsdatum för Azure DevOps Server 2020 Update 1.2 Patch 9: 10 oktober 2023

Viktig

Vi släppte uppdateringar till Azure Pipelines-agenten med Patch 8 som släpptes den 12 september 2023. Om du inte har installerat agentuppdateringarna enligt beskrivningen i viktig information för Patch 8rekommenderar vi att du installerar dessa uppdateringar innan du installerar Patch 9. Den nya versionen av agenten efter installationen av Patch 8 blir 3.225.0.

Vi har släppt en -patch. för Azure DevOps Server 2020 Update 1.2 som innehåller korrigeringar för följande.

• En bugg har åtgärdats där "Analysägare"-identiteten visas som inaktiv på patch-uppgraderade datorer.

Versionsdatum för Azure DevOps Server 2020 Update 1.2 Patch 8: 12 september 2023

Vi har släppt en korrigering för Azure DevOps Server 2020 Update 1.2 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.

Viktig

Implementera åtgärden i en testmiljö och se till att miljöns pipelines fungerar som förväntat innan åtgärden tillämpas på produktion.

Note

För att implementera korrigeringar för den här korrigeringen måste du följa ett antal steg för att manuellt uppdatera agenten och uppgifterna.

Installera korrigeringar

1. Ladda ned och installera Azure DevOps Server 2020 Update 1.2 korrigering 8.

Uppdatera Azure Pipelines-agenten

1. Ladda ned agenten från: https://github.com/microsoft/azure-pipelines-agent/releases/tag/v3.225.0 – Agent_20230825.zip
2. Använd stegen som beskrivs i dokumentationen om lokalt installerade Windows-agenter för att distribuera agenten.  

Notera

AZP_AGENT_DOWNGRADE_DISABLED måste anges till "true" för att förhindra att agenten nedgraderas. I Windows kan följande kommando användas i en administrativ kommandotolk följt av en omstart. setx AZP_AGENT_DOWNGRADE_DISABLED true /M

Konfigurera TFX

1. Följ stegen i ladda upp uppgifter till dokumentationen för projektsamlingen för att installera och logga in med tfx-cli.

Uppdatera uppgifter med TFX

1. Ladda ned och extrahera Tasks_20230825.zip.
2. Ändra katalogen till de extraherade filerna.
3. Kör följande kommandon för att ladda upp uppgifterna:

tfx build tasks upload --task-zip-path AzureFileCopyV1.1.226.3.zip
tfx build tasks upload --task-zip-path AzureFileCopyV2.2.226.2.zip 
tfx build tasks upload --task-zip-path AzureFileCopyV3.3.226.2.zip 
tfx build tasks upload --task-zip-path AzureFileCopyV4.4.226.2.zip 
tfx build tasks upload --task-zip-path AzureFileCopyV5.5.226.2.zip 
tfx build tasks upload --task-zip-path BashV3.3.226.2.zip 
tfx build tasks upload --task-zip-path BatchScriptV1.1.226.0.zip 
tfx build tasks upload --task-zip-path PowerShellV2.2.226.1.zip 
tfx build tasks upload --task-zip-path SSHV0.0.226.1.zip 
tfx build tasks upload --task-zip-path WindowsMachineFileCopyV1.1.226.2.zip 
tfx build tasks upload --task-zip-path WindowsMachineFileCopyV2.2.226.2.zip 

Krav för rörledning

Om du vill använda det nya beteendet måste en variabel AZP_75787_ENABLE_NEW_LOGIC = true anges i pipelines som använder de berörda uppgifterna.

• Om klassiskt:

  Definiera variabeln på variabelfliken i pipelinen.

• YAML-exempel:

variables: 
- name: AZP_75787_ENABLE_NEW_LOGIC 
  value: true 

Versionsdatum för Azure DevOps Server 2020 Update 1.2 Patch 7: 8 augusti 2023

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

• CVE-2023-36869: Azure DevOps Server Spoofing Vulnerability.
• Uppdatera SSH-tjänsten för att stödja SHA2-256 och SHA2-512. Om du har hårdkodade SSH-konfigurationsfiler för att använda RSA bör du uppdatera till SHA2 eller ta bort posten.
• Åtgärdat problem med relativa länkar som inte fungerar i Markdown-filer.
• Fixade en bugg med kommentarsnavigering på en commitsida.
• 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 2020 Update 1.2 Patch 6: 13 juni 2023

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

• CVE-2023-21565: Azure DevOps Server Spoofing Vulnerability.
• CVE-2023-21569: Azure DevOps Server Spoofing Vulnerability.
• Åtgärdade ett fel som störde push-paket vid uppgradering från 2018 eller tidigare.
• Å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 2020 Update 1.2 Patch 5: 14 februari 2023

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

• CVE-2023-21553: Sårbarhet för körning av fjärrkod i Azure DevOps Server
• Åtgärdat problem med tillgänglighet för shelvesets via webbgränssnittet.
• Kunder måste starta om tfsjobagent-tjänsten och Azure DevOps Server-programpoolen efter uppdatering av SMTP-relaterade inställningar i Azure DevOps Server Management Console.

Versionsdatum för Azure DevOps Server 2020 Update 1.2 Patch 4: 13 december 2022

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

• Visningen av specialtecken i IdentityPicker har korrigerats.

• Testdata togs inte bort, vilket gjorde att databasen växte. Med den här korrigeringen uppdaterade vi byggkvarhållningen för att förhindra att nya överblivna testdata skapas.

Versionsdatum för Azure DevOps Server 2020 Update 1.2 Patch 3: 18 oktober 2022

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

• Lös problemet med nyligen tillagda AD-identiteter som inte visas i säkerhetsdialogrutans identitetsväljare.
• Åtgärda ett problem med filtret Begärd av gruppmedlem i inställningarna för webbhooken.
• Åtgärda fel med gated check-in builds när organisationsinställningarna för pipelinen hade jobbauktoriseringsomfånget konfigurerat som Begränsa jobbauktoriseringsomfånget till det aktuella projektet för pipelines som inte släpps.
• Åtgärda hämtning av åtkomsttoken från Azure när du upprättar tjänstanslutning bakom autentiserad proxy.

Versionsdatum för Azure DevOps Server 2020 Update 1.2 Patch 2: 9 augusti 2022

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

• Åtgärda identitetsvärdefel när du tilldelar ett arbetsobjekt till en identitet som visas i olika domäner.

Versionsdatum för Azure DevOps Server 2020 Update 1.2 Patch 1: 12 juli 2022

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

• I API:er för testkörningar var fortsättningstoken som returnerades större än värdet "maxLastUpdatedDate" som angavs.

Versionsdatum för Azure DevOps Server 2020 Update 1.2: 17 maj 2022

Azure DevOps Server 2020 Update 1.2 är en sammanställning av felkorrigeringar. Du kan installera Azure DevOps Server 2020 Update 1.2 direkt eller uppgradera från Azure DevOps Server 2020 eller Team Foundation Server 2013 eller senare.

Notera

Datamigreringsverktyget kommer att vara tillgängligt för Azure DevOps Server 2020 Update 1.2 ungefär tre veckor efter den här versionen. Du kan se vår lista över versioner som stöds för import här.

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

• Azure DevOps Server 2020.1.2 inaktiverar den nya kvarhållningsmodellen (introducerades i Azure DevOps Server 2020) för att förhindra förlust av pipelinekörningar (versioner). Det innebär att systemet kommer att:

  • Skapa leasingavtal för de senaste 3 versionerna som genererades medan Server 2020 kördes
  • För YAML-pipelines och klassiska pipelines utan kvarhållningsprinciper per pipeline behålls byggen enligt högsta kvarhållningsinställningar på samlingsnivå
  • För klassiska pipelines med anpassade kvarhållningsprinciper per pipeline behålls byggen enligt den pipelinespecifika kvarhållningsprincipen
  • Byggen med lån räknas inte mot inställningen Minimum för att behålla

• Länkarna changeset och shelveset comments omdirigerades inte korrekt. När kommentarer lades till i filer i ändringsuppsättningar eller hylluppsättningar, omdirigerades inte filvyn till rätt plats när dessa kommentarer valdes.

• Det går inte att hoppa över byggkön med hjälp av knappen "Kör nästa". Tidigare aktiverades knappen "Kör nästa" endast för projektsamlingsadministratörer.

• Återkalla alla personliga åtkomsttoken när en användares Active Directory-konto har inaktiverats.

Versionsdatum för Azure DevOps Server 2020.1.1 Patch 4: 26 januari 2022

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

• E-postaviseringar skickades inte när du använde @mention-kontrollen i ett arbetsobjekt.
• Önskad e-postadress uppdaterades inte i användarprofilen. Detta resulterade i att e-postmeddelanden skickades till den tidigare e-postadressen.
• Rubriken visades inte på sidan Projektsammanfattning. Rubriken visades under några millisekunder och sedan försvann den.
• Förbättring av Active Directory-användarsynkronisering.
• Åtgärdat Elasticsearch-sårbarhet genom att ta bort klassen jndilookup från log4j-binärfiler.

Installationssteg

1. Uppgradera servern med Patch 4.
2. Kontrollera registervärdet på HKLM:\Software\Elasticsearch\Version. Om registervärdet inte finns där lägger du till ett strängvärde och anger Version till 5.4.1 (Namn = Version, Värde = 5.4.1).
3. Kör uppdateringskommandot PS C:\Program Files\{TFS Version Folder}\Search\zip> .\Configure-TFSSearch.ps1 -Operation update enligt beskrivningen i readme-filen. Det kan returnera en varning som: Det går inte att ansluta till fjärrservern. Stäng inte fönstret eftersom uppdateringen utför återförsök förrän den har slutförts.

Anteckning

Om Azure DevOps Server och Elasticsearch är installerade på olika datorer följer du stegen nedan.

1. Uppgradera servern med Patch 4.
2. Kontrollera registervärdet på HKLM:\Software\Elasticsearch\Version. Om registervärdet inte finns där lägger du till ett strängvärde och anger Version till 5.4.1 (Namn = Version, Värde = 5.4.1).
3. Kopiera innehållet i mappen med namnet zip, som finns på C:\Program Files\{TFS Version Folder}\Search\zip, till den fjärrmapp som används för Elasticsearch.
4. Kör Configure-TFSSearch.ps1 -Operation update på Elasticsearch-serverdatorn.

SHA-256 Hash: 451F0BB73132EFCD2B3D292F0040DBF2BCF2808C35D3C37CA5A3CD8F65F29D6

Versionsdatum för Azure DevOps Server 2020.1.1 Patch 3: 15 december 2021

Patch 3- för Azure DevOps Server 2020.1.1 innehåller korrigeringar för följande.

• Åtgärda makro för arbetsobjekt för frågor med "Innehåller ord". Tidigare returnerade frågor felaktiga resultat för värden som innehöll en radbrytning.
• Öka gränserna för maven-paketversionens teckenlängd.
• Lokaliseringsproblem för layouttillstånd för anpassade arbetsobjekt.
• Lokaliseringsproblem i mallen för e-postaviseringar.
• Problem med NOTSAMEAS-regelutvärdering när flera NOTSAMEAS-regler definierades för ett fält.

Versionsdatum för Azure DevOps Server 2020.1.1 Patch 2: 26 oktober 2021

Patch 2- för Azure DevOps Server 2020.1.1 innehåller korrigeringar för följande.

• Tidigare kunde Azure DevOps Server bara skapa anslutningar till GitHub Enterprise Server. Med den här korrigeringen kan projektadministratörer skapa anslutningar mellan Azure DevOps Server och lagringsplatser på GitHub.com. Du hittar den här inställningen på sidan GitHub-anslutningar under Projektinställningar.
• Lös problem med testplanswidgeten. Testkörningsrapporten visade en felaktig användare i resultaten.
• Åtgärda problem med att sammanfattningssidan för projektöversikten inte kunde läsas in.
• Åtgärda problem med att e-postmeddelanden inte skickas för att bekräfta produktuppgradering.

Versionsdatum för Azure DevOps Server 2020.1.1 Patch 1: 14 september 2021

Patch 1 för Azure DevOps Server 2020.1.1 innehåller korrigeringar för följande.

• Åtgärda problem vid nedladdning eller uppladdning av artefakter.
• Lös problem med inkonsekventa testresultatdata.

Versionsdatum för Azure DevOps Server 2020 Update 1.1: 17 augusti 2021

Azure DevOps Server 2020 Update 1.1 är en sammanställning av felkorrigeringar. Du kan installera Azure DevOps Server 2020 Update 1.1 direkt eller uppgradera från Azure DevOps Server 2020 eller Team Foundation Server 2013 eller senare.

Anmärkning

Datamigreringsverktyget kommer att vara tillgängligt för Azure DevOps Server 2020 Update 1.1 ungefär tre veckor efter den här versionen. Du kan se vår lista över versioner som stöds för import här.

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

Azure Boards

• Hyperlänken "Visa arbetsobjekt" i e-postmeddelandena för meddelanden använder inte den offentliga URL:en.

Azure Repos

• Kryssrutor för visning av ärftlighet med begränsade sammanslagningstyper har åtgärdats för att möjliggöra ändring av typer av begränsad sammanslagning efter inställning av principer för korslagring.

Azure Pipelines

• När inställningen för Agentuppdatering ändrades spreds inte inställningarna till andra programnivåer i miljön.

Allmänt

• Stavningsguiden för serverkonfiguration har åtgärdats.
• Ökad storlek på tilläggspaketet och gör att du kan ändra storleken i registret.

Azure-testplaner

• Det går inte att gå tillbaka till testresultat när du har slagit tillbaka från historik till sammanfattningssida.

---

Versionsdatum för Azure DevOps Server 2020.1 Patch 2: 10 augusti 2021

Vi har släppt en korrigering för Azure DevOps Server 2020.1 som åtgärdar följande.

• Åtgärda användargränssnittsfel för byggdefinition.
• Webbhistoriken ändrades för att visa filer i stället för rotlagringsplatsen.

Versionsdatum för Azure DevOps Server 2020.1 Patch 1: 15 juni 2021

Vi har släppt en korrigering för Azure DevOps Server 2020.1 som åtgärdar följande.

• Skydda cookies som används i auktoriseringsflöden som bekräftar SameSite=None.

• Lös problem med Notifications SDK. Tidigare parsades inte aviseringsprenumerationer med filtret Områdessökväg korrekt.

Utgivningsdatum för Azure DevOps Server 2020.1 RTW: 25 maj 2021

Sammanfattning av nyheter i Azure DevOps Server 2020.1 RTW

Azure DevOps Server 2020.1 RTW är en samling av felkorrigeringar. Den innehåller alla funktioner i Azure DevOps Server 2020.1 RC2 som släpptes tidigare. Azure DevOps Server 2020.1 RTW är en sammanslagning av felkorrigeringar. Du kan installera Azure DevOps Server 2020.1 direkt eller uppgradera från Azure DevOps Server 2020, 2019 eller Team Foundation Server 2015 eller senare.

Not

Datamigreringsverktyget kommer att vara tillgängligt för Azure DevOps Server 2020 Update 1 ungefär tre veckor efter den här versionen. Du kan se vår lista över versioner som stöds för import här.

Lanseringsdatum för Azure DevOps Server 2020.1 RC2: 13 april 2021

Sammanfattning av nyheter i Azure DevOps Server 2020.1 RC2

Azure DevOps Server 2020.1 RC2 är en uppdatering av buggfixar. Den innehåller alla funktioner i Azure DevOps Server 2020.1 RC1 som släpptes tidigare.

Lanseringsdatum för Azure DevOps Server 2020.1 RC1: 23 mars 2021

Sammanfattning av nyheter i Azure DevOps Server 2020.1 RC1

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

• Regler för begränsning av tillståndsövergång i Tavlor
• Intressenter kan nu flytta arbetsobjekt över olika kolumner
• Förbättra versionssäkerheten genom att begränsa omfånget för åtkomsttoken
• Förbättrad upplevelse av pull-begäranden
• Multi-repo-utlösare i Pipelines

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

• tavlor
• Lagringsplatser
• Pipelines
• Föremål

---

Styrelser

Regler för begränsning av tillståndsövergång

Vi fortsätter att stänga funktionsparitetsgapet mellan värdbaserad XML och den ärvda processmodellen. Med den här nya regeln för arbetsobjektstyp kan du begränsa att arbetsobjekt flyttas från ett tillstånd till ett annat. Du kan till exempel begränsa Buggar från att gå från nytt till löst. I stället måste de gå från New –> Active –> Resolved

Du kan också skapa en regel för att begränsa tillståndsövergångar efter gruppmedlemskap. Till exempel kan endast användare i gruppen Godkännare flytta användarberättelser från New –> Approved.

Kopiera arbetsobjekt för att kopiera underordnade objekt

En av de mest efterfrågade funktionerna för Azure Boards är möjligheten att kopiera ett arbetsobjekt som också kopierar de underordnade arbetsobjekten. Vi har lagt till ett nytt alternativ för att inkludera underordnade arbetsobjekt i dialogrutan kopiera arbetsobjekt. När du väljer det här alternativet kopieras arbetsobjektet samt alla underordnade arbetsobjekt (upp till 100).

Förbättrade regler för aktiverade och lösta fält

Hittills har reglerna för Aktiverad av, Aktiveringsdatum, Löst avoch Lösningsdatum varit ett mysterium. De anges endast för systemarbetsobjekttyper och är specifika för tillståndsvärdet "Aktiv" och "Löst". Vi har ändrat logiken så att dessa regler inte längre är för ett specifikt tillstånd. I stället utlöses de av den kategori (tillståndskategori) som tillståndet finns i. Tänk dig till exempel att du har ett anpassat tillstånd för "Behöver testas" i kategorin Löst. När arbetsobjektet ändras från "Aktiv" till "Behöver testas" utlöses reglerna Löst av och Löst datum.

Detta gör att kunderna kan skapa anpassade tillståndsvärden och ändå generera Aktiverad av, Aktiverat Datum, Löst avoch Löst Datum fältet, utan behov av att använda anpassade regler.

Intressenter kan flytta arbetsobjekt över brädkolumner

Intressenter har alltid kunnat ändra arbetsobjektens tillstånd. Men när de går till Kanban-tavlan kan de inte flytta arbetsobjekten från en kolumn till en annan. I stället skulle intressenter behöva öppna varje arbetsobjekt, ett i taget, och uppdatera tillståndsvärdet. Detta har länge varit ett problemområde för kunderna, och vi är glada att kunna meddela att du nu kan flytta arbetsobjekt mellan tavlans kolumner.

Systemarbetsobjekttyper på kvarvarande uppgifter och tavlor

Nu kan du lägga till en typ av systemarbetsobjekt till valfri nivå för kvarvarande uppgifter. Historiskt sett har dessa typer av arbetsobjektstyper endast varit tillgängliga från frågeformulär.

Process	Typ av arbetsobjekt
Agil	Utfärda
Scrum	Hinder
CMMI	Ändringsbegäran
	Utfärda
	Recension
	Risk

Det är enkelt att lägga till en systemarbetsobjekttyp till en backlognivå. Gå bara in i din anpassade process och klicka på fliken Backlognivåer. Välj valfri backlognivå (exempel: Kravbacklog) och välj redigeringsalternativet. Lägg sedan till arbetsobjekttypen.

Azure Boards GitHub-apprepogräns har höjts

Lagringsplatsens gräns för Azure Boards-program på GitHub Marketplace har ökats från 100 till 250.

Anpassa arbetsobjektets tillstånd när pull-begäran slås samman

Alla arbetsflöden är inte desamma. Vissa kunder vill stänga sina relaterade arbetsobjekt när en pull request har slutförts. Andra vill ställa in arbetsobjekten på en annan status som ska verifieras innan de stängs. Vi bör tillåta båda.

Vi har en ny funktion som gör att du kan ange arbetsobjekten till önskat tillstånd när pull-begäran slås samman och slutförs. För att göra detta genomsöker vi beskrivningen av pull-begäran och letar efter tillståndsvärdet följt av #mention för arbetsobjekten. I det här exemplet ställer vi in två användarberättelser på Löst och stänger två uppgifter.

Länka arbetsobjektet till byggen i ett annat projekt

Nu kan du enkelt spåra dina byggberoenden i projekt bara genom att länka ditt arbetsobjekt till en Build, Found in build eller Integrated in build.

Redigera beskrivning (hjälptext) på systemfält

Du har alltid kunnat redigera beskrivningen av anpassade fält. Men för systemfält som prioritet, allvarlighetsgrad och aktivitet kunde beskrivningen inte redigeras. Det här var ett funktionsgap mellan värdbaserad XML och Ärvd som hindrade vissa kunder från att migrera till den ärvda modellen. Nu kan du redigera beskrivningen för systemfält. Det redigerade värdet påverkar bara det fältet i processen och för den typen av arbetsobjekt. Detta ger dig flexibiliteten att ha olika beskrivningar för samma fält på olika typer av arbetsobjekt.

Anpassa arbetsobjektets tillstånd när pull-begäran slås samman

Pull-begäranden refererar ofta till flera arbetsobjekt. När du skapar eller uppdaterar en pull-begäran kanske du vill stänga några av dem, lösa några av dem och hålla resten öppet. Du kan nu använda kommentarer som de som visas i bilden nedan för att åstadkomma detta. Mer information finns i dokumentation.

Föräldrafält på aktivitetstavlan

På grund av en populär begäran kan du nu lägga till fältet Överordnad till både underordnade och överordnade kort på aktivitetstavlan.

Ta bort regeln "Tilldelad till" för typ av buggarbetsobjekt

Det finns flera dolda systemregler för alla olika typer av arbetsobjekt i Agile, Scrum och CMMI. Dessa regler har funnits i över ett decennium och har i allmänhet fungerat bra utan några klagomål. Det finns dock ett par regler som inte längre är välkomna. En regel i synnerhet har orsakat mycket smärta för nya och befintliga kunder och vi har beslutat att det var dags att ta bort den. Den här regeln finns på typen buggarbetsobjekt i den Agila processen.

"Ange det tilldelade värdet till Skapad av när tillståndet ändras till Löst"

Vi har fått mycket feedback om den här regeln. Som svar gick vi vidare och tog bort den här regeln från typ av buggarbetsobjekt i agilprocessen. Den här ändringen påverkar varje projekt som använder en ärvd Agile eller en anpassad ärvd Agile-process. För de kunder som gillar och är beroende av den här aktuella regeln kan du läsa vårt blogginlägg om de steg du kan vidta för att lägga till regeln igen med hjälp av anpassade regler.

Borttagna objekt på sidan Arbetsobjekt

Sidan Arbetsobjekt är ett bra ställe att snabbt hitta objekt som du har skapat eller som har tilldelats dig, bland annat. Den innehåller flera anpassade pivoter och filter. Ett av de främsta klagomålen för pivoten "Tilldelad till mig" är att den visar borttagna arbetsobjekt (det vill säga arbetsobjekt i tillståndet borttaget). Och vi håller med! Borttagna objekt är arbete som inte längre är av värde och därför har tagits bort från kvarvarande uppgifter, så att inkludera det i den här vyn är inte användbart.

Nu kan du dölja alla borttagna poster från fliken Tilldelad till mig på sidan Arbetsobjekt.

Repos

Standardinställning för grennamn

Azure Repos erbjuder nu ett anpassningsbart standardgrennamn för Git. I lagringsplatsens inställningar kan du välja valfritt namn på den juridiska grenen som ska användas när en lagringsplats initieras. Azure Repos har alltid stöd för att ändra standardgrennamnet för en befintlig lagringsplats.

Mer information finns i Hantera grenar och Ändra standardgrenen.

Inställning på organisationsnivå för standardgren

Det finns nu en inställning på kollektionsnivå för ditt föredragna initiala grennamn för nya förvar. Om ett projekt inte har valt ett första grennamn används den här inställningen på organisationsnivå. Om du inte angav det första grennamnet i organisationsinställningarna eller projektinställningarna använder nya lagringsplatser en Azure DevOps-definierad standard.

Lägga till ett nytt autentiseringsomfång för att bidra med PR-kommentarer

Den här versionen lägger till ett nytt OAuth-omfång för att läsa och skriva pull-begäranskommentarer. Om du har en robot eller automatisering som bara behöver interagera med kommentarer kan du ge den en PAT med endast det här omfånget. Den här processen minskar explosionsradien om automatiseringen har en bugg eller om token komprometterades.

Förbättringar av upplevelsen med pull-begäranden

Den nya upplevelsen av pull-requests har förbättrats med följande:

• Gör de valfria kontrollerna mer synliga

Kunder använder valfria kontroller för att uppmärksamma en utvecklare på potentiella problem. Tidigare var det uppenbart när kontrollerna misslyckas. Så är dock inte fallet i förhandsversionen. En stor, grön bockmarkering på de kontroller som krävs maskerar felen i valfria kontroller. Användarna kunde bara upptäcka att valfria kontroller misslyckades genom att öppna kontrollpanelen. Utvecklare gör inte ofta det när det inte finns några tecken på ett problem. I den här distributionen gjorde vi statusen för valfria kontroller mer synlig i sammanfattningen.

• Ctrl-klick på menyalternativ

Tabbmenyer på en PR har inte stöd för Ctrl-klick. Användare öppnar ofta nya webbläsarflikar när de granskar en pull-begäran. Detta har åtgärdats.

• Placering av [+] anteckning

Trädlistan över filer i en PR visar en anteckning [+] som hjälper författare och granskare att identifiera nya filer. Eftersom anteckningen var efter ellipsen var den ofta inte synlig för längre filnamn.

• PR-uppdateringarnas listruta återfår tidsinformation

Listrutan för att välja uppdatera och jämföra filer i en PR förlorade ett viktigt element i förhandsversionen. Det visades inte när uppdateringen gjordes. Detta har åtgärdats.

• **Förbättrad layout för kommentarsfilter **

När du filtrerade kommentarer på sammanfattningssidan för en pull request fanns listrutan till höger, men texten var vänsterjusterad. Detta har åtgärdats.

• Navigering till överordnade inskickningar

På sidan Åtaganden kan du jämföra ändringarna som gjorts i ett visst åtagande med dess föregående åtagande. Du kanske dock vill navigera till den överordnade committen och ytterligare förstå hur den skiljer sig från sin egen överordnade. Detta behövs ofta när du vill förstå alla ändringar i en version. Vi har lagt till ett överordnat kort i en commit för att hjälpa dig att uppnå detta.

• Mer utrymme för mappar och filer med långa namn på fliken PR-filer

Mappar och filer med långa namn avbröts på grund av brist på horisontellt avstånd i filträdet. Vi återställde ytterligare utrymme i trädet genom att ändra trädets indrag så att det matchar rotnoden och genom att dölja ellipsknappen från sidan förutom vid hovring.

Bild av det nya filträdet:

Bild av filträdet när du hovrar över en katalog:

• Bevara rullningspositionen när du ändrar storlek på diff-fönstret på fliken PR-filer

När du ändrar storlek på difffönstret sida vid sida i fliken PR-filer, kommer användarens rullningsposition att gå förlorad. Det här problemet har åtgärdats; användarens scrollposition behålls nu när man ändrar storlek på ett diff-fönster.

• Sök efter ett commit på en mobil enhet

När du visar sidan Commits på en mobil enhet saknas sökrutan i det nya gränssnittet. Därför är det svårt för dig att hitta en commit med dess hash och öppna den. Detta har åtgärdats nu.

• Förbättrad användning av utrymme för den nya mobila PR-fildiffvyn

Vi har uppdaterat den här sidan för att bättre använda utrymmet så att användarna kan se mer av filen i mobila vyer i stället för att ha 40% av skärmen som tas upp av en rubrik.

• Förbättrade avbildningar i PR-sammanfattningsvyn

Bilder som redigerats i en PR visades inte i PR-sammanfattningsvyn men visades korrekt i vyn PR-filer. Det här problemet har lösts.

• förbättrad grenupplevelse när du skapar en ny PR-

Före den här uppdateringen var den här upplevelsen inte idealisk eftersom den skulle jämföra ändringarna med standardgrenen för lagringsplatsen i stället för jämförelsegrenen.

Rörledningar

Ytterligare agentplattform: ARM64

Vi har lagt till Linux/ARM64 i listan över plattformar som stöds för Azure Pipelines-agenten. Även om kodändringarna var minimala var mycket arbete bakom kulisserna tvunget att slutföras först, och vi är glada över att kunna tillkännage dess lansering!

Stöd för taggfilter för pipelineresurser

Vi har nu lagt till "taggar" i YAML-pipelines. Du kan använda taggar för att ange att CI-pipelinen ska köras eller när den ska utlösas automatiskt.

resources:
  pipelines:
  - pipeline: MyCIAlias
    project: Fabrikam
    source: Farbrikam-CI
    branch: main
    tags:              ### This filter is used for resolving default version
    - Production       ### Tags are AND'ed
    trigger:
      tags:            ### This filter is used for triggering the pipeline run
      - Production     ### Tags are AND'ed
      - Signed

Ovanstående kodfragment visar att taggar kan användas för att fastställa standardversionen av CI-pipelinen (kontinuerlig integrering) som ska köras när CD-pipelinekörningen (kontinuerlig distribution) inte utlöses av någon annan källa/resurs eller en schemalagd körningsutlösare.

Om du till exempel har en schemalagd utlösare inställd för din CD-pipeline som du bara vill köra om din CI har produktionstaggen, säkerställer taggarna i avsnittet utlösare att CD-pipelinen endast utlöses om taggningsvillkoret uppfylls av CI-slutförandehändelsen.

Kontrollera vilka uppgifter som tillåts i pipelines

Nu kan du inaktivera Marketplace-uppgifter. Vissa av er kan tillåta Marketplace-tillägg, men inte de Pipelines-uppgifter som de tar med sig. För ännu mer kontroll kan du också inaktivera alla in-the-box-uppgifter separat (förutom utcheckning, vilket är en speciell åtgärd). När båda dessa inställningar är aktiverade är de enda uppgifter som tillåts köras i en pipeline de som laddas upp med hjälp av tfx. Gå till https://dev.azure.com/<your_org>/_settings/pipelinessettings och leta efter avsnittet "Uppgiftsbegränsningar" för att komma igång.

Exklusiv policy för utplaceringslås

Med den här uppdateringen kan du se till att endast en drift åt gången distribueras till en miljö. Genom att välja markeringen "Exklusivt lås" i en miljöinställning kommer bara en körning att fortsätta. Framtida försök att distribuera till den miljön kommer att pausas. När körningen med det exklusiva låset har slutförts fortsätter den senaste körningen. Alla mellanliggande körningar avbryts.

Stegvisa filter för pipelineresursutlösare

Vi har lagt till stöd för "faser" som ett filter för pipelineresurser i YAML. Med det här filtret behöver du inte vänta tills hela CI-pipelinen är klar innan du startar din CD-pipeline. Du kan nu välja att utlösa din CD-pipeline när en specifik fas i CI-pipelinen har slutförts.

resources:
  pipelines:
  - pipeline: MyCIAlias  
    project: Fabrikam  
    source: Farbrikam-CI  
    trigger:    
      stages:            ### This stage filter is used when evaluating conditions for triggering your CD pipeline
      - PreProduction    ### stages are AND'ed. On successful completion of all the stages provided, your CD pipeline will be triggered. 
      - Production

När stegen i utlösarfiltret har slutförts i din CI-pipeline, utlöses automatiskt en ny körning för din CD-pipeline.

Generiska webhookbaserade utlösare för YAML-pipelines

Idag har vi olika resurser (till exempel pipelines, containrar, bygge och paket) genom vilka du kan använda artefakter och aktivera automatiserade utlösare. Hittills har du dock inte kunnat automatisera distributionsprocessen baserat på andra externa händelser eller tjänster. I den här versionen introducerar vi stöd för webhook-utlösare i YAML-pipelines för att möjliggöra integrering av pipelineautomatisering med alla externa tjänster. Du kan prenumerera på externa händelser via dess webhooks (Github, Github Enterprise, Nexus, Aritfactory osv.) och utlösa dina pipelines.

Här följer stegen för att konfigurera webhooksutlösare:

1. Konfigurera en webhook på den externa tjänsten. När du skapar webhooken måste du ange följande information:

   • Url för begäran – "https://dev.azure.com/<ADO-samling>/_apis/public/distributedtask/webhooks/<WebHook-namn>?api-version=6.0-preview"
   • Hemlighet – det här är valfritt. Om du behöver skydda din JSON-nyttolast, ange då det hemliga värdet Secret.

2. Skapa en ny tjänstanslutning för "Incoming Webhook". Det här är en nyligen introducerad tjänstanslutningstyp som gör att du kan definiera tre viktiga uppgifter:

   • Webhook Name: Namnet på webhooken ska matcha webhooken som skapats i din externa tjänst.
   • HTTP-huvud – Namnet på HTTP-huvudet i begäran som innehåller nyttolastens hashvärde för verifiering av begäran. När det till exempel gäller GitHub blir begärandehuvudet "X-Hub-Signature"
   • Secret – Hemligheten används för att parsa nyttolastens hash som används för verifiering av inkommande begäran (detta är valfritt). Om du har använt en hemlighet för att skapa din webhook måste du ange samma hemliga nyckel

   

3. En ny resurstyp med namnet webhooks introduceras i YAML-pipelines. För att prenumerera på en webhook-händelse måste du definiera en webhook-resurs i pipelinen och peka den på den inkommande webhook-tjänstanslutningen. ** Du kan också definiera ytterligare filter på webhookresursen baserat på data från JSON-nyttolasten för att ytterligare anpassa triggrarna för varje pipeline, och du kan använda nyttolastdata i form av variabler i dina jobb.

resources:
  webhooks:
    - webhook: MyWebhookTrigger          ### Webhook alias
      connection: MyWebhookConnection    ### Incoming webhook service connection
      filters:
        - path: repositoryName      ### JSON path in the payload
          value: maven-releases     ### Expected value in the path provided
        - path: action
          value: CREATED
steps:
- task: PowerShell@2
  inputs:
    targetType: 'inline'
    ### JSON payload data is available in the form of ${{ parameters.<WebhookAlias>.<JSONPath>}}
    script: |
      Write-Host ${{ parameters.MyWebhookTrigger.repositoryName}}
      Write-Host ${{ parameters.MyWebhookTrigger.component.group}}

4. När en webhook-händelse tas emot av den inkommande Webhook-tjänstanslutningen utlöses en ny körning för alla pipelines som prenumererar på webhook-händelsen.

Stöd och spårning av problem med YAML-resursutlösare

Det kan vara förvirrande när pipelineutlösare inte kan köras som du förväntar dig. För att bättre förstå detta har vi lagt till ett nytt menyalternativ på pipelinedefinitionssidan med namnet "Utlösarproblem" där information visas om varför utlösare inte körs.

Resursutlösare kan inte köras av två orsaker.

1. Om källan för den angivna tjänstanslutningen är ogiltig, eller om det finns syntaxfel i utlösaren, konfigureras inte utlösaren alls. Dessa visas som fel.

2. Om utlösarvillkoren inte matchas körs inte utlösaren. När detta inträffar visas en varning så att du kan förstå varför villkoren inte matchades.

   

Utlösare för flera lagringsplatser

Du kan ange flera lagringsplatser i en YAML-fil och orsaka att en pipeline utlöses av uppdateringar till någon av lagringsplatserna. Den här funktionen är till exempel användbar i följande scenarier:

• Du använder ett verktyg eller ett bibliotek från en annan lagringsplats. Du vill köra tester för ditt program när verktyget eller biblioteket uppdateras.
• Du behåller YAML-filen på en separat lagringsplats från programkoden. Du vill utlösa pipelinen varje gång en uppdatering skickas till programlagringsplatsen.

Med den här uppdateringen fungerar utlösare för flera lagringsplatser endast för Git-lagringsplatser i Azure Repos. De fungerar inte för GitHub- eller BitBucket-lagringsplatsens resurser.

Här är ett exempel som visar hur du definierar flera lagringsplatsresurser i en pipeline och hur du konfigurerar utlösare för dem alla.

trigger:
- main

resources:
  repositories:
  - repository: tools
    type: git
    name: MyProject/tools
    ref: main
    trigger:
      branches:
        include:
        - main
        - release

Pipelinen i det här exemplet utlöses om det finns några uppdateringar till:

• main gren i self-lagringsplatsen som innehåller YAML-filen
• main eller release grenar i tools repo

Mer information finns i Flera lagringsplatser i pipelinen.

Uppladdningar av agentloggar har förbättrats

När en agent slutar kommunicera med Azure Pipelines-servern blir jobbet det körde övergivet. Om du råkade titta på loggarna för strömningskonsolen kan du ha fått några ledtrådar om vad agenten höll på med precis innan den slutade svara. Men om du inte var det, eller om du uppdaterade sidan, var konsolloggarna borta. Med den här versionen, om agenten slutar svara innan den skickar upp sina fullständiga loggar, behåller vi konsolloggarna som det näst bästa. Konsolloggar är begränsade till 1 000 tecken per rad och kan ibland vara ofullständiga, men de är mycket mer användbara än att inte visa någonting! Att undersöka dessa loggar kan hjälpa dig att felsöka dina egna pipelines, och det hjälper säkert våra supporttekniker när de hjälper till med felsökning.

Du kan valfritt montera containervolymer med skrivskydd

När du kör ett containerjobb i Azure Pipelines mappas flera volymer som innehåller arbetsytan, uppgifter och annat material som volymer. Dessa volymer har som förval läs- och skrivåtkomst. För ökad säkerhet kan du montera volymerna som skrivskyddade genom att ändra containerspecifikationen i YAML. Varje nyckel under mountReadOnly kan ställas in på true för skrivskyddad läge (standardvärdet är false).

resources:
  containers:
    - container: example
      image: ubuntu:18.04
      mountReadOnly:
        externals: true
        tasks: true
        tools: true
        work: false

Detaljerad kontroll över containerstart/stopp

I allmänhet rekommenderar vi att du låter Azure Pipelines hantera livscykeln för dina jobb- och tjänstcontainrar. Men i vissa ovanliga scenarier kanske du vill starta och stoppa dem själv. Med den här versionen har vi byggt in den funktionen i Docker-uppgiften.

Här är en exempelpipeline med den nya funktionen:

resources:
  containers:
    - container: builder
      image: ubuntu:18.04
steps:
  - script: echo "I can run inside the container (it starts by default)"
    target:
      container: builder
  - task: Docker@2
    inputs:
      command: stop
      container: builder
# if any step tried to run in the container here, it would fail

Dessutom inkluderar vi listan över containrar i en pipelinevariabel, Agent.ContainerMapping. Du kan till exempel använda detta om du vill granska listan över containrar i ett skript. Den innehåller ett strängifierat JSON-objekt som mappar resursnamnet ("builder" från exemplet ovan) till det container-ID som agenten hanterar.

Packa upp uppgiftsbuntar för varje steg

När agenten kör ett jobb laddar den först ned alla uppgiftspaket som krävs enligt jobbets steg. För att förbättra prestandan packar det normalt upp uppgiften en gång per jobb även om uppgiften används i flera steg. Om du är orolig för att opålitlig kod ändrar det uppackade innehållet kan du offra lite prestanda genom att låta agenten packa upp uppgiften vid varje användningstillfälle. Om du vill aktivera det här läget skickar du --alwaysextracttask när du konfigurerar agenten.

Förbättra versionssäkerheten genom att begränsa åtkomsttokens omfång

Genom att bygga vidare på vårt initiativ för att förbättra säkerhetsinställningarna för Azure Pipelines har vi nu stöd för att begränsa omfattningen av åtkomsttoken för versioner.

Varje jobb som körs i versioner får en åtkomsttoken. Åtkomsttoken används av uppgifterna och av dina skript för att anropa tillbaka till Azure DevOps. Vi använder till exempel åtkomsttoken för att hämta källkod, ladda ned artefakter, ladda upp loggar, testa resultat eller för att göra REST-anrop till Azure DevOps. En ny åtkomsttoken genereras för varje jobb och upphör att gälla när jobbet har slutförts.

Med den här uppdateringen förbättrar vi pipelinesäkerheten genom att begränsa omfattningen av åtkomsttokener och tillämpar samma säkerhetsåtgärder på klassiska versioner.

Den här funktionen är aktiverad som standard för nya projekt och samlingar. För befintliga samlingar måste du aktivera detta i samlingens Inställningar > Pipelines > Inställningar. > Begränsa omfånget för jobbauktorisering till det aktuella projektet för utgivningspipelines. Läs mer här.

Förbättringar av API:et för YAML-förhandsversion

Nu kan du förhandsgranska hela YAML- av en pipeline utan att köra den. Dessutom har vi skapat en dedikerad ny URL för förhandsgranskningsfunktionen. Nu kan du POST till https://dev.azure.com/{collection}/{project}/_apis/pipelines/{pipelineId}/preview för att hämta det färdiga YAML-innehållet. Det nya API:et använder samma parametrar som att köa en körning, men kräver inte längre behörigheten "Köa byggen".

Kör det här jobbet nästa

Har du någonsin haft ett buggfix som du behövde distribuera omedelbart men var tvungen att vänta bakom CI- och PR-jobb? Med den här versionen kan du nu öka prioriteten för ett köat jobb. Användare med behörigheten "Hantera" i poolen – vanligtvis pooladministratörer – ser en ny "Kör nästa"-knapp på sidan med jobbinformation. Om du klickar på knappen kommer jobbet att köras så snart som möjligt. (Du behöver fortfarande tillgänglig parallellitet och en lämplig agent, naturligtvis.)

Malluttryck som är tillåtna i YAML-resources-block

Tidigare tilläts inte kompileringstidsuttryck (${{ }}) i avsnittet resources i en AZURE Pipelines YAML-fil. Med den här versionen har vi lyft den här begränsningen för containrar. På så sätt kan du använda körparameter innehåll i dina resurser, till exempel för att välja en container vid kötid. Vi planerar att utöka det här stödet till andra resurser över tid.

Kontroll över automatiska aktivitetsuppdateringar från Marketplace

När du skriver en YAML-pipeline anger du normalt bara huvudversionsnumret för de inkluderade uppgifterna. På så sätt kan dina pipelines automatiskt ta de senaste funktionstilläggen och felkorrigeringarna. Ibland kan du behöva återställa till en tidigare punktversion av en uppgift, och med den här uppdateringen har vi lagt till möjligheten för dig att göra det. Nu kan du ange en fullständig major.minor.patch-uppgiftsversion i YAML-pipelines.

Vi rekommenderar inte att du gör detta regelbundet och använder det endast som en tillfällig lösning när du finner att en nyare uppgift förstör dina pipelines. Detta kommer inte heller att installera en äldre version av en uppgift från Marketplace. Den måste redan finnas i din samling, annars kommer din pipeline att misslyckas.

Exempel:

steps:
- task: MyTask@1  # a normal, major-version only reference
- task: MyOtherTask@2.3.4   # pinned to a precise version

Stöd för Nod 10 i agent och uppgifter

Eftersom nod 6 inte längre stöds migrerar vi uppgifterna för att arbeta med Nod 10. För den här uppdateringen har vi migrerat nästan 50% av in-box-uppgifter till Nod 10. Agenten kan nu köra både Node 6- och Node 10-uppgifter. I en framtida uppdatering tar vi helt bort Nod 6 från agenten. För att förbereda för borttagning av Nod 6 från agenten ber vi dig att uppdatera dina interna tillägg och anpassade uppgifter så att du även använder Node 10 snart. Om du vill använda Nod 10 för din uppgift uppdaterar du i task.jsonunder executionfrån Node till Node10.

Förbättra YAML-konverteringen i den klassiska byggdesignern

Med den här versionen introducerar vi en ny "export till YAML"-funktion för designergenereringspipelines. Spara pipelinedefinitionen och leta sedan upp "Exportera till YAML" på ...-menyn.

Den nya exportfunktionen ersätter funktionen "Visa som YAML" som tidigare hittades i den klassiska byggdesignern. Den funktionen var ofullständig eftersom den bara kunde kontrollera vad webbgränssnittet kände till om bygget, vilket ibland ledde till att felaktig YAML genererades. Den nya exportfunktionen tar hänsyn till exakt hur pipelinen ska bearbetas och genererar YAML med fullständig återgivning till designerpipelinen.

Ny webbplattformskonvertering – Lagringsplatsinställningar

Vi har konverterat de två sidorna för lagringsplatsinställningar till en enda upplevelse som har uppgraderats till en ny webbplattform. Den här uppgraderingen gör inte bara upplevelsen snabbare och modernare, utan de här sidorna ger också en enda startpunkt för alla principer från projektnivån till grennivån.

Med den här nya upplevelsen har navigeringen för projekt med ett stort antal lagringsplatser blivit enklare på grund av snabbare inläsningstider och ett extra sökfilter. Du kan också visa principer på projektnivå och listan över principer för flera lagringsplatser under fliken Principer.

Om du klickar på en lagringsplats kan du visa principer och behörigheter som angetts på lagringsplatsnivå. På fliken Principer kan du visa en lista över varje gren som principen är inställd på. Klicka nu på grenen för att se principerna samtidigt som du aldrig lämnar sidan Lagringsplatsinställningar.

Nu, när principer ärvs från ett högre omfång än vad du arbetar med, visar vi dig var principen ärvdes bredvid varje enskild princip. Du kan också navigera till sidan där principen på högre nivå angavs genom att klicka på omfångsnamnet.

Själva principsidan har också uppgraderats till den nya webbplattformen med komprimerbara avsnitt! För att förbättra upplevelsen av att söka efter en viss Build-validering, status-kontroll eller automatisk granskarpolicy har vi lagt till sökfilter för varje avsnitt.

ServiceNow-ändringshanteringsintegrering med YAML-pipelines

Azure Pipelines-appen för ServiceNow hjälper dig att integrera Azure Pipelines och ServiceNow Change Management. Med den här uppdateringen tar vi vårt arbete med att anpassa Azure Pipelines till ändringshanteringsprocessen som hanteras i ServiceNow ytterligare ett steg mot YAML-pipelines.

Genom att konfigurera kontrollen "ServiceNow Change Management" på en resurs kan du nu pausa för att ändringen ska godkännas innan du distribuerar bygget till den resursen. Du kan automatiskt skapa en ny ändring för en fas eller vänta på en befintlig ändringsbegäran.

Du kan också lägga till UpdateServiceNowChangeRequest uppgift i ett serverjobb för att uppdatera ändringsbegäran med distributionsstatus, anteckningar osv.

Artefakter

Möjlighet att skapa organisationsspecifika flöden från användargränssnittet

Vi tar tillbaka möjligheten för kunder att skapa och hantera samlingsomfångsflöden via webbgränssnittet för både lokala och värdbaserade tjänster.

Nu kan du skapa organisationsomfattande feeds via användargränssnittet genom att gå till Artefakter –> Skapa feed och välja en typ av feed inom omfattning.

Vi rekommenderar att du använder feeds med projektomfattning i enlighet med resten av Azure DevOps-erbjudanden, men du kan återigen skapa, hantera och använda samlingsomfångsfeeds via användargränssnittet och olika REST-API:er. Mer information finns i dokumentationen för flöden.

REST API för uppdatering av paketversion är nu tillgängligt för Maven-paket

Nu kan du använda REST-API:et för Azure Artifacts "Update Package Version" för att uppdatera Maven-paketversioner. Tidigare kunde du använda REST-API:et för att uppdatera paketversioner för NuGet-, Maven-, npm- och Universal Packages, men inte Maven-paket.

Om du vill uppdatera Maven-paket använder du HTTP PATCH-kommandot på följande sätt.

PATCH https://pkgs.dev.azure.com/{collection}/{project?}/\_apis/packaging/feeds/{feedId}/maven/groups/{groupId}/artifacts/{artifactId}/versions/{packageVersion}?api-version=5.1-preview.1

Du kan ange följande:

URI-parametrar

Namn	i	Krävs	typ	Beskrivning
artifactId	stig	SANN	sträng	Artefakt-ID för paketet
mata	stig	SANN	sträng	Namn eller ID för feeden
groupId	stig	SANN	sträng	Grupp-ID för paketet
samling	stig	SANN	sträng	Namnet på Azure DevOps-samlingen
version	stig	SANN	sträng	Version av paketet
projekt	stig		sträng	Projekt-ID eller projektnamn
api-version	fråga	SANN	sträng	Version av API:et som ska användas. Detta bör anges till "5.1-preview.1" för att använda den här versionen av API:et

begärandetext

Namn	Typ	Beskrivning
Visningar	JsonPatchOperation	Vyn som paketversionen ska läggas till i

Mer information finns i REST API-dokumentationen när den uppdateras.

Feedback

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

---

överst på sidan