Viktig information om Azure DevOps Server 2020

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ållts manuellt eller som behålls av en version 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 0.2 Patch 6: 14 november 2023

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

• Utökade listan över tillåtna tecken för PowerShell-uppgifter för aktivera validering av parameterargument för shell-uppgifter.

Notera

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 4 som släpptes den 12 september 2023. Om du inte har installerat agentuppdateringarna enligt beskrivningen i versionsinformation för patch 4rekommenderar vi att du installerar dessa uppdateringar innan du installerar patch 6. Den nya versionen av agenten efter installationen av Patch 4 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 Hashvärde
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.

• På klassiska:

  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 0.2 Patch 5: 10 oktober 2023

Viktig

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

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

• En bugg har åtgärdats där identiteten "Analysägare" visas som Inaktiv identitet på datorer för korrigeringsuppgradering.

Versionsdatum för Azure DevOps Server 2020 Update 0.2 Patch 4: 12 september 2023

Vi har släppt en korrigering för Azure DevOps Server 2020 Update 0.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: Azure DevOps Server och Team Foundation Server sårbarhet för eskalering av behörighet.

Viktig

Distribuera patchen till en testmiljö och se till att miljöns pipelines fungerar som förväntat innan patchen tillämpas på produktionsmiljön.

Notera

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 0.2 patch 4.

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 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.

• På klassiska:

  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 0.2 Patch 3: 8 augusti 2023

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

• Åtgärdade ett fel som störde push-paket vid uppgradering från 2018 eller tidigare.

Versionsdatum för Azure DevOps Server 2020 Update 0.2 Patch 2: 13 juni 2023

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

• Åtgärdade ett fel som störde push-paket vid uppgradering från 2018 eller tidigare.

Versionsdatum för Azure DevOps Server 2020 Update 0.2 Patch 1: 18 oktober 2022

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

Versionsdatum för Azure DevOps Server 2020.0.2: 17 maj 2022

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

Not

Datamigreringsverktyget kommer att vara tillgängligt för Azure DevOps Server 2020.0.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:

• 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.0.1 Patch 9: 26 januari 2022

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

• E-postaviseringar skickades inte när du använde @mention-kontrollen i ett arbetsobjekt.
• Åtgärda TF400813 fel vid byte av konton. Det här felet uppstod när det uppgraderades från TFS 2018 till Azure DevOps Server 2020.0.1.
• Åtgärda problem med att sammanfattningssidan för projektöversikten inte kunde läsas in.
• 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 9.
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.

Not

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

1. Uppgradera servern med Patch 9..
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 från C:\Program Files\{TFS Version Folder}\Search\zip till fjärrmappen Elasticsearch.
4. Kör Configure-TFSSearch.ps1 -Operation update på Elasticsearch-serverdatorn.

SHA-256 Hash: B0C05A972C73F253154AEEB7605605EF2E596A96A3720AE942D7A9DDD881545E

Versionsdatum för Azure DevOps Server 2020.0.1 Patch 8: 15 december 2021

Patch 8 för Azure DevOps Server 2020.0.1 innehåller korrigeringar för följande.

• Lokaliseringsproblem för layouttillstånd för anpassade arbetsobjekt.
• Lokaliseringsproblem i mallen för e-postaviseringar.
• Problem med att konsolloggar trunkeras när det finns flera identiska länkar i en rad.
• Problem med NOTSAMEAS-regelutvärdering när flera NOTSAMEAS-regler definierades för ett fält.

Versionsdatum för Azure DevOps Server 2020.0.1 Patch 7: 26 oktober 2021

Patch 7 för Azure DevOps Server 2020.0.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.0.1 Patch 6: 14 september 2021

Patch 6 för Azure DevOps Server 2020.0.1 innehåller korrigeringar för följande.

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

Versionsdatum för Azure DevOps Server 2020.0.1 Patch 5: 10 augusti 2021

Patch 5 för Azure DevOps Server 2020.0.1 innehåller korrigeringar för följande.

• Åtgärda fel i användargränssnittet för byggdefinition.
• Webbhistoriken ändrades för att visa filer i stället för rotlagringsplatsen.
• Åtgärda problem med e-postleveransjobb för vissa arbetsobjektstyper.

Versionsdatum för Azure DevOps Server 2020.0.1 Patch 4: 15 juni 2021

Patch 4- för Azure DevOps Server 2020.0.1 innehåller korrigeringar för följande.

• Åtgärda problem med dataimport. Dataimporten tog lång tid för kunder som har många inaktuella testfall. Detta berodde på referenser som ökade storleken på tabellen tbl_testCaseReferences. Med den här korrigeringen har vi tagit bort referenser till inaktuella testfall för att påskynda dataimportprocessen.

Versionsdatum för Azure DevOps Server 2020.0.1 Patch 3: 11 maj 2021

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

• Inkonsekventa testresultatdata när du använder Microsoft.TeamFoundation.TestManagement.Client.

Om du har Azure DevOps Server 2020.0.1 bör du installera Azure DevOps Server 2020.0.1 Patch 3.

Verifiering av installation

• Alternativ 1: Kör devops2020.0.1patch3.exe CheckInstall, devops2020.0.1patch3.exe är filen som laddas ned från länken ovan. Kommandots utdata anger antingen att korrigeringen har installerats eller att den inte är installerad.

• Alternativ 2: Kontrollera versionen av följande fil: [INSTALL_DIR]\Azure DevOps Server 2020\Application Tier\bin\Microsoft.Teamfoundation.Framework.Server.dll. Azure DevOps Server 2020.0.1 installeras som standard på c:\Program Files\Azure DevOps Server 2020. När du har installerat Azure DevOps Server 2020.0.1 Patch 3 blir versionen 18.170.31228.1.

Versionsdatum för Azure DevOps Server 2020.0.1 Patch 2: 13 april 2021

Anteckning

Om du har Azure DevOps Server 2020 bör du först uppdatera till Azure DevOps Server 2020.0.1 . När du har uppdaterat till 2020.0.1, installera Azure DevOps Server 2020.0.1 Patch 2

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

• CVE-2021-27067: Informationsupplysning
• CVE-2021-28459: Utökade privilegier

För att genomföra korrigeringar för denna patch måste du följa stegen nedan för generell patchinstallation, AzureResourceGroupDeploymentV2 och AzureResourceManagerTemplateDeploymentV3 uppgiftsinstallationer.

Allmän korrigeringsinstallation

Om du har Azure DevOps Server 2020.0.1 bör du installera Azure DevOps Server 2020.0.1 Patch 2.

Verifiera installation

• Alternativ 1: Kör devops2020.0.1patch2.exe CheckInstall, devops2020.0.1patch2.exe är filen som laddas ned från länken ovan. Kommandots utdata anger antingen att korrigeringen har installerats eller att den inte är installerad.

• Alternativ 2: Kontrollera versionen av följande fil: [INSTALL_DIR]\Azure DevOps Server 2020\Application Tier\bin\Microsoft.Teamfoundation.Framework.Server.dll. Azure DevOps Server 2020.0.1 installeras som standard på c:\Program Files\Azure DevOps Server 2020. När du har installerat Azure DevOps Server 2020.0.1 Patch 2 blir versionen 18.170.31123.3.

AzureResourceGroupDeploymentV2-aktivitetsinstallation

Not

Alla steg som nämns nedan måste utföras på en Windows-dator

Installera

1. Extrahera AzureResourceGroupDeploymentV2.zip-paketet till en ny mapp på datorn. Till exempel: D:\tasks\AzureResourceGroupDeploymentV2.

2. Ladda ned och installera Node.js 14.15.1 och npm (ingår i Node.js nedladdning) enligt din dator.

3. Öppna en kommandotolk i administratörsläge och kör följande kommando för att installera tfx-cli.

npm install -g tfx-cli

4. Skapa en personlig åtkomsttoken med Fullständig åtkomst behörigheter och kopiera den. Den här personliga åtkomsttoken används när du kör kommandot tfx-inloggning.

5. Kör följande från kommandotolken. När du uppmanas till det anger du tjänstens URL och personlig åtkomsttoken.

~$ tfx login
Copyright Microsoft Corporation

> Service URL: {url}
> Personal access token: xxxxxxxxxxxx
Logged in successfully

6. Kör följande kommando för att ladda upp uppgiften på servern. Använd sökvägen till den extraherade .zip-filen från steg 1.

  ~$ tfx build tasks upload --task-path *<Path of the extracted package>*

AzureResourceManagerTemplateDeploymentV3-aktivitetsinstallation

Not

Alla steg som nämns nedan måste utföras på en Windows-dator

Installera

1. Extrahera AzureResourceManagerTemplateDeploymentV3.zip-paketet till en ny mapp på datorn. Till exempel:D:\tasks\AzureResourceManagerTemplateDeploymentV3.

2. Ladda ned och installera Node.js 14.15.1 och npm (ingår i Node.js nedladdning) efter behov för din dator.

3. Öppna en kommandotolk i administratörsläge och kör följande kommando för att installera tfx-cli.

npm install -g tfx-cli

4. Skapa en personlig åtkomsttoken med Fullständig åtkomst behörigheter och kopiera den. Den här personliga åtkomsttoken används när du kör kommandot tfx-inloggning.

5. Kör följande från kommandotolken. När du uppmanas till det anger du tjänstens URL och personlig åtkomsttoken.

~$ tfx login
Copyright Microsoft Corporation

> Service URL: {url}
> Personal access token: xxxxxxxxxxxx
Logged in successfully

6. Kör följande kommando för att ladda upp uppgiften på servern. Använd sökvägen till den extraherade .zip-filen från steg 1.

  ~$ tfx build tasks upload --task-path *<Path of the extracted package>*

Versionsdatum för Azure DevOps Server 2020.0.1 Patch 1: 9 februari 2021

Vi har släppt en korrigering för Azure DevOps Server 2020.0.1 som åtgärdar följande. Mer information finns i blogginlägget .

• Lös problemet som rapporteras i den här feedbackärendet för utvecklarcommunityn| Knappen Nytt testfall fungerar inte
• Inkludera korrigeringar som släppts med Azure DevOps Server 2020 Patch 2.

Versionsdatum för Azure DevOps Server 2020 Patch 3: 9 februari 2021

Vi har släppt en korrigering för Azure DevOps Server 2020 som åtgärdar följande. Mer information finns i blogginlägget .

• Lös problemet som rapporteras i den här feedbackbegäran för utvecklarcommunityn| Knappen Nytt testfall fungerar inte

Versionsdatum för Azure DevOps Server 2020.0.1: 19 januari 2021

Azure DevOps Server 2020.0.1 är en sammanställning av felkorrigeringar. Du kan installera Azure DevOps Server 2020.0.1 direkt eller uppgradera från en befintlig installation. Versioner som stöds för uppgradering är Azure DevOps Server 2020, Azure DevOps Server 2019 och Team Foundation Server 2012 eller senare.

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

• Lös ett uppgraderingsproblem från Azure DevOps Server 2019 där Git-proxyn kan sluta fungera efter uppgraderingen.
• Åtgärda System.OutOfMemoryException-undantag för icke-ENU-samlingar före Team Foundation Server 2017 vid uppgradering till Azure DevOps Server 2020. Löser problemet som rapporterats i feedbackärende för utvecklarcommunityn.
• Servicefel som orsakas av saknade Microsoft.Azure.DevOps.ServiceEndpoints.Sdk.Server.Extensions.dll. Löser problemet som rapporteras i den här feedbackbegäran från utvecklarcommunityn.
• Åtgärda fel med ogiltigt kolumnnamn i Analytics när du uppgraderar till Azure DevOps Server 2020. Löser problemet som rapporteras i i det här feedbackärendet för utvecklarcommunityt.
• Lagrade XSS när testfallsstegen visades i testfallsresultat.
• Uppgraderingsstegfel vid migrering av poängresultatdata till TCM.

Versionsdatum för Azure DevOps Server 2020 Patch 2: 12 januari 2021

Vi har släppt en korrigering för Azure DevOps Server 2020 som åtgärdar följande. Mer information finns i blogginlägget .

• Testkörningsinformation visar inte teststegsinformation för testdata som migrerats med OpsHub Migration
• Undantag vid initiering för "Microsoft.TeamFoundation.TestManagement.Server.TCMLogger"
• Ouppnåeliga versioner tas omedelbart bort efter migreringen till Azure DevOps Server 2020
• Åtgärda undantag för dataprovider

Azure DevOps Server 2020 Patch 1 Datum: 8 december 2020

Vi har släppt en korrigering för Azure DevOps Server 2020 som åtgärdar följande. Mer information finns i blogginlägget .

• CVE-2020-17145: Azure DevOps Server och Team Foundation Services Förfalskningsrisk

Utgivningsdatum för Azure DevOps Server 2020: 6 oktober 2020

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

Notera

Azure DevOps 2020 Server har problem med att installera en av de sammansättningar som används av Git Virtual File System (GVFS).

Om du uppgraderar från Azure DevOps 2019 (en version) eller en Azure DevOps 2020-versionskandidat och installerar till samma katalog som den tidigare versionen installeras inte sammansättningen Microsoft.TeamFoundation.Git.dll. Du kan kontrollera att du har drabbats av problemet genom att leta efter Microsoft.TeamFoundation.Git.dll i mapparna <Install Dir>\Version Control Proxy\Web Services\bin, <Install Dir>\Application Tier\TFSJobAgent och <Install Dir>\Tools. Om filen saknas kan du köra en reparation för att återställa de filer som saknas.

Om du vill köra en reparation går du till Settings -> Apps & Features på Azure DevOps Server-datorn/den virtuella datorn och kör en reparation på Azure DevOps 2020 Server. När reparationen har slutförts kan du starta om datorn/den virtuella datorn.

Lanseringsdatum för Azure DevOps Server 2020 RC2: 11 augusti 2020

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

Nytt lanseringsdatum för Azure DevOps Server 2020 RC1: 10 juli 2020

Vi har återutsläppt Azure DevOps Server 2020 RC1 för att åtgärda feedbackärendet i utvecklarcommunityn.

Tidigare, efter uppgradering från Azure DevOps Server 2019 Update 1.1 till Azure DevOps Server 2020 RC1, kunde du inte visa filer i webbgränssnittets databaser, pipelines och wiki. Ett felmeddelande indikerar ett oväntat fel har inträffat i den här regionen på sidan. Du kan prova att läsa in komponenten igen eller uppdatera hela sidan. Med den här versionen har vi åtgärdat det här problemet. Mer information finns i blogginlägget .

Lanseringsdatum för Azure DevOps Server 2020 RC1: 30 juni 2020

Sammanfattning av nyheter i Azure DevOps Server 2020

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

• Flerstegspipeline
• Kontinuerlig distribution i YAML-
• Följ utvecklingen av huvudobjekt med hjälp av sammanställning på tavlors backlogg
• Lägg till filtret "Överordnat arbetsobjekt" i aktivitetstavlan och sprintarbetslistan
• nytt webbgränssnitt för Azure Repos-landningssidor
• Administration av grenprinciper mellan arkiv
• sidan ny testplan
• omfattande redigering för wiki-sidor med kod
• Pipeline-fel och varaktighetsrapporter

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

• Allmänt
• brädor
• Förvar
• Rörledningar
• Testplaner
• artefakter
• Wiki
• Rapportering

---

Allmänt

Allmän tillgänglighet för Azure DevOps CLI

I februari introducerade vi Azure DevOps-tillägget för Azure CLI. Med tillägget kan du interagera med Azure DevOps från kommandoraden. Vi har samlat in din feedback som hjälpte oss att förbättra tillägget och lägga till fler kommandon. Vi är nu glada att kunna meddela att tillägget är allmänt tillgängligt.

Mer information om Azure DevOps CLI finns i dokumentationen här.

Använda publiceringsprofil för att distribuera Azure WebApps för Windows från Distributionscenter

Nu kan du använda publiceringsprofilbaserad autentisering för att distribuera dina Azure WebApps för Windows från distributionscentret. Om du har behörighet att distribuera till en Azure WebApp för Windows med dess publiceringsprofil kan du konfigurera pipelinen med den här profilen i arbetsflödena för Distributionscenter.

Styrelser

Lägg till filtret "Överordnat arbetsobjekt" i uppgiftstavlan och sprint-backloggen

Vi har lagt till ett nytt filter i både sprinttavlan och sprintens backlog. På så sätt kan du filtrera backloggsposter på kravnivå (den första kolumnen till vänster) utifrån deras överordnade. På skärmbilden nedan har vi till exempel filtrerat vyn för att endast visa användarhistorier där den överordnade är 'Min stora huvudfunktion'.

Förbättra felhanteringsupplevelsen – obligatoriska fält för bugg/uppgift

Historiskt sett, om du flyttade ett arbetsobjekt från en kolumn till en annan på Kanban-tavlan där tillståndsändringen utlöste regler för fälten, visade kortet bara ett rött felmeddelande som tvingar dig att öppna arbetsobjektet för att förstå rotorsaken. I sprint 170 förbättrade vi upplevelsen så att du nu kan klicka på det röda felmeddelandet för att se information om felet utan att behöva öppna själva arbetsobjektet.

Live-omladdning av arbetsobjekt

Tidigare, när du uppdaterade ett arbetsobjekt och en andra gruppmedlem gjorde ändringar i samma arbetsobjekt, skulle den andra användaren förlora sina ändringar. Så länge du redigerar olika fält kommer du nu att se liveuppdateringar av de ändringar som gjorts i arbetsobjektet.

Hantera iteration och områdessökvägar från kommandoraden

Nu kan du hantera iterations- och områdessökvägar från kommandoraden med hjälp av kommandona az boards iteration och az boards area. Du kan till exempel konfigurera och hantera iteration och områdessökvägar interaktivt från CLI, eller automatisera hela installationen med hjälp av ett skript. Mer information om kommandona och syntaxen finns i dokumentationen här.

Alternativ för arbetsobjektets föräldrakolumn som kolumnalternativ

Nu har du möjlighet att se överordnat objekt för varje arbetsobjekt i din produkt-backlog eller sprint-backlog. För att aktivera funktionen går du till Kolumnalternativ i önskad backlog och lägger sedan till Förälder-kolumnen.

Ändra processen som används av ett projekt

Dina verktyg bör ändras som ditt team gör. Nu kan du byta projekt från valfri färdiga processmall till andra färdiga processer. Du kan till exempel ändra ditt projekt från att använda Agile till Scrum eller Basic till Agile. Du hittar fullständig stegvis dokumentation här.

Dölj anpassade fält från layout

Nu kan du dölja anpassade fält från formulärlayouten när du anpassar processen. Fältet är fortfarande tillgängligt från frågor och REST-API:er. Detta är praktiskt för att spåra extra fält när du integrerar med andra system.

Få insikter om teamets hälsa med tre nya Azure Boards-rapporter

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

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

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

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

Not

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

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

• Utbränningsdiagrammet finns under Sprints nav.

  

• CFD- och Velocity-rapporterna kan nås från fliken Analytics under Boards och Backlogs genom att klicka på det relevanta kortet.

  

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

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

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

Diagrammet Velocity kan nu spåras för alla kvarvarande nivåer. Nu kan du till exempel lägga till både Funktioner och Epos, medan tidigare kunde endast Krav läggas till i det föregående diagrammet. Här är ett exempel på en hastighetsrapport för de senaste 6 iterationerna av kvarvarande funktioner.

Anpassa Taskboard-kolumner

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

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

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

Växla för att visa eller dölja slutförda deluppgifter i arbetsloggen

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

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

De senaste taggarna som visas när du taggar ett arbetsobjekt

När du taggar ett arbetsobjekt kommer auto-kompletteringsfunktionen nu att visa upp till fem av dina senast använda taggar. Detta gör det enklare att lägga till rätt information i dina arbetsobjekt.

Skrivskyddade och obligatoriska regler för gruppmedlemskap

Med arbetsobjektsregler kan du ange specifika åtgärder för arbetsobjektfält för att automatisera deras beteende. Du kan skapa en regel för att ange ett fält till skrivskyddat eller obligatoriskt baserat på gruppmedlemskap. Du kanske till exempel vill ge produktägare möjlighet att ange prioriteten för dina funktioner samtidigt som du gör den skrivskyddad för alla andra.

Anpassa systemlistvärden

Nu kan du anpassa värdena för valfri systemlistelista (förutom orsaksfältet) som Allvarlighetsgrad, Aktivitet, Prioritet osv. Anpassningarna av listrutan är begränsade så att du kan hantera olika värden för samma fält för varje arbetsobjektstyp.

Url-parameter för nytt arbetsobjekt

Dela länkar till arbetsobjekt med kontexten från din tavla eller arbetskö med vår nya URL-parameter för arbetsobjekt. Nu kan du öppna en dialogruta för arbetsobjekt på din tavla, kvarvarande uppgifter eller din sprintupplevelse genom att lägga till parametern ?workitem=[ID] till URL:en.

Alla du delar länken med kommer sedan att landa med samma kontext som du hade när du delade länken!

Nämn personer, arbetsobjekt och PR:ar i textfält

När vi lyssnade på din feedback hörde vi att du ville kunna nämna personer, arbetsobjekt och PR:er i arbetsobjektets beskrivningsområde (och andra HTML-fält) på arbetsobjektet och inte bara i kommentarer. Ibland samarbetar du med någon i ett arbetsobjekt eller vill markera en PR i beskrivningen av arbetsobjektet, men inte har något sätt att lägga till den informationen. Nu kan du nämna personer, arbetsobjekt och PR:er i alla långa textfält i arbetsobjektet.

Du kan se ett exempel här.

• Om du vill använda personomnämnanden skriver du @-tecknet och personens namn som du vill nämna. @mentions i fält för arbetsobjekt kommer att generera e-postmeddelanden på samma sätt som för kommentarer.
• Om du vill använda omnämnanden av arbetsobjekt skriver du #-tecknet följt av arbetsobjektets ID eller rubrik. #mentions skapar en länk mellan de två arbetsobjekten.
• Om du vill använda PR-omnämnanden lägger du till en ! följt av ditt PR-ID eller namn.

Reaktioner på diskussionskommenter

Ett av våra huvudmål är att göra arbetsobjekten mer samarbetsinriktade för team. Nyligen genomförde vi en omröstning på Twitter för att ta reda på vilka samarbetsfunktioner du vill ha i diskussioner om arbetsobjektet. Reaktioner på kommentarer vann omröstningen, så vi lägger till dem! Här är resultatet av Twitter-undersökningen.

Du kan lägga till reaktioner på alla kommentarer, och det finns två sätt att lägga till dina reaktioner – smiley-ikonen i det övre högra hörnet av en kommentar, samt längst ned i en kommentar bredvid eventuella befintliga reaktioner. Du kan lägga till alla sex reaktioner om du vill, eller bara en eller två. Om du vill ta bort din reaktion klickar du på reaktionen längst ned i kommentaren så tas den bort. Nedan kan du se upplevelsen av att lägga till en reaktion, samt hur reaktionerna ser ut på en kommentar.

Fästa Azure Boards-rapporter på instrumentpanelen

I Sprint 155-uppdateringen inkluderade vi uppdaterade versioner av CFD- och Velocity-rapporterna. Dessa rapporter är tillgängliga under fliken Analys i Boards och Backlogs. Nu kan du fästa rapporterna direkt på instrumentpanelen. Fäst rapporterna genom att hovra över rapporten, välja ellipsen "..." och Kopiera till instrumentpanelen.

Spåra förloppet för huvudobjekt med hjälp av Rollup-funktionen på tavlans backlog

Sammanfattningskolumner visar förloppsstaplar och/eller summor av numeriska fält eller underelement i en hierarki. Underordnade objekt motsvarar alla barnobjekt i hierarkin. En eller flera summeringskolumner kan läggas till i en produkt- eller portföljarbetsreserv.

Här visar vi till exempel Förlopp efter arbetsobjekt som visar förloppsstaplar för stigande arbetsobjekt baserat på procentandelen underordnade objekt som har stängts. Underordnade objekt för Epics innehåller alla relaterade funktioner och deras arbetsobjekt på barn- eller barnbarnsnivå. Underordnade objekt för funktioner innehåller alla underordnade användarberättelser och deras underordnade arbetsobjekt.

Liveuppdateringar för Aktivitetstavla

Din aktivitetstavla uppdateras nu automatiskt när ändringar sker! När andra teammedlemmar flyttar eller ändrar ordning på korten i aktivitetstavlan uppdateras din styrelse automatiskt med dessa ändringar. Du behöver inte längre trycka på F5 för att se de senaste ändringarna.

Stöd för anpassade fält i uppsummeringskolumner

Sammanslagning kan nu göras på valfritt fält, inklusive anpassade fält. När du lägger till en rollup-kolumn kan du fortfarande välja en rollup-kolumn från snabblistan, men om du vill sammankoppla numeriska fält som inte ingår i standardprocessmallen kan du konfigurera din egen på följande sätt:

1. Klicka på "Kolumnalternativ" i din backlog. Klicka sedan på "Add Rollup column" i panelen och konfigurera anpassad rollup.

   

2. Välj mellan Förloppsindikator och Total.
3. Välj en typ av arbetsobjekt eller en backlog-nivå (vanligtvis aggregerar backloggar flera typer av arbetsobjekt).
4. Välj aggregeringstyp. Antal arbetsobjekt eller Summa. För Summa måste du välja det fält som ska sammanfattas.
5. Knappen OK tar dig tillbaka till panelen kolumnalternativ där du kan ändra ordning på den nya anpassade kolumnen.

Observera att du inte kan redigera din anpassade kolumn när du har klickat på OK. Om du behöver göra en ändring tar du bort den anpassade kolumnen och lägger till en till efter behov.

Ny regel för att dölja fält i ett arbetsobjektsformulär baserat på villkor

Vi har lagt till en ny regel i den ärvda regelmotorn så att du kan dölja fält i ett arbetsobjektformulär. Den här regeln döljer fält baserat på användarnas gruppmedlemskap. Om användaren till exempel tillhör gruppen "produktägare" kan du dölja ett utvecklarspecifikt fält. Mer information finns i dokumentationen här.

Meddelandeinställningar för anpassat arbetsobjekt

Det är otroligt viktigt att hålla dig uppdaterad om arbetsobjekt som är relevanta för dig eller ditt team. Det hjälper teamen att samarbeta och hålla sig på rätt spår med projekt och ser till att alla rätt parter är inblandade. Olika intressenter har dock olika investeringsnivåer i olika insatser, och vi anser att det bör återspeglas i din förmåga att följa statusen för en arbetsuppgift.

Om du tidigare ville följa ett arbetsobjekt och få meddelanden om ändringar som gjorts skulle du få e-postaviseringar för alla ändringar som gjorts i arbetsobjektet. Efter att ha beaktat er feedback gör vi uppföljningen av en arbetsuppgift mer flexibel för alla intressenter. Nu visas en ny inställningsknapp bredvid knappen Följ längst upp till höger i arbetsobjektet. Detta tar dig till ett popup-fönster där du kan konfigurera följande alternativ.

Från Meddelandeinställningarkan du välja mellan tre meddelandealternativ. Först kan du avsluta prenumerationen helt. För det andra kan du prenumerera fullt ut, där du får meddelanden om alla ändringar i arbetsobjektet. Slutligen kan du välja att få aviseringar om några av de viktigaste och viktiga ändringshändelserna för arbetsobjekt. Du kan bara välja ett eller alla tre alternativen. Detta gör att teammedlemmar kan följa arbetsobjekt på en högre nivå och inte distraheras av varje enskild ändring som görs. Med den här funktionen eliminerar vi onödiga e-postmeddelanden och gör att du kan fokusera på viktiga uppgifter.

Länka arbetsobjekt till distributioner

Vi är glada över att kunna släppa distributionskontrollen i arbetsobjektsformuläret. Den här kontrollen länkar dina arbetsobjekt till en version och gör att du enkelt kan spåra var ditt arbetsobjekt har distribuerats. Mer information finns i dokumentationen här.

Importera arbetsobjekt från en CSV-fil

Hittills har import av arbetsobjekt från en CSV-fil varit beroende av att använda Excel-plugin-programmet. I den här uppdateringen tillhandahåller vi en förstklassig importupplevelse direkt från Azure Boards så att du kan importera nya eller uppdatera befintliga arbetsobjekt. Mer information finns i dokumentationen här.

Lägga till överordnat fält i arbetsobjektkort

Överordnad kontext är nu tillgänglig i Kanban-tavlan som ett nytt fält för arbetsobjektkort. Nu kan du lägga till fältet Överordnat i korten och kringgå behovet av att använda lösningar som taggar och prefix.

Lägg till förälderfält till backlogg och sökfrågor

Det överordnade fältet är nu tillgängligt när du visar kvarvarande uppgifter och frågeresultat. Om du vill lägga till det överordnade fältet använder du alternativen Kolumn vy.

Repos

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

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

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

Filtrera kommentarsmeddelanden från pull-begäranden

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

Servicekrokar för pull-begärankommentarer

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

Princip för att blockera filer med angivna mönster

Administratörer kan nu ange en princip för att förhindra att incheckningar skickas till en lagringsplats baserat på filtyper och sökvägar. Valideringsprincipen för filnamn blockerar push-meddelanden som matchar det angivna mönstret.

Lös arbetsuppgifter via commit med hjälp av nyckelord

Du kan nu lösa arbetsobjekt via commits som görs i standardgrenen med hjälp av nyckelord som fix, fixareller fixade. Du kan till exempel skriva - "den här ändringen åtgärdar #476" i din commithälsning, och arbetsuppgiften #476 slutförs när commiten pushas eller slås samman med standardgrenen. Mer information finns i dokumentationen här.

Kornighet för automatiska granskare

Tidigare, när du lade till granskare på gruppnivå i en pull-begäran, krävdes endast ett godkännande från gruppen som lades till. Nu kan du ange principer som kräver att fler än en granskare från ett team godkänner en pull-begäran när du lägger till automatiska granskare. Dessutom kan du lägga till en princip för att förhindra att begäranden godkänner sina egna ändringar.

Använda tjänstkontobaserad autentisering för att ansluta till AKS

Tidigare använde vi en Azure Resource Manager-anslutning när vi konfigurerade Azure Pipelines från AKS Deployment Center. Den här anslutningen hade åtkomst till hela klustret och inte bara det namnområde som pipelinen konfigurerades för. Med den här uppdateringen använder våra pipelines tjänstkontobaserad autentisering för att ansluta till klustret så att de bara har åtkomst till det namnområde som är associerat med pipelinen.

Förhandsgranska Markdown-filer i pull-begäran sida vid sida-diff

Nu kan du se en förhandsgranskning av hur en markdown-fil kommer att se ut med hjälp av den nya knappen Förhandsversion. Dessutom kan du se det fullständiga innehållet i en fil från diffen sida vid sida genom att välja knappen Visa.

Förfallodatum för byggriktlinje för manuella byggen

Policier upprätthåller teamets standarder för kodkvalitet och ändringshantering. Tidigare kunde du ange förfalloprinciper för bygget för automatiserade versioner. Nu kan du även ange utgångspolicyer för dina manuella builds.

Lägga till en princip för att blockera incheckningar baserat på incheckningsförfattarens e-post

Administratörer kan nu ange en push-princip för att förhindra att incheckningar skickas till en lagringsplats där incheckningsförfattarens e-post inte matchar det angivna mönstret.

Den här funktionen prioriterades baserat på ett förslag från Developer Community för att leverera en liknande upplevelse. Vi fortsätter att hålla biljetten öppen och uppmanar användarna att berätta vilka andra typer av push-principer som du vill se.

Markera filer som granskade i en pull-begäran

Ibland behöver du granska pull-begäranden som innehåller ändringar i ett stort antal filer och det kan vara svårt att hålla reda på vilka filer som du redan har granskat. Nu kan du markera filer som granskade i en pull-begäran.

Du kan markera en fil som granskad med hjälp av den nedrullningsbara menyn bredvid ett filnamn eller genom att hovra och klicka på filnamnet.

Notera

Den här funktionen är bara avsedd att spåra förloppet när du granskar en pull-begäran. Den representerar inte röstning på pull requests, därför kommer dessa markeringar endast att synas för granskaren.

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

Nytt webbgränssnitt för Azure Repos-landningssidor

Nu kan du prova våra nya moderna, snabba och mobilvänliga landningssidor i Azure Repos. Dessa sidor är tillgängliga som landningssidor för nya lagringsplatser. Landningssidor inkluderar alla sidor förutom information om pull-begäranden, commit-information och jämförelse av grenar.

Webb

Mobil

Administration av grenspolicy tvärs över förvarsplatser

Grenprinciper är en av de kraftfulla funktionerna i Azure Repos som hjälper dig att skydda viktiga grenar. Även om det finns möjlighet att ange principer på projektnivå i REST-API:et fanns det inget användargränssnitt för det. Nu kan administratörer ange principer för en specifik gren eller standardgrenen på alla lagringsplatser i projektet. En administratör kan till exempel kräva minst två granskare för alla pull-förfrågningar som görs till huvudgrenen i varje repo i deras projekt. Du hittar funktionen Lägg till grenskydd i Lagringsplatsprojektinställningar.

Nya landningssidor för webbplattformskonvertering

Vi har uppdaterat användarupplevelsen för repos-landningssidor så att den blir modern, snabb och mobilvänlig. Här är två exempel på de sidor som har uppdaterats. Vi fortsätter att uppdatera andra sidor i framtida uppdateringar.

Webbupplevelse:

Mobil upplevelse:

Stöd för Kotlin-språk

Vi är glada över att kunna meddela att vi nu stöder Kotlin-språkmarkering i filredigeraren. Markeringen förbättrar läsbarheten för din Kotlin-textfil och hjälper dig att snabbt söka efter fel. Vi har prioriterat den här funktionen baserat på ett förslag från Developer Community.

Anpassad meddelandeprenumeration för pull-begäranden för utkast

För att minska antalet e-postaviseringar från pull-begäranden kan du nu skapa en anpassad meddelandeprenumeration för pull-begäranden som skapas eller uppdateras i utkasttillstånd. Du kan få e-postmeddelanden specifikt för pull-begäranden eller filtrera bort e-postmeddelanden från pull-begäranden så att ditt team inte meddelas innan pull-begäran är redo att granskas.

Förbättrad handlingsbarhet i PR

När du har många pull-begäranden att granska kan det vara svårt att förstå var du bör vidta åtgärder först. För att förbättra åtgärdsbarheten för pull-begäranden kan du nu skapa flera anpassade frågor på sidan med listan över pull-begäranden med flera nya alternativ att filtrera efter, till exempel utkasttillstånd. De här frågorna skapar separata och komprimerbara avsnitt på sidan för pull-begäranden utöver "Skapad av mig" och "Tilldelad till mig". Du kan också avböja att granska en pull request som du har lagts till i via menyn Rösta eller kontextmenyn på sidan med pull requests. I de anpassade avsnitten visas nu separata flikar för pull-begäranden som du har lämnat en granskning om eller avböjt att granska. Dessa anpassade frågor fungerar över lagringsplatser på fliken "Mina pull-begäranden" på samlingens startsida. Om du vill återvända till en pull request kan du markera den, och de kommer att visas högst upp i listan. Slutligen kommer pull requests som har ställts in på automatisk komplettering att markeras med en etikett som säger "Auto-complete" i listan.

Rörledningar

Pipelines i flera steg

Vi har arbetat med en uppdaterad användarupplevelse för att hantera dina pipelines. Dessa uppdateringar gör användarupplevelsen av pipelines modern och i linje med riktningen för Azure DevOps. Dessutom sammanför dessa uppdateringar klassiska byggpipelines och YAML-pipelines i flera steg till en enhetlig upplevelse. Det är mobilvänligt och ger olika förbättringar av hur du hanterar dina pipelines. Du kan öka detaljnivån och visa pipelineinformation, körningsinformation, pipelineanalys, jobbinformation, loggar med mera.

Följande funktioner ingår i den nya upplevelsen:

• visa och hantera flera faser
• godkänna pipeline-körningar
• rulla hela vägen tillbaka i loggar medan en pipeline fortfarande pågår
• hälsostatus för varje gren av en pipeline.

Kontinuerlig distribution i YAML

Vi är glada över att kunna tillhandahålla YAML CD-funktioner för Azure Pipelines. Vi erbjuder nu en enhetlig YAML-upplevelse så att du kan konfigurera var och en av dina pipelines för att göra CI, CD eller CI och CD tillsammans. YAML CD-funktioner introducerar flera nya avancerade funktioner som är tillgängliga för alla samlingar som använder YAML-pipelines i flera steg. Några av höjdpunkterna är:

• YAML-pipelines i flera steg (för CI och CD)
• godkännanden och kontroller av resurser
• Miljöer och distributionsstrategier
• Kubernetes- och Virtuell Maskin resurser i miljön
• Granska appar för samarbete
• Uppdaterat UX för tjänstanslutningar
• Resurser i YAML-pipelines

Om du är redo att börja bygga, kolla in -dokumentationen eller -bloggen för att bygga CI/CD-pipelines i flera steg.

Hantera pipelinevariabler i YAML-redigeraren

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

Godkänna versioner direkt från releasehubben

Det har blivit enklare att hantera väntande godkännanden. Tidigare var det möjligt att godkänna en version från informationssidan för versionen. Nu kan du godkänna versioner direkt från releasehubben.

Förbättringar med att komma igång med pipelines

En vanlig förfrågan med komma igång-guiden har varit möjligheten att byta namn på den genererade filen. För närvarande checkas den in som azure-pipelines.yml i lagringsplatsens rot. Du kan nu uppdatera detta till ett annat filnamn eller en annan plats innan du sparar pipelinen.

Slutligen kommer vi och du att ha mer kontroll när du checkar in azure-pipelines.yml-filen till en annan gren, eftersom du kan välja att hoppa över att skapa en pull request från den grenen.

Förhandsgranska fullständigt tolkat YAML-dokument utan att committera eller köra pipelinan

Vi har lagt till en förhandsversion men kör inte läge för YAML-pipelines. Nu kan du prova en YAML-pipeline utan att checka in den på en lagringsplats eller köra den. Med tanke på en befintlig pipeline och en valfri ny YAML-nyttolast kommer det nya API:et att ge dig tillbaka den fullständiga YAML-pipelinen. I framtida uppdateringar används det här API:et i en ny redigeringsfunktion.

För utvecklare: POST till dev.azure.com/<org>/<project>/_apis/pipelines/<pipelineId>/runs?api-version=5.1-preview med ett JSON-innehåll enligt följande:

{
  "PreviewRun": true,
  "YamlOverride": "
# your new YAML here, optionally
"
}

Svaret innehåller den renderade YAML-filen.

Cron-scheman i YAML

Tidigare kunde du använda användargränssnittsredigeraren för att ange en schemalagd utlösare för YAML-pipelines. Med den här versionen kan du schemalägga versioner med cron-syntax i YAML-filen och dra nytta av följande fördelar:

1. Konfiguration som kod: Du kan spåra scheman tillsammans med din pipeline som en del av koden.
2. Uttrycksfull: Du har mer uttrycksfull kraft när det gäller att definiera scheman än vad du kunde med användargränssnittet. Det är till exempel enklare att ange ett enda schema som startar en körning varje timme.
3. Branschstandard: Många utvecklare och administratörer är redan bekanta med cron-syntaxen.

schedules:
- cron: "0 0 * * *"
 displayName: Daily midnight build
 branches:
  include:
  - main
  - releases/*
  exclude:
  - releases/ancient/*
 always: true

Vi har också gjort det enkelt för dig att diagnostisera problem med cron-scheman. Schemalagda körningar på menyn Kör pipeline ger dig en förhandsversion av de kommande schemalagda körningarna för din pipeline som hjälper dig att diagnostisera fel med dina cron-scheman.

Uppdateringar av användargränssnittet för tjänstanslutningar

Vi har arbetat med en uppdaterad användarupplevelse för att hantera dina tjänstanslutningar. De här uppdateringarna gör tjänstanslutningen modern och konsekvent med riktningen för Azure DevOps. Vi introducerade det nya användargränssnittet för tjänstanslutningar som en förhandsversionsfunktion tidigare i år. Tack till alla som provat den nya upplevelsen och gett sin värdefulla feedback till oss.

Tillsammans med uppdatering av användarupplevelsen har vi även lagt till två funktioner som är viktiga för att använda tjänstanslutningar i YAML-pipelines: pipelineauktoriseringar och godkännanden och kontroller.

Den nya användarupplevelsen aktiveras som standard med den här uppdateringen. Du har fortfarande möjlighet att välja bort förhandsversionen.

Not

Vi planerar att introducera delning av tjänstanslutningar mellan projekt som en ny funktion. Du hittar mer information om delningsupplevelsen och säkerhetsrollerna här.

Hoppa över faser i en YAML-pipeline

När du startar en manuell körning kan du ibland vilja hoppa över vissa steg i pipelinen. Om du till exempel inte vill distribuera till produktion eller om du vill hoppa över distributionen till några miljöer i produktion. Nu kan du göra detta med dina YAML-pipelines.

Den uppdaterade körningspipelinepanelen visar en lista över etapper från YAML-filen, och du har möjlighet att hoppa över en eller flera av dessa etapper. Du måste vara försiktig när du hoppar över faser. Om din första fas till exempel genererar vissa artefakter som behövs för efterföljande steg bör du inte hoppa över den första fasen. Körningspanelen visar en allmän varning när du hoppar över steg som har underordnade beroenden. Det är upp till dig om dessa beroenden är sanna artefaktberoenden eller om de bara finns för sekvensering av distributioner.

Att hoppa över en fas motsvarar att ändra beroendena mellan faserna. Eventuella direkta efterkommande beroenden av den överhoppade fasen görs beroende av den överordnade föräldern till den överhoppade fasen. Om körningen misslyckas och om du försöker köra en misslyckad fas igen kommer det försöket också att ha samma överhoppningsbeteende. Om du vill ändra vilka steg som hoppar över måste du starta en ny genomgång.

Tjänstanslutningars nya användargränssnitt blir standardupplevelsen

Det finns ett nytt användargränssnitt för tjänstanslutningar. Det här nya användargränssnittet bygger på moderna designstandarder och har olika viktiga funktioner för att stödja YAML CD-pipelines i flera steg, till exempel godkännanden, auktoriseringar och delning mellan projekt.

Läs mer om tjänstanslutningar här.

Pipeline-resursversionsväljare i dialogrutan för att skapa körning

Vi har lagt till möjligheten att manuellt hämta pipelineresursversioner i dialogrutan skapa körning. Om du använder en pipeline som en resurs i en annan pipeline kan du nu välja den version av pipelinen när du skapar en körning.

az CLI-förbättringar för Azure Pipelines

Kommandon för pipelinevariabelgrupper och variabelhantering

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

Kör pipeline för en PR-gren

När du skapar en PR kan det vara svårt att kontrollera om ändringarna kan bryta pipelinekörningen på målgrenen. Men med möjligheten att utlösa en pipelinekörning eller köa en bygge för en PR-gren kan du nu validera och visualisera de ändringar som går in genom att köra den mot målpipelinen. För mer information, se dokumentationen för kommandona az pipelines run och az pipelines build queue.

Hoppa över den första pipelinekörningen

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

Kommandoförbättring för tjänstslutpunkt

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

Distributionsjobb

Ett distributionsjobb är en särskild typ av jobb som används för att distribuera din app till en miljö. Med den här uppdateringen har vi lagt till stöd för stegreferenser i ett distributionsjobb. Du kan till exempel definiera en uppsättning steg i en fil och referera till den i ett distributionsjobb.

Vi har också lagt till stöd för ytterligare egenskaper i distributionsjobbet. Här är till exempel några egenskaper för ett distributionsjobb som du nu kan ange,

• timeoutInMinutes – hur lång tid jobbet ska köras innan det avbryts automatiskt
• cancelTimeoutInMinutes – hur mycket tid som ges "uppgifter som körs alltid även om de avbryts" innan de avslutas
• villkor – kör uppgiften villkorligt
• variabler – Hårdkodade värden kan läggas till direkt eller variabelgrupper, variabelgrupp som backas upp av ett Azure-nyckelvalv kan refereras till eller så kan du referera till en uppsättning variabler som definierats i en fil.
• continueOnError – om framtida jobb ska köras även om distributionsjobbet misslyckas; standardvärdet är 'false'

Mer information om distributionsjobb och den fullständiga syntaxen för att ange ett distributionsjobb finns i Distributionsjobb.

Visar information om tillhörande CD-pipelines i CI-pipelines

Vi har lagt till stöd för detaljer i CD YAML-pipelines där CI-pipelines kallas pipelinresurser. I CI-pipelinekörningsvyn visas nu den nya fliken 'Associerade pipelines' där du hittar alla pipelinekörningar som använder din pipeline och dess artefakter.

Stöd för GitHub-paket i YAML-pipelines

Vi har nyligen introducerat en ny resurstyp med namnet paket som lägger till stöd för att använda NuGet och npm paket från GitHub som en resurs i YAML-pipelines. Som en del av den här resursen kan du nu ange den pakettyp (NuGet eller npm) som du vill använda från GitHub. Du kan också aktivera automatiserade pipelineutlösare när en ny paketversion släpps. Idag är stödet endast tillgängligt för användning av paket från GitHub, men framöver planerar vi att utöka stödet för att använda paket från andra paketlagringsplatser, till exempel NuGet, npm, AzureArtifacts och många fler. Mer information finns i exemplet nedan:

resources:
  packages:
    - package: myPackageAlias # alias for the package resource
      type: Npm # type of the package NuGet/npm
      connection: GitHubConn # Github service connection of type PAT
      name: nugetTest/nodeapp # <Repository>/<Name of the package>
      version: 1.0.9 # Version of the packge to consume; Optional; Defaults to latest
      trigger: true # To enable automated triggers (true/false); Optional; Defaults to no triggers

Not

Idag stöder GitHub-paket endast PAT-baserad autentisering, vilket innebär att GitHub-tjänstanslutningen i paketresursen ska vara av typen PAT. När den här begränsningen har hävts ger vi stöd för andra typer av autentisering.

Som standard laddas paket inte ned automatiskt i dina jobb, därför har vi introducerat ett getPackage- makro som gör att du kan använda paketet som definieras i resursen. Mer information finns i exemplet nedan:

- job: job1
  pool: default
  steps:
    - getPackage: myPackageAlias # Alias of the package resource

Azure Kubernetes Service Cluster-länk i Kubernetes-miljöresursvyn

Vi har lagt till en länk till resursvyn för Kubernetes-miljöer så att du kan navigera till Azure-bladet för motsvarande kluster. Detta gäller för miljöer som är mappade till namnområden i Azure Kubernetes Service-kluster.

Filtret för utgivningsmappen i meddelandeprenumerationer

Mappar gör det möjligt att organisera pipelines för enklare identifiering och säkerhetskontroll. Ofta kanske du vill konfigurera anpassade e-postaviseringar för alla versionspipelines som representeras av alla pipelines under en mapp. Tidigare var du tvungen att konfigurera flera prenumerationer eller ha komplexa frågor i prenumerationerna för att få fokuserade e-postmeddelanden. Med den här uppdateringen kan du nu lägga till en klausul för versionsmapp till händelserna distribution slutförd och godkännande väntar och förenkla prenumerationerna.

Länka arbetsobjekt med YAML-pipelines i flera steg

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

Avbryt fasen i en YAML-pipelinekörning i flera steg

När du kör en YAML-pipeline i flera steg kan du avbryta körningen av en fas medan den pågår. Det här är användbart om du vet att steget kommer att misslyckas eller om du har en annan process som du vill starta.

Upprepa misslyckade steg

En av de mest efterfrågade funktionerna i flerstegspipelines är möjligheten att försöka igen ett misslyckat steg utan att behöva starta från början. Med den här uppdateringen lägger vi till en stor del av den här funktionen.

Nu kan du pröva köra om en pipeline-etapp när körningen misslyckas. Alla jobb som misslyckades i det första försöket och de som är transitivt beroende av de misslyckade jobben görs på nytt.

Detta kan hjälpa dig att spara tid på flera sätt. När du till exempel kör flera jobb i en fas kanske du vill att varje steg ska köra tester på en annan plattform. Om testerna på en plattform misslyckas medan de andra klarar sig kan du spara tid genom att inte köra om jobben som redan har klarat sig. Ett annat exempel är att en distributionsfas kan ha misslyckats på grund av en fläckig nätverksanslutning. Om du försöker utföra den fasen igen kan du spara tid genom att inte behöva skapa en ny version.

Det finns några kända luckor i den här funktionen. Du kan till exempel inte försöka igen i ett steg som du uttryckligen avbryter. Vi arbetar för att överbrygga dessa luckor i framtida uppdateringar.

Godkännanden i flerstegs-YAML-pipelines

Dina YAML CD-pipelines kan innehålla manuella godkännanden. Infrastrukturägare kan skydda sina miljöer och söka manuella godkännanden innan en fas i en pipeline distribueras till dem. Med fullständig uppdelning av roller mellan ägare av infrastruktur (miljö) och program (pipeline) säkerställer du manuell inloggning för distribution i en viss pipeline och får central kontroll när du tillämpar samma kontroller i alla distributioner i miljön.

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

Ökning av tidsgräns och frekvens för portar

Tidigare var tidsgränsen för gaten i utgivningspipelines tre dagar. Med den här uppdateringen har tidsgränsen ökats till 15 dagar för att tillåta grindar med längre varaktighet. Vi ökade också frekvensen för grinden till 30 minuter.

Mall för ny byggbild för Dockerfile

Tidigare, när du skapade en ny pipeline för en Dockerfile, rekommenderade mallen att pusha avbildningen till ett Azure Container Registry och deploya till en Azure Kubernetes Service. Vi har lagt till en ny mall så att du kan skapa en bild med hjälp av agenten utan att behöva överföra den till ett containerregister.

Ny uppgift för att konfigurera appinställningar för Azure App Service

Azure App Service tillåter konfiguration via olika inställningar som appinställningar, anslutningssträngar och andra allmänna konfigurationsinställningar. Nu har vi en ny Azure Pipelines-uppgift Azure App Service-inställningar som har stöd för att konfigurera dessa inställningar i grupp med JSON-syntax i webbappen eller någon av dess distributionsplatser. Den här uppgiften kan användas tillsammans med andra App Service-uppgifter för att distribuera, hantera och konfigurera dina webbappar, funktionsappar eller andra containerbaserade App Services.

Azure App Service har nu stöd för växling med förhandsversion

Azure App Service stöder nu växling med förhandsversion på distributionsplatserna. Det här är ett bra sätt att verifiera appen med produktionskonfiguration innan appen faktiskt växlas från en mellanlagringsplats till produktionsplatsen. Detta skulle också säkerställa att mål-/produktionsplatsen inte upplever driftstopp.

Azure App Service-uppgiften stöder nu den här växlingen i flera faser genom följande nya åtgärder:

• Starta växling med förhandsgranskning – Initierar en växling med en förhandsgranskning (växling med flera faser) och tillämpar målplatsens konfiguration (som till exempel produktionsplatsen) på källplatsen.
• Slutför växling med förhandsversion – När du är redo att slutföra den väntande växlingen väljer du åtgärden Slutför växling med förhandsversion.
• Avbryt växling med förhandsversion – Om du vill avbryta ett väntande byte väljer du Avbryt växling med förhandsversion.

Filter på stegnivå för Azure Container Registry och Docker Hub-artefakter

Tidigare var filter för reguljära uttryck för Azure Container Registry och Docker Hub-artefakter endast tillgängliga på versionspipelinenivå. De har nu också lagts till på scennivå.

Förbättringar av godkännanden i YAML-pipelines

Vi har aktiverat konfiguration av godkännanden för tjänstanslutningar och agentpooler. För godkännanden följer vi uppdelningen av roller mellan infrastrukturägare och utvecklare. Genom att konfigurera godkännanden för dina resurser, till exempel miljöer, tjänstanslutningar och agentpooler, kommer du att vara säker på att alla pipelinekörningar som använder resurser måste godkännas först.

Upplevelsen liknar att konfigurera godkännanden för miljöer. När ett godkännande väntar på en resurs som refereras i en fas väntar körningen av pipelinen tills pipelinen har godkänts manuellt.

Stöd för testning av containerstruktur i Azure Pipelines

Användningen av containrar i program ökar och därmed behovet av robust testning och validering. Azure Pipelines har nu stöd för containerstrukturtester. Det här ramverket är ett bekvämt och kraftfullt sätt att verifiera innehållet och strukturen i dina containrar.

Du kan verifiera strukturen för en bild baserat på fyra kategorier av tester som kan köras tillsammans: kommandotester, filexistenstester, filinnehållstester och metadatatester. Du kan använda resultatet i pipelinen för att fatta go/no go-beslut. Testdata finns tillgänglig i pipeline-körningen med ett felmeddelande som hjälper dig att bättre felsöka problem.

Ange konfigurationsfilen och bildinformationen

Testdata och sammanfattning

Pipelinedekoratörer för utgivningspipelines

Med pipelinedekoratörer kan du lägga till steg i början och slutet av varje jobb. Det här skiljer sig från att lägga till steg i en enskild definition eftersom det gäller för alla pipelines i en samling.

Vi har stöttat dekoratörer för byggen och YAML-pipelines, där kunder använder dem för att centralt kontrollera stegen i sina arbetsflöden. Vi utökar nu även stödet till releasepipelines. Du kan skapa tillägg för att lägga till steg som riktar sig till den nya bidragspunkten och de läggs till i alla agentjobb i versionspipelines.

Distribuera Azure Resource Manager (ARM) till prenumerations- och hanteringsgruppsnivå

Tidigare hade vi endast stöd för distributioner på resursgruppsnivå. Med den här uppdateringen har vi lagt till stöd för att distribuera ARM-mallar till både prenumerations- och hanteringsgruppens nivåer. Detta hjälper dig när du distribuerar en uppsättning resurser tillsammans men placerar dem i olika resursgrupper eller prenumerationer. Du kan till exempel distribuera den virtuella säkerhetskopieringsdatorn för Azure Site Recovery till en separat resursgrupp och plats.

CD-funktioner för YAML-pipeline i flera steg

Nu kan du använda artefakter som publicerats av dina CI-pipelines och aktivera avslutningstriggers för pipelines. I flerstegs-YAML-pipelines introducerar vi pipelines som en resurs. I YAML kan du nu referera till en annan pipeline och även aktivera CD-utlösare.

Här är det detaljerade YAML-schemat för pipelineresurser.

resources: 
  pipelines:
  - pipeline: MyAppCI  # identifier for the pipeline resource
    project:  DevOpsProject # project for the build pipeline; optional input for current project
    source: MyCIPipeline  # source pipeline definition name
    branch: releases/M159  # branch to pick the artifact, optional; defaults to all branches
    version: 20190718.2 # pipeline run number to pick artifact; optional; defaults to last successfully completed run
    trigger:     # Optional; Triggers are not enabled by default.
      branches:  
        include:  # branches to consider the trigger events, optional; defaults to all branches.
        - main
        - releases/*
        exclude:   # branches to discard the trigger events, optional; defaults to none.
        - users/*  

Dessutom kan du ladda ned de artefakter som publicerats av pipelineresursen med hjälp av uppgiften - download.

steps: 
- download: MyAppCI  # pipeline resource identifier
    artifact:  A1 # name of the artifact to download; optional; defaults to all artifacts

Mer information finns i dokumentationen om nedladdning av artefakter här.

Orkestrera kanariedistributionsstrategi på Kubernetes-miljön

En av de viktigaste fördelarna med kontinuerlig leverans av programuppdateringar är möjligheten att snabbt skicka uppdateringar till produktion för specifika mikrotjänster. Detta ger dig möjlighet att snabbt svara på ändringar i affärskraven. Environment introducerades som ett förstklassigt koncept som möjliggör orkestrering av distributionsstrategier och underlättar noll stilleståndstid. Tidigare stödde vi runOnce strategi som utförde stegen en gång sekventiellt. Med stöd för kanariestrategi i pipelines i flera steg kan du nu minska risken genom att långsamt distribuera ändringen till en liten delmängd. När du får mer förtroende för den nya versionen kan du börja distribuera den till fler servrar i infrastrukturen och dirigera fler användare till den.

jobs:
- deployment:
  environment: musicCarnivalProd
  pool:
    name: musicCarnivalProdPool 
  strategy:                 
    canary:     
      increments: [10,20] 
      preDeploy:                                    
        steps:          
        - script: initialize, cleanup....  
      deploy:            
        steps:
        - script: echo deploy updates...
        - task: KubernetesManifest@0
          inputs:
            action: $(strategy.action)      
            namespace: 'default'
            strategy: $(strategy.name)
            percentage: $(strategy.increment)
            manifests: 'manifest.yml'
      postRouteTaffic:
        pool: server
        steps:          
        - script: echo monitor application health...  
      on:
        failure:
          steps:
	  - script: echo clean-up, rollback...  
        success:
          steps:
          - script: echo checks passed, notify...

Kanariestrategin för Kubernetes distribuerar först ändringarna med 10% poddar, följt av 20%, medan man övervakar hälsotillståndet under postRouteTraffic. Om allt går bra, kommer det att uppgraderas till 100%.

Vi letar efter tidig feedback om stöd för VM-resurser i miljöer och utför en rullande distributionsstrategi på flera datorer. Kontakta oss för att registrera dig.

Godkännandeprinciper för YAML-pipelines

I YAML-pipelines följer vi en konfiguration för resursägarkontrollerat godkännande. Resursägare konfigurerar godkännanden för resursen, och alla pipelines som använder resursen pausas för godkännande innan steget som konsumerar resursen börjar. Det är vanligt att SOX-baserade programägare begränsar beställaren av distributionen från att godkänna sina egna distributioner.

Du kan nu använda avancerade godkännandealternativ för att konfigurera godkännandeprinciper som att beställaren inte bör godkänna, kräva godkännande från en delmängd av användare och tidsgräns för godkännande.

ACR som en förstklassig pipelineresurs

Om du behöver använda en containeravbildning som publicerats till ACR (Azure Container Registry) som en del av pipelinen och utlösa pipelinen när en ny avbildning publiceras kan du använda ACR-containerresursen.

resources:
  containers:
  - container: MyACR  #container resource alias
    type: ACR
    azureSubscription: RMPM  #ARM service connection
    resourceGroup: contosoRG
    registry: contosodemo
    repository: alphaworkz
    trigger: 
      tags:
        include: 
        - production 

Dessutom kan ACR-bildmetadata nås med hjälp av fördefinierade variabler. Följande lista innehåller de ACR-variabler som är tillgängliga för att definiera en ACR-containerresurs i din pipeline.

resources.container.<Alias>.type
resources.container.<Alias>.registry
resources.container.<Alias>.repository
resources.container.<Alias>.tag 
resources.container.<Alias>.digest
resources.container.<Alias>.URI
resources.container.<Alias>.location

Förbättringar för att utvärdera regelverk för kontroll av artefakter i pipelineprocesser

Vi har förbättrat utvärdera artefaktkontrollen för att göra det enklare att lägga till principer från en lista med färdiga principdefinitioner. Principdefinitionen genereras automatiskt och läggs till i checkkonfiguration, som kan uppdateras vid behov.

Stöd för utdatavariabler i ett distributionsjobb

Nu kan du definiera utdatavariabler i ett distributionsjobbs livscykelkrokar och använda dem i andra underordnade steg och jobb i samma fas.

När du kör distributionsstrategier kan du komma åt utdatavariabler mellan jobb med hjälp av följande syntax.

• För runOnce strategi: $[dependencies.<job-name>.outputs['<lifecycle-hookname>.<step-name>.<variable-name>']]
• För kanarie- strategi: $[dependencies.<job-name>.outputs['<lifecycle-hookname>_<increment-value>.<step-name>.<variable-name>']]
• För rullande strategi: $[dependencies.<job-name>.outputs['<lifecycle-hookname>_<resource-name>.<step-name>.<variable-name>']]

// Set an output variable in a lifecycle hook of a deployment job executing canary strategy
- deployment: A
  pool:
    vmImage: 'ubuntu-16.04'
  environment: staging
  strategy:                  
    canary:      
      increments: [10,20]  # creates multiple jobs, one for each increment. Output variable can be referenced with this.
      deploy:
        steps:
        - script: echo "##vso[task.setvariable variable=myOutputVar;isOutput=true]this is the deployment variable value"
          name: setvarStep
        - script: echo $(setvarStep.myOutputVar)
          name: echovar

 // Map the variable from the job
- job: B
  dependsOn: A
  pool:
    vmImage: 'ubuntu-16.04'
  variables:
    myVarFromDeploymentJob: $[ dependencies.A.outputs['deploy_10.setvarStep.myOutputVar'] ]
  steps:
  - script: "echo $(myVarFromDeploymentJob)"
    name: echovar

Läs mer om hur du ange en utdatavariabel för flera jobb

Undvik återställning av kritiska ändringar

I klassiska versionspipelines är det vanligt att förlita sig på schemalagda distributioner för regelbundna uppdateringar. Men när du har en kritisk korrigering kan du välja att starta en manuell distribution utanför det vanliga flödet. När du gör det fortsätter äldre versioner att vara schemalagda. Detta innebar en utmaning eftersom den manuella distributionen skulle återställas när distributionerna återupptogs enligt schemat. Många av er rapporterade det här problemet och vi har nu åtgärdat det. Med korrigeringen avbryts alla äldre schemalagda distributioner till miljön när du startar en distribution manuellt. Detta gäller endast när köalternativet har valts som "Distribuera senaste och avbryt andra".

Förenklad resursauktorisering i YAML-pipelines

En resurs är allt som används av en pipeline och som finns utanför pipelinen. Resurser måste auktoriseras innan de kan användas. Tidigare, när du använder obehöriga resurser i en YAML-pipeline, misslyckades den med ett resursauktoriseringsfel. Du var tvungen att auktorisera resurserna från sammanfattningssidan för det misslyckade utförandet. Dessutom misslyckades pipelinen om den använde en variabel som refererade till en obehörig resurs.

Nu gör vi det enklare att hantera resursauktoriseringar. I stället för att misslyckas med körningen väntar körningen på behörigheter för resurserna i början av fasen som förbrukar resursen. En resursägare kan visa pipelinen och auktorisera resursen från sidan Säkerhet.

Utvärdera artefaktkontroll

Nu kan du definiera en uppsättning principer och lägga till principutvärderingen som en kontrollpunkt för en miljö med containerbildsartefakter. När en pipeline körs pausas exekveringen innan ett steg som använder miljön startas. Den angivna principen utvärderas mot tillgängliga metadata för avbildningen som distribueras. Kontrollen godkänns när policyn är framgångsrik och markerar fasen som misslyckad om kontrollen misslyckas.

Uppdateringar av distribueringsuppgiften för ARM-mallen

Tidigare filtrerade vi inte tjänstanslutningarna i ARM-malldistributionsuppgiften. Detta kan leda till att distributionen misslyckas om du väljer en tjänstanslutning med lägre omfång för att utföra ARM-malldistributioner till ett bredare omfång. Nu har vi lagt till filtrering av tjänstanslutningar för att filtrera bort tjänstanslutningar med lägre omfattning baserat på det distributionsomfång du väljer.

ReviewApp i miljön

ReviewApp distribuerar varje pull-begäran från din Git-lagringsplats till en dynamisk miljöresurs. Granskare kan se hur dessa ändringar ser ut och fungerar med andra beroende tjänster innan de sammanfogas till huvudgrenen och distribueras till produktion. Detta gör det enkelt för dig att skapa och hantera granskningsApp resurser och dra nytta av alla spårnings- och diagnosmöjligheter hos miljöfunktionerna. Genom att använda nyckelordet reviewApp kan du skapa en klon av en resurs (dynamiskt skapa en ny resurs baserat på en befintlig resurs i en miljö) och lägga till den nya resursen i miljön.

Följande är ett YAML-exempelfragment med att använda reviewApp under miljöer.

jobs:
- deployment:
  environment: 
     name: smarthotel-dev      
     resourceName: $(System.PullRequest.PullRequestId) 
  pool:
    name: 'ubuntu-latest'
  strategy:                 
    runOnce:            
      pre-deploy: 
        steps:       
        - reviewApp: MainNamespace

Samla in automatiska och användardefinierade metadata från pipeline

Nu kan du aktivera automatisk och användardefinierad metadatainsamling från pipelineuppgifter. Du kan använda metadata för att framtvinga artefaktprincip i en miljö med hjälp av utvärdera artefaktkontrollen.

VM-distributioner i miljöer

En av de mest efterfrågade funktionerna i Miljöer var VM-distributioner. Med den här uppdateringen aktiverar vi virtuella datorresurser i miljöer. Nu kan du samordna distributioner över flera maskiner och utföra rullande uppdateringar med YAML-pipelines. Du kan också installera agenten på var och en av dina målservrar direkt och driva rullande distribution till dessa servrar. Dessutom kan du använda hela uppgiftskatalogen på dina måldatorer.

En löpande distribution ersätter instanser av den tidigare versionen av ett program med instanser av den nya versionen av programmet på en uppsättning datorer (rullande uppsättningar) i varje iteration.

Vid löpande distribution uppdateras till exempel upp till fem målobjekt i varje iteration. maxParallel avgör antalet mål som kan distribueras parallellt. Valet står för det antal mål som måste vara tillgängliga när som helst, exklusive de mål som distribueras till. Den används också för att fastställa framgångs- och misslyckandeförhållanden under distributionen.

jobs:
- deployment:
  displayName: web
  environment:
    name: musicCarnivalProd
    resourceType: VirtualMachine
  strategy:                 
    rolling:
      maxParallel: 5 #for percentages, mention as x%
      preDeploy:
        steps:
        - script: echo initialize, cleanup, backup, install certs...
      deploy:              
        steps:                                     
        - script: echo deploy ...      
      routeTraffic:
        steps:
        - script: echo routing traffic...   
      postRouteTaffic:
        steps:          
        - script: echo health check post routing traffic...  
      on:
        failure:
          steps:
          - script: echo restore from backup ..     
        success:
          steps:
          - script: echo notify passed...

Notera

Med den här uppdateringen hämtas alla tillgängliga artefakter från den aktuella pipelinen och från de associerade pipelineresurserna endast i deploy livscykel-hook. Du kan dock välja att ladda ned genom att ange Ladda ned pipelineartefaktaktiviteten. Det finns några kända luckor i den här funktionen. När du till exempel försöker köra en etapp igen, körs distributionen på alla virtuella maskiner, inte bara misslyckade instanser. Vi arbetar för att överbrygga dessa luckor i framtida uppdateringar.

Ytterligare kontroll över dina distributioner

Azure Pipelines har stöd för distributioner som styrs med manuella godkännanden under en tid nu. Med de senaste förbättringarna har du nu ytterligare kontroll över dina distributioner. Förutom godkännanden kan resursägare nu lägga till automatiserade checks för att verifiera säkerhets- och kvalitetsprinciper. Dessa kontroller kan användas för att utlösa åtgärder och sedan vänta tills de har slutförts. Med hjälp av de ytterligare kontrollerna kan du nu definiera hälsokriterier baserat på flera källor och vara säker på att alla distributioner som riktar sig till dina resurser är säkra, oavsett vilken YAML-pipeline som utför distributionen. Utvärdering av varje kontroll kan upprepas regelbundet baserat på den angivna återförsöksintervall för kontrollen. Följande ytterligare kontroller är nu tillgängliga:

• Anropa REST-API:er och utför validering baserat på svarsdata eller ett återanrop från den externa tjänsten
• Anropa en Azure-funktion och utföra validering baserat på svar eller återanrop från funktionen
• Sök Azure Monitor-regler för aktiva larm
• Se till att pipelinen utökar en eller flera YAML-mallar

Godkännandemeddelande

När du lägger till ett godkännande i en miljö eller en tjänstanslutning väntar alla flerstegspipelines som använder resursen automatiskt på godkännandet i början av steget. De utsedda godkännarna måste slutföra godkännandet innan pipelinen kan fortsätta.

Med den här uppdateringen skickas godkännarna ett e-postmeddelande för det väntande godkännandet. Användare och teamägare kan välja bort eller konfigurera anpassade prenumerationer med hjälp av meddelandeinställningar.

Konfigurera distributionsstrategier från Azure-portalen

Med den här funktionen har vi gjort det enklare för dig att konfigurera pipelines som använder valfri distributionsstrategi, till exempel Rullande, Canaryeller Blågrön. Med hjälp av dessa färdiga strategier kan du distribuera uppdateringar på ett säkert sätt och minimera associerade distributionsrisker. Om du vill komma åt detta klickar du på inställningen "Kontinuerlig leverans" på en virtuell Azure-dator. I konfigurationsfönstret uppmanas du att välja information om Azure DevOps-projektet där pipelinen ska skapas, distributionsgruppen, bygg-pipelinen som publicerar paketet som ska distribueras och vilken distributionsstrategi du väljer. I framtiden konfigureras en fullt fungerande pipeline som distribuerar det valda paketet till den virtuella datorn.

Mer information finns i vår dokumentation om konfigurering av distributionsstrategier.

Körningsparametrar

Med körningsparametrar kan du få mer kontroll över vilka värden som kan skickas till en pipeline. Till skillnad från variabler har körningsparametrar datatyper och blir inte automatiskt miljövariabler. Med körningsparametrar kan du:

• Ange olika värden för skript och uppgifter vid körning
• Kontrollera parametertyper, tillåtna intervall och standardvärden
• Välj jobb och steg dynamiskt med malluttryck

Mer information om körningsparametrar finns i dokumentationen här.

Använd extends-nyckelord i pipelines

Just nu kan pipelines brytas ut i mallar, vilket främjar återanvändning och minskar standardkod. Den övergripande strukturen för pipelinen definierades fortfarande av YAML-rotfilen. Med den här uppdateringen har vi lagt till ett mer strukturerat sätt att använda pipelinemallar. En YAML-rotfil kan nu använda nyckelordet utökar för att indikera att huvudstrukturen för pipelinen finns i en annan fil. Detta ger dig kontroll över vilka segment som kan utökas eller ändras och vilka segment som är fasta. Vi har också förbättrat pipelineparametrarna med datatyper för att tydliggöra de anpassningspunkter som du kan tillhandahålla.

Det här exemplet illustrerar hur du kan tillhandahålla enkla krokar som författaren av pipelinen kan använda. Mallen kör alltid en version, kör eventuellt ytterligare steg som tillhandahålls av pipelinen och kör sedan ett valfritt teststeg.

# azure-pipelines.yml
extends:
  template: build-template.yml
  parameters:
    runTests: true
    postBuildSteps:
    - script: echo This step runs after the build!
    - script: echo This step does too!

# build-template.yml
parameters:
- name: runTests
  type: boolean
  default: false
- name: postBuildSteps
  type: stepList
  default: []
steps:
- task: MSBuild@1   # this task always runs
- ${{ if eq(parameters.runTests, true) }}:
  - task: VSTest@2  # this task is injected only when runTests is true
- ${{ each step in parameters.postBuildSteps }}:
  - ${{ step }}

Kontrollera variabler som kan åsidosättas vid kötid

Tidigare kunde du använda användargränssnittet eller REST-API:et för att uppdatera värdena för en variabel innan du startar en ny körning. Pipelinens författare kan markera vissa variabler som _settable at queue time_, men systemet framtvingade inte detta och förhindrade inte heller att andra variabler angavs. Med andra ord användes inställningen bara för att fråga efter ytterligare indata när en ny körning startades.

Vi har lagt till en ny samlingsinställning som framtvingar parametern _settable at queue time_. Detta ger dig kontroll över vilka variabler som kan ändras när du startar en ny körning. Framöver kan du inte ändra en variabel som inte markeras av författaren som _settable at queue time_.

Not

Den här inställningen är inaktiverad som standard i befintliga samlingar, men den är aktiverad som standard när du skapar en ny Azure DevOps-samling.

Nya fördefinierade variabler i YAML-pipeline

Med variabler kan du enkelt hämta viktiga databitar till olika delar av pipelinen. Med den här uppdateringen har vi lagt till några fördefinierade variabler i ett distributionsjobb. Dessa variabler anges automatiskt av systemet, begränsade till det specifika distributionsjobbet och är skrivskyddade.

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

Checka ut flera lagringsplatser

Pipelines förlitar sig ofta på flera lagringsplatser. Du kan ha olika lagringsplatser med källa, verktyg, skript eller andra objekt som du behöver för att skapa din kod. Tidigare var du tvungen att lägga till dessa lagringsplatser som undermoduler eller som manuella skript för att köra git-utcheckning. Nu kan du hämta och checka ut andra lagringsplatser, utöver den som du använder för att lagra DIN YAML-pipeline.

Om du till exempel har en lagringsplats med namnet MyCode- med en YAML-pipeline och en andra lagringsplats med namnet Toolsser YAML-pipelinen ut så här:

resources:
  repositories:
  - repository: tools
    name: Tools
    type: git

steps:
- checkout: self
- checkout: tools
- script: dir $(Build.SourcesDirectory)

Det tredje steget visar två kataloger, MyCode och Tools i källkatalogen.

Azure Repos Git-lagringsplatser stöds. Mer information finns i multi-repo-utcheckning.

Få information vid körning om flera lagringsplatser

När en pipeline körs lägger Azure Pipelines till information om lagringsplatsen, grenen och commit som startade körningen. Nu när YAML-pipelines har stöd för att checka ut flera repositories kanske du också vill veta vilka repo, branch och commit som har checkats ut för andra repositories. Denna data är tillgänglig via ett körningsuttryck, som du nu kan koppla till en variabel. Till exempel:

resources:
  repositories:
  - repository: other
    type: git
    name: MyProject/OtherTools

variables:
  tools.ref: $[ resources.repositories['other'].ref ]

steps:
- checkout: self
- checkout: other
- bash: echo "Tools version: $TOOLS_REF"

Tillåt databasreferenser till andra Azure Repos-samlingar

Tidigare, när du refererade till lagringsplatser i en YAML-pipeline, var alla Azure Repos-lagringsplatser tvungna att finnas i samma samling som pipelinen. Nu kan du peka på lagringsplatser i andra samlingar med hjälp av en tjänstanslutning. Till exempel:

resources:
  repositories:
  - repository: otherrepo
    name: ProjectName/RepoName
    endpoint: MyServiceConnection
steps:
- checkout: self
- checkout: otherrepo

MyServiceConnection pekar på en annan Azure DevOps-samling och har autentiseringsuppgifter som kan komma åt lagringsplatsen i ett annat projekt. Båda lagringsplatserna, self och otherrepo, checkas ut.

Viktig

MyServiceConnection måste vara en Azure Repos/Team Foundation Server-tjänstanslutning, se bilden nedan.

Meta-data för pipelineresurser som fördefinierade variabler

Vi har lagt till fördefinierade variabler för YAML-pipelineresurser i pipelinen. Här är listan över tillgängliga pipelineresursvariabler.

resources.pipeline.<Alias>.projectName 
resources.pipeline.<Alias>.projectID 
resources.pipeline.<Alias>.pipelineName 
resources.pipeline.<Alias>.pipelineID 
resources.pipeline.<Alias>.runName 
resources.pipeline.<Alias>.runID
resources.pipeline.<Alias>.runURI
resources.pipeline.<Alias>.sourceBranch 
resources.pipeline.<Alias>.sourceCommit
resources.pipeline.<Alias>.sourceProvider 
resources.pipeline.<Alias>.requestedFor
resources.pipeline.<Alias>.requestedForID

kustomize och kompose som bake-alternativ i KubernetesManifest-uppgift

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

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

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

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

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

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

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

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

Argumentindata i Docker Compose-uppgift

Ett nytt fält har introducerats i Docker Compose-aktiviteten så att du kan lägga till argument som --no-cache. Argumentet skickas av aktiviteten när du kör kommandon som build.

Förbättringar av GitHub-releaseuppgift

Vi har gjort flera förbättringar av GitHub Release-funktionen. Nu kan du ha bättre kontroll över skapandet av versioner med hjälp av taggmönsterfältet genom att ange ett reguljärt tagguttryck och versionen skapas endast när utlösande incheckning taggas med en matchande sträng.

Vi har också lagt till funktioner för att anpassa skapande och formatering av ändringsloggen. I det nya avsnittet för ändringsloggkonfiguration kan du nu ange vilken version som den aktuella versionen ska jämföras med. Den Jämför med version kan vara den sista fullständiga versionen (exkluderar förhandsversioner), den senaste versionen som inte är utkast eller någon tidigare version som matchar din angivna versionstagg. Dessutom tillhandahåller uppgiften ett fält för typ av ändringslogg för att formatera ändringsloggar. Baserat på valet visar ändringsloggen antingen en lista över commits eller en lista över ärenden/PR:er som kategoriserats utifrån etiketter.

Open Policy Agent-installationsuppgift

Open Policy Agent är en principmotor med öppen källkod som möjliggör enhetlig och kontextmedveten principframtvingande. Vi har lagt till installationsuppgiften Open Policy Agent. Det är särskilt användbart för principframtvingande i pipeline med avseende på infrastruktur som kodleverantörer.

Till exempel kan Open Policy Agent utvärdera Rego principfiler och Terraform-planer i pipeline.

task: OpenPolicyAgentInstaller@0
    inputs:
          opaVersion: '0.13.5'

Stöd för PowerShell-skript i Azure CLI-uppgift

Tidigare kunde du köra batch- och bash-skript som en del av en Azure CLI-uppgift. Med den här uppdateringen har vi lagt till stöd för PowerShell- och PowerShell-kärnskript till uppgiften.

Service Mesh Interface-baserade kanariedistributioner i KubernetesManifest-uppgift

Tidigare när kanariestrategi angavs i KubernetesManifest-aktiviteten skulle uppgiften skapa baslinje- och kanariearbetsbelastningar vars repliker motsvarade en procentandel av replikerna som används för stabila arbetsbelastningar. Detta var inte exakt samma sak som att dela upp trafiken till önskad procentsats på begärandenivå. För att hantera detta har vi lagt till stöd för Service Mesh-Gränssnitt-baserade kanarieutplaceringar till KubernetesManifest-uppgiften.

Abstraktion av Service Mesh-gränssnitt möjliggör plug-and-play-konfiguration med tjänstenätleverantörer som Linkerd och Istio. Nu tar KubernetesManifest-uppgiften bort det hårda arbetet med att mappa SMI:s TrafficSplit-objekt till stabila, baslinje- och kanarietjänster under distributionsstrategins livscykel. Den önskade procentuella uppdelningen av trafiken mellan stabil, baslinje och kanariefågel är mer exakt eftersom den procentuella trafikdelningen styrs på begäranden i service mesh-planet.

Följande är ett exempel på hur du utför SMI-baserade kanariedistributioner på ett löpande sätt.

- deployment: Deployment
    displayName: Deployment
    pool:
      vmImage: $(vmImage)
    environment: ignite.smi
    strategy:
      canary:
        increments: [25, 50]
        preDeploy:
          steps:
          - task: KubernetesManifest@0
            displayName: Create/update secret
            inputs:
              action: createSecret
              namespace: smi
              secretName: $(secretName)
              dockerRegistryEndpoint: $(dockerRegistryServiceConnection)
        deploy:
          steps:
          - checkout: self
          - task: KubernetesManifest@0
            displayName: Deploy canary
            inputs:
              action: $(strategy.action)
              namespace: smi
              strategy: $(strategy.name)
              trafficSplitMethod: smi
              percentage: $(strategy.increment)
              baselineAndCanaryReplicas: 1
              manifests: |
                manifests/deployment.yml
                manifests/service.yml
              imagePullSecrets: $(secretName)
              containers: '$(containerRegistry)/$(imageRepository):$(Build.BuildId)'
        postRouteTraffic:
          pool: server
          steps:
            - task: Delay@1
              inputs:
                delayForMinutes: '2'

Azure File Copy Task stöder nu AzCopy V10

Azure-filkopieringsaktiviteten kan användas i en bygg- eller versionspipeline för att kopiera filer till Microsoft Storage-blobbar eller virtuella datorer (VM). Uppgiften använder AzCopy, kommandoradsverktyget för snabb kopiering av data från och till Azure-lagringskonton. Med den här uppdateringen har vi lagt till stöd för AzCopy V10 som är den senaste versionen av AzCopy.

Kommandot azcopy copy stöder endast de argumenten som är associerade med det. På grund av ändringen i syntaxen för AzCopy är vissa av de befintliga funktionerna inte tillgängliga i AzCopy V10. Dessa inkluderar:

• Ange loggplats
• Rensa logg- och planfiler efter kopian
• Återuppta kopiering om jobbet misslyckas

De ytterligare funktioner som stöds i den här versionen av uppgiften är:

• Jokerteckensymboler i källans filnamn/sökväg
• Härled innehållstypen baserat på filnamnstillägget när inga argument anges
• Definiera loggverositeten för loggfilen genom att skicka ett argument

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

Varje jobb som körs i Azure Pipelines 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 upp loggar, testa resultat, artefakter 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 har vi lagt till följande förbättringar.

• Förhindra att token kommer åt resurser utanför ramen för ett teamprojekt

  Hittills har standardomfånget för alla pipelines varit gruppprojektsamlingen. Du kan ändra omfånget så att det är gruppprojektet i klassiska byggpipelines. Du hade dock inte den kontrollen för klassiska releasepipelines eller YAML-pipelines. Med den här uppdateringen introducerar vi en samlingsinställning som tvingar varje jobb att hämta en token med projektomfattning oavsett vad som har konfigurerats i pipelinen. Vi har också lagt till inställningen på projektnivå. Nu kommer varje nytt projekt och samling som du skapar automatiskt att ha den här inställningen aktiverad.

  Notera

  Insamlingsinställningen åsidosätter projektinställningen.

  Om du aktiverar den här inställningen i befintliga projekt och samlingar kan vissa pipelines misslyckas om dina pipelines med hjälp av åtkomsttokens kommer åt resurser som finns utanför teamprojektet. För att undvika pipelinefel kan du uttryckligen bevilja Project Build Service-konto åtkomst till önskad resurs. Vi rekommenderar starkt att du aktiverar dessa säkerhetsinställningar.

• Begränsa åtkomsten till build-tjänstens repo-omfång

  Azure Pipelines bygger på att förbättra pipelinesäkerheten genom att begränsa åtkomsttokens omfattning och kan nu begränsa lagringsplatsens åtkomst till de lagringsplatser som krävs för en YAML-baserad pipeline. Det innebär att om pipelines åtkomsttoken skulle läcka skulle den bara kunna se de lagringsplatser som används i pipelinen. Tidigare var åtkomsttoken bra för alla Azure Repos-lagringsplatser i projektet, eller potentiellt hela samlingen.

  Den här funktionen är aktiverad som standard för nya projekt och samlingar. För befintliga samlingar måste du aktivera den i Samlingsinställningar>Pipelines>Inställningar. När du använder den här funktionen måste alla lagringsplatser som behövs av bygget (även de som du klonar med hjälp av ett skript) ingå i lagringsplatsresurser i pipelinen.

• Ta bort vissa behörigheter för åtkomsttoken

  Som standard beviljar vi ett antal behörigheter till åtkomsttoken. En av de här behörigheterna är Queue builds. Med den här uppdateringen har vi tagit bort den här behörigheten till åtkomsttoken. Om dina pipelines behöver den här behörigheten kan du uttryckligen bevilja den till Project Build Service-konto eller Project Collection Build Service-konto beroende på vilken token du använder.

Säkerhet på projektnivå för tjänstanslutningar

Vi har lagt till säkerhet på hubbnivå för tjänstanslutningar. Nu kan du lägga till/ta bort användare, tilldela roller och hantera åtkomst på en central plats för alla tjänstanslutningar.

Stegmål och kommandoisolering

Azure Pipelines stöder att köra jobb i containrar eller på agentvärden. Tidigare var ett helt jobb inställt på ett av dessa två mål. Nu kan enskilda steg (uppgifter eller skript) köras på det mål du väljer. Steg kan också rikta sig mot andra containrar, så en pipeline kan köra varje steg i en specialiserad och specialbyggd container.

Containrar kan fungera som isoleringsgränser, vilket förhindrar att kod gör oväntade ändringar på värddatorn. Hur steg kommunicerar med och kommer åt tjänster från agenten påverkas inte av att steg isoleras i en container. Därför introducerar vi även ett kommandobegränsningsläge som du kan använda med stegmål. Om du aktiverar detta begränsas de tjänster som ett steg kan begära från agenten. Den kommer inte längre att kunna bifoga loggar, ladda upp artefakter och vissa andra åtgärder.

Här är ett omfattande exempel som visar steg som exekveras på värddatorn i en jobbcontainer och i en annan container.

resources:
  containers:
  - container: python
    image: python:3.8
  - container: node
    image: node:13.2

jobs:
- job: example
  container: python

  steps:
  - script: echo Running in the job container

  - script: echo Running on the host
    target: host

  - script: echo Running in another container, in restricted commands mode
    target:
      container: node
      commands: restricted

Skrivskyddade variabler

Systemvariabler dokumenterades som oföränderliga, men i praktiken kunde de skrivas över av en uppgift och underordnade aktiviteter skulle hämta det nya värdet. Med den här uppdateringen skärper vi säkerheten kring pipelinevariabler för att göra system- och kötidsvariabler skrivskyddade. Dessutom kan du göra en YAML-variabel skrivskyddad genom att markera den på följande sätt.

variables:
- name: myVar
  value: myValue
  readonly: true

Rollbaserad åtkomst för tjänstanslutningar

Vi har lagt till rollbaserad åtkomst för tjänstanslutningar. Tidigare kunde tjänstanslutningssäkerhet endast hanteras via fördefinierade Azure DevOps-grupper som Slutpunktsadministratörer och Slutpunktsskapare.

Som en del av det här arbetet har vi introducerat de nya rollerna Läsare, Användare, Skapare och Administratör. Du kan ange dessa roller via sidan tjänstanslutningar i projektet och dessa ärvs av de enskilda anslutningarna. Och i varje tjänstanslutning har du möjlighet att aktivera eller inaktivera arv och åsidosätta rollerna i tjänstanslutningens omfång.

Läs mer om säkerhet för tjänstanslutningar här.

Delning mellan projekt av tjänstanslutningar

Vi har aktiverat stöd för delning av tjänstanslutningar mellan projekt. Nu kan du dela dina tjänstanslutningar med dina projekt på ett säkert och säkert sätt.

Läs mer om delning av tjänstanslutningar här.

Spårbarhet för pipelines och ACR-resurser

Vi säkerställer fullständig E2E-spårning när pipelines och ACR-containerresurser används i en pipeline. För varje resurs som förbrukas av er YAML-pipeline kan ni spåra tillbaka till ändringar, arbetsobjekt och artefakter.

I sammanfattningsvyn för pipelinekörning kan du se:

• Den resursversion som utlöste körningen. Nu kan din pipeline utlösas när en annan Azure-pipelinekörning har slutförts eller när en containeravbildning skickas till ACR.

  

• kommittar som förbrukas av pipelinens. Du kan också hitta en uppdelning av de åtgärder som tagits, baserat på varje resurs som pipelinen förbrukar.

  

• De arbetsobjekt som är associerade med varje resurs som förbrukas av pipelinen.

• De artefakter som är tillgängliga för användning i körningen.

  

I miljöns distributionsvy kan du se incheckningar och arbetsobjekt för varje resurs som distribueras till miljön.

Stöd för stora testbilagor

Med uppgiften publicera testresultat i Azure Pipelines kan du publicera testresultat när tester körs för att ge en omfattande testrapportering och analysupplevelse. Hittills har det funnits en gräns på 100 MB för testbilagor för både testkörning och testresultat. Detta begränsade uppladdningen av stora filer som kraschdumpar eller videor. Med den här uppdateringen har vi lagt till stöd för stora testbilagor så att du kan ha alla tillgängliga data för att felsöka misslyckade tester.

Du kanske ser VSTest-uppgift eller Publicera testresultat-uppgift som returnerar ett fel 403 eller 407 i loggarna. Om du använder lokala byggen eller versionsagenter bakom en brandvägg som filtrerar utgående begäranden måste du göra några konfigurationsändringar för att kunna använda den här funktionen. ​

För att åtgärda det här problemet rekommenderar vi att du uppdaterar brandväggen för utgående begäranden till https://*.vstmrblob.vsassets.io. Du hittar felsökningsinformation i dokumentationen här. ​

Not

Detta krävs bara om du använder lokalt installerade Azure Pipelines-agenter och du är bakom en brandvägg som filtrerar utgående trafik. Om du använder Microsoft-värdbaserade agenter i molnet eller som inte filtrerar utgående nätverkstrafik behöver du inte vidta några åtgärder.

Visa rätt poolinformation för varje jobb

Tidigare, när du använde en matris för att expandera jobb eller en variabel för att identifiera en pool, löste vi ibland felaktig poolinformation på loggsidorna. De här problemen har lösts.

CI-utlösare för nya grenar

Det har varit en länge försenad begäran att inte utlösa CI-byggen när en ny gren skapas, och när den grenen inte har några ändringar. Tänk på följande exempel:

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

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

Jobb kan komma åt utdatavariabler från tidigare steg

Utdatavariabler kan nu användas i flera steg i en YAML-baserad pipeline. Detta hjälper dig att skicka användbar information, till exempel ett go/no-go-beslut eller ID för genererade utdata, från en fas till en annan. Resultatet (status) för en tidigare fas och dess jobb är också tillgängligt.

Utdatavariabler skapas fortfarande av steg i jobben. I stället för att referera till dependencies.jobName.outputs['stepName.variableName']refererar faserna till stageDependencies.stageName.jobName.outputs['stepName.variableName'].

Not

Som standard beror varje steg i en pipeline på den precis före den i YAML-filen. Därför kan varje steg använda utdatavariabler från föregående fas. Du kan ändra beroendediagrammet, vilket också ändrar vilka utdatavariabler som är tillgängliga. Om steg 3 till exempel behöver en variabel från steg 1 måste den deklarera ett explicit beroende av steg 1.

Inaktivera automatiska agentuppgraderingar på poolnivå

För närvarande uppdateras pipelines-agenter automatiskt till den senaste versionen när det behövs. Detta inträffar vanligtvis när det finns en ny funktion eller uppgift som kräver en nyare agentversion för att fungera korrekt. Med den här uppdateringen lägger vi till möjligheten att inaktivera automatiska uppgraderingar på poolnivå. Om ingen agent för rätt version är ansluten till poolen i det här läget misslyckas pipelines med ett tydligt felmeddelande i stället för att begära att agenter uppdateras. Den här funktionen är främst av intresse för kunder med lokalt installerade pooler och mycket strikta krav på ändringskontroll. Automatiska uppdateringar är aktiverade som standard och vi rekommenderar inte att de flesta kunder inaktiverar dem.

Agentdiagnostik

Vi har lagt till diagnostik för många vanliga agentrelaterade problem, till exempel många nätverksproblem och vanliga orsaker till uppgraderingsfel. Kom igång med diagnostik genom att använda run.sh --diagnostics eller run.cmd --diagnostics i Windows.

Tjänstkrokar för YAML-pipelines

Det blev enklare att integrera tjänster med YAML-pipelines. Med hjälp av service hooks-händelser för YAML-pipelines kan du nu initiera aktiviteter i anpassade appar eller tjänster baserat på förloppet på pipelinekörningarna. Du kan till exempel skapa en supportbegäran när ett godkännande krävs, initiera ett övervakningsarbetsflöde när en fas har slutförts eller skicka ett push-meddelande till teamets mobila enheter när en fas misslyckas.

Filtrering efter pipelinenamn och fasnamn stöds för alla händelser. Godkännandehändelser kan också filtreras för specifika miljöer. På samma sätt kan tillståndsändringshändelser filtreras efter nytt tillstånd för pipelinekörningen eller fasen.

Optimerad integrering

Optimizely är en kraftfull plattform för A/B-testning och funktionsavgränsning för produktteam. Integrering av Azure Pipelines med optimerad experimenteringsplattform gör det möjligt för produktteam att testa, lära sig och distribuera i snabbare takt, samtidigt som de får alla DevOps-fördelar med Azure Pipelines.

Tillägget Optimizely för Azure DevOps lägger till experimenteringssteg och utrullningssteg för funktionsflaggor i bygg- och versionspipelines, så att du kontinuerligt kan iterera, lansera funktioner och återställa dem med hjälp av Azure Pipelines.

Läs mer om Azure DevOps Optimizely-tillägget här.

Lägga till en GitHub-version som en artefaktkälla

Nu kan du länka dina GitHub-versioner som artefaktkälla i Azure DevOps-versionspipelines. På så sätt kan du använda GitHub-versionen som en del av dina distributioner.

När du klickar på Lägg till en artefakt i release-pipelinedefinitionen hittar du den nya GitHub Release källtyp. Du kan ange tjänstanslutningen och GitHub-lagringsplatsen för att använda GitHub-versionen. Du kan också välja en standardversion för GitHub-versionen som ska användas som den senaste, specifika taggversionen eller välja när versionen skapas. När en GitHub-version är länkad laddas den ned automatiskt och görs tillgänglig i dina versionsjobb.

Terraform-integrering med Azure Pipelines

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

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

Integrering med Google Analytics

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

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

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

ServiceNow-integrering med Azure Pipelines har uppdaterats

Azure Pipelines-appen för ServiceNow hjälper till att integrera Azure Pipelines och ServiceNow Change Management. Med den här uppdateringen kan du integrera med New York-versionen av ServiceNow. Autentiseringen mellan de två tjänsterna kan nu göras med OAuth och grundläggande autentisering. Dessutom kan du nu konfigurera avancerade framgångsvillkor så att du kan använda valfri ändringsegenskap för att bestämma gateresultatet.

Skapa Azure Pipelines från VSCode

Vi har lagt till en ny funktion i Azure Pipelines-tillägget för VSCode. Nu kan du skapa Azure Pipelines direkt från VSCode utan att lämna IDE:t.

Oberäknelig felhantering och felsökning

Vi introducerade hantering av ostadiga tester för att stödja den hela livscykeln med identifiering, rapportering och åtgärdande. För att förbättra det ytterligare lägger vi till hantering och åtgärd av flagnande testfel.

När du undersöker det flagnande testet kan du skapa en bugg med hjälp av åtgärden Bug som sedan kan tilldelas en utvecklare för att ytterligare undersöka rotorsaken till det flagnande testet. Felrapporten innehåller information om pipelinen, till exempel felmeddelande, stackspårning och annan information som är associerad med testet.

När en felrapport har lösts eller stängts avmarkerar vi automatiskt testet så det inte längre anses vara ostabilt.

Ange att VSTest-uppgifter ska misslyckas om ett minsta antal tester inte körs

VSTest-uppgiften identifierar och kör tester med hjälp av användarindata (testfiler, filterkriterier och så vidare) samt ett testkort som är specifikt för det testramverk som används. Ändringar av antingen användarindata eller testkortet kan leda till fall där tester inte identifieras och endast en delmängd av de förväntade testerna körs. Detta kan leda till situationer där pipelines lyckas genom att tester skippas i stället för att koden är av tillräckligt hög kvalitet. För att undvika den här situationen har vi lagt till ett nytt alternativ i VSTest-aktiviteten som gör att du kan ange det minsta antal tester som måste köras för att aktiviteten ska klaras.

VSTest TestResultsDirectory-alternativet är tillgängligt i aktivitetsgränssnittet

VSTest-aktiviteten lagrar testresultat och associerade filer i mappen $(Agent.TempDirectory)\TestResults. Vi har lagt till ett alternativ i aktivitetsgränssnittet så att du kan konfigurera en annan mapp för att lagra testresultat. Nu kan alla efterföljande uppgifter som behöver filerna på en viss plats använda dem.

Markdown-stöd i automatiserade testfelmeddelanden

Vi har lagt till markdown-stöd för felmeddelanden för automatiserade tester. Nu kan du enkelt formatera felmeddelanden för både testkörning och testresultat för att förbättra läsbarheten och underlätta felsökningen av testfel i Azure Pipelines. Markdown-syntaxen som stöds finns här.

Använd pipelinedekoratörer för att infoga steg automatiskt i ett distributionsjobb

Nu kan du lägga till pipelinedekoratörer till distributionsjobben. Du kan få alla anpassade steg (t.ex. sårbarhetsskanner) automatiskt inmatade i varje livscykelkrok körning av varje distributionsjobb. Eftersom pipelinedekoratörer kan tillämpas på alla pipelines i en samling kan detta användas som en del av att tillämpa säkra distributionsmetoder.

Dessutom kan distributionsjobb köras som ett containerjobb tillsammans med tjänster sidecar om de är definierade.

Testplaner

Sidan Ny testplan

En ny testplanssida (testplaner *) är tillgänglig för alla Azure DevOps-samlingar. Den nya sidan innehåller strömlinjeformade vyer som hjälper dig att fokusera på den aktuella uppgiften – testplanering, redigering eller körning. Den är också fri från rörighet och överensstämmer med resten av Azure DevOps-erbjudandet.

Hjälp mig att förstå den nya sidan

Den nya sidan Testplaner innehåller totalt 6 avsnitt där de första 4 är nya, medan avsnitten Diagram & Utökningsbarhet är de befintliga funktionerna.

1. Testplansrubrik: Använd det här för att hitta, favorit, redigera, kopiera eller klona en testplan.
2. Test suites tree: Använd detta för att lägga till, hantera, exportera eller beställa testpaket. Använd detta för att även tilldela konfigurationer och utföra testning av användargodkännande.
3. Fliken Definiera: Sammanställ, lägg till och hantera testfall i en testsvit via denna flik.
4. Kör-fliken: Tilldela och utför tester via Kör-fliken eller leta upp ett testresultat att fördjupa sig i.
5. Diagramfliken: Övervaka testkörning och status via diagram som också kan fästas på instrumentpaneler.
6. Utökningsmöjligheter: Stöder nuvarande utökningspunkter i produkten.

Låt oss ta en överblick över de nya avsnitten nedan.

1. Rubrik för testplan

uppgifter

Med rubriken Testplan kan du utföra följande uppgifter:

• Markera en testplan som favorit
• Avmarkera en favorittestplan
• Navigera enkelt bland dina favorittestplaner
• Visa itereringsvägen för testplanen, vilket tydligt visar om testplanen är aktuell eller tidigare
• Visa snabbsammanfattningen av teststatusrapporten med en länk för att navigera till rapporten
• Gå tillbaka till sidan Alla/Mina testplaner

Snabbmenyalternativ

Snabbmenyn i rubriken Testplan innehåller följande alternativ:

• Kopiera testplan: Det här är ett nytt alternativ som gör att du snabbt kan kopiera den aktuella testplanen. Mer information finns nedan.
• Redigera testplan: Med det här alternativet kan du redigera arbetsobjektformuläret Testplan för att hantera arbetsobjektfälten.
• Testplansinställningar: Med det här alternativet kan du konfigurera testkörningsinställningarna (för att associera bygg- eller versionspipelines) och testresultatinställningarna

Kopiera testplan (ny funktion)

Vi rekommenderar att du skapar en ny testplan per sprint/version. När du gör det kan vanligtvis testplanen för den tidigare cykeln kopieras över och med få ändringar är den kopierade testplanen redo för den nya cykeln. För att göra den här processen enkel har vi aktiverat funktionen "Kopiera testplan" på den nya sidan. Genom att använda den kan du kopiera eller klona testplaner. REST API:n som stöder den beskrivs här och API:t låter dig kopiera/klona en testplan mellan projekt också.
Fler riktlinjer för användning av testplaner finns i här.

2. Testsvitträd

uppgifter

Med Test suite-rubriken kan du utföra följande uppgifter:

• Expandera/dölj: Med det här verktygsfältsalternativen kan du expandera eller dölja hierarkiträdet för sviten.
• Visa testpunkter från underordnade sviter: Det här verktygsfältsalternativet visas bara när du är på fliken Kör. På så sätt kan du visa alla testpunkter för den angivna sviten och dess underordnade i en vy för enklare hantering av testpunkter utan att behöva gå till enskilda sviter en i taget.
• Order-sviter: Du kan dra/släppa sviter för att antingen ändra ordning på pakethierarkin eller flytta dem från en svithierarki till en annan i testplanen.

Snabbmenyalternativ

Snabbmenyn i testsvitträdet innehåller följande alternativ:

• Skapa nya sviter: Du kan skapa tre olika typer av sviter på följande sätt:
  • Använd statisk svit eller mappsvit för att organisera dina tester.
  • Använd kravbaserad svit för att direkt länka till kraven/användarberättelserna för sömlös spårning.
  • Använd frågebaserat för att dynamiskt organisera testfall som uppfyller frågekriterier.
• Tilldela konfigurationer: Du kan tilldela konfigurationer för sviten (till exempel Chrome, Firefox, EdgeChromium) och dessa kan sedan tillämpas på alla befintliga testfall eller nya testfall som du lägger till senare i den här sviten.
• Exportera som pdf/e-post: Exportera egenskaperna för testplanen, testpaketegenskaperna tillsammans med information om testfallen och testpunkterna som antingen "e-post" eller "skriv ut till pdf".
• Open test suite work item: Med det här alternativet kan du redigera arbetsobjektsformuläret Test suite för att hantera arbetsobjektfälten.
• Tilldela testare för att köra alla tester: Det här alternativet är mycket användbart för UAT-scenarier (User Acceptance Testing) där samma test måste köras/köras av flera testare, som vanligtvis tillhör olika avdelningar.
• Byt namn på/ta bort: Med de här alternativen kan du hantera svitnamnet eller ta bort sviten och dess innehåll från testplanen.

3. Definiera fliken

Med fliken Definiera kan du sortera, lägga till och hantera testfall för en testsvit. Fliken Kör är avsedd för att tilldela testpunkter och köra dem.

Fliken Definiera och vissa åtgärder är endast tillgängliga för användare med Grundläggande + Testplaner åtkomstnivå eller motsvarande. Allt annat bör kunna användas av en användare med åtkomstnivån "Basic".

uppgifter

På fliken Definiera kan du utföra följande uppgifter:

• Lägg till nytt testfall med hjälp av arbetsobjektsformuläret: Med det här alternativet kan du skapa ett nytt testfall med hjälp av arbetsobjektsformuläret. Testfallet som skapas läggs automatiskt till i sviten.
• Lägg till nytt testfall med hjälp av rutnät: Med det här alternativet kan du skapa ett eller flera testfall med hjälp av rutnätsvyn för testfall. Testfallen som skapas läggs automatiskt till i sviten.
• Lägg till befintliga testfall med hjälp av en fråga: Med det här alternativet kan du lägga till befintliga testfall i sviten genom att ange en fråga.
• Ordna testfall genom dra/släpp: Du kan ordna om testfall genom att dra och släppa ett eller flera testfall inom en bestämd svit. Ordningen på testfall gäller endast för manuella testfall och inte för automatiserade tester.
• Flytta testfall från en svit till en annan: Med dra/släpp kan du flytta testfall från en testsvit till en annan.
• Visa rutnät: Du kan använda rutnätsläget för att visa/redigera testfall tillsammans med teststeg.
• helskärmsvyn: Du kan visa innehållet på hela fliken Definiera i helskärmsläge med det här alternativet.
• Filtrering: Med hjälp av filterfältet kan du filtrera listan över testfall med hjälp av fälten "testfallsrubrik", "tilldelad till" och "tillstånd". Du kan också sortera listan genom att klicka på kolumnrubrikerna.
• Kolumnalternativ: Du kan hantera listan med kolumner som visas på fliken Definiera med hjälp av "Kolumnalternativ". Listan över kolumner som är tillgängliga för markering är främst fälten från arbetsobjektsformuläret för testfall.

Snabbmenyalternativ

Snabbmenyn på noden Testfall på fliken Definiera innehåller följande alternativ:

• Öppna/redigera arbetsobjektformulär för testfall: Med det här alternativet kan du redigera ett testfall med hjälp av arbetsobjektsformuläret där du redigerar arbetsobjektfälten, inklusive teststeg.
• Redigera testfall: Med det här alternativet kan du massredigera fält för arbetsobjekt för testfall. Du kan dock inte använda det här alternativet för att massredigera teststeg.
• Redigera testfall i rutnät: Med det här alternativet kan du massredigera de valda testfallen, inklusive teststeg med hjälp av rutnätsvyn.
• Tilldela konfigurationer: Med det här alternativet kan du åsidosätta konfigurationerna på svitens nivå med konfigurationerna på testfallens nivå.
• Ta bort testfall: Med det här alternativet kan du ta bort testfallen från den angivna sviten. Den ändrar dock inte det underliggande arbetsobjektet för testfall.
• Skapa en kopia/klon av testfall: Med det här alternativet kan du skapa en kopia/klon av valda testfall. Mer information finns nedan.
• Visa länkade objekt: Med det här alternativet kan du titta på de länkade objekten för ett visst testfall. Mer information finns nedan.

Kopiera/klona testfall (ny funktion)

För scenarier där du vill kopiera/klona ett testfall kan du använda alternativet "Kopiera testfall". Du kan ange målprojektet, måltestplanen och måltestpaketet där du vill skapa det kopierade/klonade testfallet. Du kan också ange om du vill inkludera befintliga länkar/bifogade filer som ska flöda till den klonade kopian.

Visa länkade objekt (ny funktion)

Spårbarhet bland testartefakter, krav och buggar är ett viktigt värdeförslag för produkten Testplaner. Med alternativet "Visa länkade objekt" kan du enkelt titta på alla länkade krav som det här testfallet är kopplat till, alla testpaket/testplaner där det här testfallet har använts och alla buggar som har arkiverats som en del av testkörningen.

4. Fliken Kör

Med fliken Definiera kan du sortera, lägga till och hantera testfall för en testsvit. Fliken Kör är avsedd för att tilldela testpunkter och köra dem.

Vad är en testpunkt? Testfall kan inte köras själva. När du lägger till ett testfall i en testsvit genereras testpunkter. En testpunkt är en unik kombination av testfall, testpaket, konfiguration och testare. Exempel: Om du har ett testfall som "Testa inloggningsfunktioner" och du lägger till 2 konfigurationer i det som Edge och Chrome resulterar detta i 2 testpunkter. Nu kan dessa testpunkter köras. Vid exekvering genereras testresultat. I testresultatvyn (körningshistorik) kan du se alla körningar av en testpunkt. Den senaste körningen för testpunkten är det du ser på fliken Kör.
Därför är testfall återanvändbara entiteter. Genom att inkludera dem i en testplan eller svit genereras testpunkter. Genom att köra testpunkter fastställer du kvaliteten på den produkt eller tjänst som utvecklas.

En av de främsta fördelarna med den nya sidan är för användare som huvudsakligen utför testkörning och spårning (och därför bara behöver ha åtkomstnivån "Basic") att de inte överväldigas av komplexiteten i svithanteringen (fliken 'definiera' är dold för dessa användare).

Fliken Definiera och vissa åtgärder är endast tillgängliga för användare med Grundläggande + Testplaner åtkomstnivå eller motsvarande. Allt annat, inklusive fliken "Kör" bör kunna användas av en användare med åtkomstnivån Basic.

uppgifter

På fliken Kör kan du utföra följande uppgifter:

• Testpunkter för massmarkering: Med det här alternativet kan du snabbt markera resultatet av testpunkterna – godkänt, misslyckat, blockerat eller inte tillämpligt, utan att behöva köra testfallet via testrunnern. Resultatet kan markeras för en eller flera testpunkter på en gång.
• Kör testpunkter: Med det här alternativet kan du köra testfallen individuellt genom att gå igenom varje teststeg och markera dem som godkända/icke-godkända med hjälp av en testrunner. Beroende på vilket program du testar kan du använda "Web Runner" för att testa ett "webbprogram" eller "desktop runner" för att testa skrivbords- och/eller webbprogram. Du kan också anropa "Kör med alternativ" för att ange en version som du vill utföra testningen mot.
• Kolumnalternativ: Du kan hantera listan med kolumner som visas på fliken Kör med hjälp av "Kolumnalternativ". Listan över kolumner som är tillgängliga för val är associerad med testpunkter, till exempel Kör av, Tilldelad testare, Konfiguration osv.
• Helskärmsvyn: Du kan visa innehållet av fliken Utför i helskärmsläge med det här alternativet.
• Filtrering: Med hjälp av filterfältet kan du filtrera listan över testpunkter med hjälp av fälten "testfallsrubrik", "tilldelad till", "tillstånd", "testresultat", "Test" och "Konfiguration". Du kan också sortera listan genom att klicka på kolumnrubrikerna.

Snabbmenyalternativ

Snabbmenyn på noden Testpunkt på fliken Kör innehåller följande alternativ:

• Markera testresultatet: På samma sätt som ovan kan du snabbt markera resultatet av testpunkterna – godkänt, misslyckat, blockerat eller inte tillämpligt.
• Kör testpunkter: Precis som ovan, kan du köra testfallen via testrunner.
• Återställ test till aktiv: Med det här alternativet kan du återställa testresultatet till aktivt, vilket ignorerar testpunktens sista resultat.
• Öppna/redigera arbetsobjektformulär för testfall: Med det här alternativet kan du redigera ett testfall med hjälp av arbetsobjektsformuläret där du redigerar arbetsobjektfälten, inklusive teststeg.
• Tilldela testare: Med det här alternativet kan du tilldela testpunkter till testare för testkörning.
• Visa testresultat: Med det här alternativet kan du visa den senaste testresultatinformationen, inklusive resultatet av varje teststeg, kommentarer som lagts till eller buggar som har lämnats in.
• Visa körningshistorik: Med det här alternativet kan du visa hela körningshistoriken för den valda testpunkten. Den öppnar en ny sida där du kan justera filtren för att visa körningshistoriken för inte bara den valda testpunkten utan även för hela testfallet.

Förloppsrapport för testplaner

Den här förkonfigurerade rapporten hjälper dig att spåra genomförandet och statusen för en eller flera testplaner i ett projekt. Gå till Testplaner > Förloppsrapport* för att börja använda rapporten.

De tre avsnitten i rapporten innehåller följande:

1. Sammanfattning: visar en konsoliderad vy för de valda testplanerna.
2. Utfallstrend: ger en daglig översikt för att ge dig en trendlinje för utförande och status. Den kan visa data i 14 dagar (standard), 30 dagar eller ett anpassat intervall.
3. Information: I det här avsnittet kan du fördjupa dig i detaljer för varje testplan och få viktig analys för varje testsvit.

Artefakter

Not

Azure DevOps Server 2020 importerar inte feeds som finns i papperskorgen under dataimporten. Om du vill importera flöden som finns i papperskorgen, återställ dem från papperskorgen innan du startar dataimporten.

Licensuttryck och inbäddade licenser

Nu kan du se information om licensinformation för NuGet-paket som lagras i Azure Artifacts när du bläddrar i paket i Visual Studio. Detta gäller för licenser som representeras med hjälp av licensuttryck eller inbäddade licenser. Nu kan du se en länk till licensinformationen på visual studio-paketinformationssidan (röd pil i bilden nedan).

Om du klickar på länken kommer du till en webbsida där du kan visa information om licensen. Den här upplevelsen är densamma för både licensuttryck och inbäddade licenser, så du kan se licensinformation för paket som lagras i Azure Artifacts på ett ställe (för paket som anger licensinformation och stöds av Visual Studio).

Lätta autentiseringsuppgifter

Nu kan du autentisera med populära pakethanterare från Azure Pipelines med hjälp av lättviktsautentiseringsuppgifter. Detta inkluderar NuGet, npm, PIP, Twine och Maven. Tidigare kunde du autentisera med dessa pakethanterare med hjälp av uppgifter som gav en stor mängd funktioner, inklusive möjligheten att publicera och ladda ned paket. Detta krävde dock användning av dessa uppgifter för alla aktiviteter som interagerade med pakethanterarna. Om du hade egna skript att köra för att utföra uppgifter som att publicera eller ladda ned paket, skulle du inte kunna använda dem i pipelinen. Nu kan du använda skript med din egen design i yaml-pipelinen och utföra verifiering med dessa nya lätta uppdrag. Ett exempel med npm:

Användningen av kommandot "ci" och "publish" i den här bilden är godtycklig, du kan använda kommandon som stöds av Azure Pipelines YAML. På så sätt kan du ha fullständig kontroll över kommandoanrop och gör det enkelt att använda delade skript i pipelinekonfigurationen. Mer information finns i NuGet, npm, PIP, Twineoch Maven dokumentation om autentiseringsuppgifter.

Förbättringar av inläsningstiden för feedsidor

Vi är glada över att kunna meddela att vi har förbättrat inläsningstiden för flödessidan. I genomsnitt har laddningstiderna för flödessidan minskat med 10%. De största flödena har sett den största förbättringen, inläsningstiden för den 99:e percentilen av flödessidorna (inläsningstiderna i de högsta 99% av alla flöden) minskade med 75%.

Dela dina paket offentligt med publika feeds

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

Konfigurera uppströmskonfigurationer i olika samlingar inom en AAD-klientorganisation

Nu kan du lägga till ett flöde i en annan samling som är associerad med din Azure Active Directory-klient (AAD) som uppströmskälla till ditt artefaktflöde. Ditt flöde kan hitta och använda paket från flöden som är konfigurerade som uppströmskällor, vilket gör att paket enkelt kan delas mellan samlingar som är associerade med din AAD-klientorganisation. Se hur du konfigurerar det här i dokumentationen.

Använd Python Credential Provider för att autentisera pip och twine med Azure Artifacts-feeds

Du kan nu installera och använda Python Credential Provider (artifacts-keyring) för att automatiskt konfigurera autentisering för att publicera eller använda Python-paket till eller från en Azure Artifacts-feed. Med autentiseringsprovidern behöver du inte konfigurera några konfigurationsfiler (pip.ini/pip.conf/.pypirc), du kommer helt enkelt att tas via ett autentiseringsflöde i webbläsaren när du anropar pip eller twine för första gången. Mer information finns i dokumentationen.

Azure Artifacts-flöden i Visual Studio Package Manager

Nu visar vi paketikoner, beskrivningar och författare i Visual Studio NuGet Package Manager för paket som hanteras från Azure Artifacts-feeds. Tidigare har de flesta av dessa metadata inte tillhandahållits till VS.

Connect to feed-upplevelsen har uppdaterats

Dialogrutan Anslut till feed är startvägen till att använda Azure Artifacts. den innehåller information om hur du konfigurerar klienter och lagringsplatser för att skicka och hämta paket från feeds i Azure DevOps. Vi har uppdaterat dialogrutan för att lägga till detaljerad konfigurationsinformation och utökat de verktyg som vi ger instruktioner för.

Offentliga feeds är nu allmänt tillgängliga med stöd från ursprungsleverantörer

Den offentliga förhandsversionen av offentliga flöden har fått stort upptagande och positiv feedback. I den här versionen utökade vi ytterligare funktioner till allmän tillgänglighet. Nu kan du ange ett offentligt flöde som en uppströmskälla från ett privat flöde. Du kan hålla konfigurationsfilerna enkla genom att kunna överföra både till och från privata och projektavgränsade flöden.

Skapa projektbaserade feeds från portalen

När vi släppte offentliga feeds släppte vi även projektomfattande feeds. Hittills har projektomfattande feeds skapats via REST-API:er eller genom att skapa ett offentligt flöde och sedan göra projektet privat. Nu kan du skapa feeds med projektomfattning direkt i portalen från valfritt projekt om du har de behörigheter som krävs. Du kan också se vilka flöden som är projektbegränsade och vilka som är samlingsbegränsade i flödesväljaren.

Prestandaförbättringar för npm

Vi har gjort ändringar i vår kärndesign för att förbättra hur vi lagrar och levererar npm-paket i Azure Artifacts-feeds. Detta har hjälpt oss att uppnå upp till 10-faldig minskning av svarstiden för några av de mest använda API:erna för npm.

Hjälpmedelsförbättringar

Vi har distribuerat korrigeringar för att åtgärda tillgänglighetsproblem på vår feeds-sida. Korrigeringarna innehåller följande:

• Skapa flödesupplevelse
• Upplevelsen av globala feedinställningar
• Ansluta till feed-upplevelse

Wiki

Avancerad redigering för wikidor med kod

När du redigerade en wiki-sida för kod tidigare omdirigerades du till Azure Repos Hub för redigering. För närvarande är Repo-hubben inte optimerad för Markdown-redigering.

Nu kan du redigera en wiki-kodsida i redigeraren sida vid sida i wikin. På så sätt kan du använda verktygsfältet rich markdown för att skapa ditt innehåll, vilket gör redigeringsupplevelsen identisk med den i projekt-wikin. Du kan fortfarande välja att redigera i lagringsplatser genom att välja alternativet Redigera i lagringsplatser i snabbmenyn.

Skapa och bädda in arbetsobjekt från en wiki-sida

När vi lyssnade på din feedback hörde vi att du använder wiki för att samla in brainstormingdokument, planeringsdokument, idéer om funktioner, specdokument, mötesminuter. Nu kan du enkelt skapa funktioner och användarberättelser direkt från ett planeringsdokument utan att lämna wiki-sidan.

Om du vill skapa ett arbetsobjekt markerar du texten på wiki-sidan där du vill bädda in arbetsobjektet och väljer Nytt arbetsobjekt. Detta sparar tid eftersom du inte behöver skapa arbetsobjektet först, gå till redigera och leta reda på arbetsobjektet för att bädda in det. Det minskar också kontextväxlingen eftersom du inte går utanför wiki-omfånget.

Mer information om hur du skapar och bäddar in ett arbetsobjekt från wiki finns i vår dokumentation här.

Kommentarer på wiki-sidor

Tidigare hade du inte något sätt att interagera med andra wiki-användare i wikin. Detta gjorde det utmanande att samarbeta kring innehåll och få svar på frågor eftersom konversationer måste ske över e-post eller chattkanaler. Med kommentarer kan du nu samarbeta med andra direkt i wikin. Du kan använda användarfunktionen @mention i kommentarer för att dra uppmärksamhet till andra teammedlemmar. Den här funktionen prioriterades baserat på den här förslagsbegäran. Mer information om kommentarer finns i vår dokumentation här.

Dölj mappar och filer som börjar med "". i wikiträd

Hittills har wiki-trädet visat alla mappar och filer som börjar med en punkt (.) i wikiträdet. I kod-wiki-scenarier orsakade detta att mappar som .vscode, som är avsedda att döljas, dök upp i wikiträdet. Nu kommer alla filer och mappar som börjar med en punkt att förbli dolda i wiki-trädet, vilket minskar onödig oreda.

Den här funktionen prioriterades baserat på den här förslagsbegäran.

Url:er för kort och läsbar Wiki-sida

Du behöver inte längre använda en url med flera sidor för att dela wiki-sidlänkar. Vi använder sid-ID:na i URL:en för att ta bort parametrar, vilket gör URL:en kortare och enklare att läsa.

Den nya strukturen för URL:er ser ut så här:

https://dev.azure.com/{accountName}/{projectName}/_wiki/wikis/{wikiName}/{pageId}/{readableWiki PageName}

Det här är ett exempel på den nya URL:en för en Välkommen till Azure DevOps Wiki sida:

https://dev.azure.com/microsoft/ AzureDevOps/_wiki/wikis/AzureDevOps.wiki/1/Welcome-to-Azure-DevOps-Wiki

Detta prioriterades baserat på den här funktionsförslagsbegäran från utvecklarcommunityn.

Synkron rullning för redigering av wiki-sidor

Det är nu enklare att redigera wiki-sidor med synkron rullning mellan redigerings- och förhandsgranskningsfönstret. Om du rullar på ena sidan rullas automatiskt den andra sidan för att mappa motsvarande avsnitt. Du kan inaktivera synkron rullning med växlingsknappen.

Not

Tillståndet för den synkrona rullningsväxlingsknappen sparas per användare och konto.

Sidbesök för wiki-sidor

Nu kan du få insikter om sidbesöken för wiki-sidor. Med REST-API:et kan du komma åt informationen om sidbesök under de senaste 30 dagarna. Du kan använda dessa data för att skapa rapporter för dina wiki-sidor. Dessutom kan du lagra denna data i din datakälla och skapa instrumentpaneler för att få specifika insikter som topp-n mest visade sidor.

Du kommer också att se antalet aggregerade sidbesök för de senaste 30 dagarna på varje sida.

Notera

Ett sidbesök definieras som en sidvisning av en viss användare inom ett intervall på 15 minuter.

Rapportering

Rapporter om pipelinefel och felvaraktighet

Mått och insikter hjälper dig att kontinuerligt förbättra dataflödet och stabiliteten för dina pipelines. Vi har lagt till två nya rapporter för att ge dig insikter om dina pipelines.

1. Rapporten om pipeline-fel visar byggpasseringsfrekvensen och trenden för fel. Dessutom visas också trenden för aktivitetsfel för att ge insikter om vilken aktivitet i pipelinen som bidrar till det maximala antalet fel.

2. Rapporten om pipelinevaraktighet visar trenden för tiden det tar för en pipeline att köras. Den visar också vilka aktiviteter i pipelinen som tar mest tid.

Förbättring av widgeten Frågeresultat

Widget frågeresultat är en av våra mest populära widgetar, och det av goda skäl. Widgeten visar resultatet av en fråga direkt på instrumentpanelen och är användbar i många situationer.

Med den här uppdateringen har vi inkluderat många efterlängtade förbättringar:

• Nu kan du välja så många kolumner som du vill visa i widgeten. Ingen fler gräns på 5 kolumner!
• Widgeten stöder alla storlekar, från 1x1 till 10x10.
• När du ändrar storlek på en kolumn sparas kolumnbredden.
• Du kan expandera widgeten till helskärmsvyn. När den expanderas visas alla kolumner som returneras av frågan.

Avancerad filtrering av led- och cykeltidswidgetar

Ledtid och cykeltid används av team för att se hur lång tid det tar för arbetet att flöda genom deras utvecklingspipeline och slutligen leverera värde till sina kunder.

Hittills har lead- och cykeltidswidgetarna inte haft stöd för avancerade filterkriterier för att ställa frågor som: "Hur lång tid tar det för mitt team att avsluta de mer prioriterade objekten?"

Med den här uppdateringen kan frågor som denna besvaras genom filtrering på board swimlane.

Vi har också inkluderat filter för arbetsobjekt för att begränsa de arbetsobjekt som visas i diagrammet.

Inline sprint burndown med hjälp av berättelsepunkter

Din Sprint Burndown kan nu brännas ner med hjälp av berättelser. Detta bemöter din feedback från Developer Community.

Från sprinthubben väljer du fliken Analys. Konfigurera sedan rapporten på följande sätt:

1. Välj användarberättelser i backloggen
2. Välj att bränna ned på Sum of Story Points

En Sprint Burndown-widget med allt du har bett om

Den nya Sprint Burndown-widgeten har stöd för att bränna ned efter storypunkter, antal uppgifter eller genom att summera anpassade fält. Du kan till och med skapa en sprintburndown för funktioner eller epics. Widgeten visar genomsnittlig nedbränningsdiagram, % complete och omfattningsökning. Du kan konfigurera teamet så att du visar sprintnedbrytningar för flera team på samma instrumentpanel. Med all den här fantastiska informationen att visa kan du ändra storlek på den upp till 10 x 10 på kontrollpanelen.

Om du vill prova kan du lägga till den från widgetkatalogen eller genom att redigera konfigurationen för den befintliga Sprint Burndown-widgeten och kontrollera Prova den nya versionen nu rutan.

Observera

Den nya widgeten använder Analytics. Vi behöll den äldre Sprint Burndown om du inte har åtkomst till Analytics.

Miniatyrbild för inbyggd sprint burndown

Sprint Burndown är tillbaka! För några sprinter sedan tog vi bort sprintbrännskadan i kontexten från Sprint Burndown- och Taskboard-huvudena. Baserat på din feedback har vi förbättrat och återinfört miniatyrbilden för sprintbrännad.

Om du klickar på miniatyrbilden visas omedelbart en större version av diagrammet med ett alternativ för att visa den fullständiga rapporten under fliken Analys. Alla ändringar som görs i den fullständiga rapporten återspeglas i diagrammet som visas i rubriken. Så du kan nu konfigurera den till att nedräkningen baseras på användarberättelser, berättelsepoäng eller antal uppgifter, i stället för att bara baseras på mängden arbete som återstår.

Skapa en instrumentpanel utan team

Du kan nu skapa en instrumentpanel utan att associera den med ett team. När du skapar en instrumentpanel väljer du Project Dashboard typ.

En projektinstrumentpanel är som en teaminstrumentpanel, förutom att den inte är associerad med ett team och du kan bestämma vem som kan redigera/hantera instrumentpanelen. Precis som en Team Dashboard, är den synlig för alla i projektet.

Alla Azure DevOps-widgetar som kräver en teamkontext har uppdaterats så att du kan välja ett team i konfigurationen. Du kan lägga till dessa widgetar i Projektinstrumentpaneler och välja det specifika team du vill ha.

Not

För anpassade widgetar eller widgetar från tredje part kommer en projektinstrumentpanel att föra över standardteamets kontext till dess widgetar. Om du har en anpassad widget som förlitar sig på teamkontext bör du uppdatera konfigurationen så att du kan välja ett team.

---

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