Viktig information om Azure DevOps Server 2019

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 stöds från Azure DevOps Server 2020, Azure DevOps Server 2019 eller Team Foundation Server (TFS) 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 pipeline körning (build) kvarhållningsmodell som fungerar baserat på inställningar på projektnivå .

Azure DevOps Server 2020 hanterar byggkvarhållning på olika sätt, baserat på kvarhållningsprinciper på pipelinenivå. Vissa principkonfigurationer leder till att pipelinekörningar tas bort efter uppgraderingen. Pipelinekörningar som har behållits manuellt eller som behålls av en release kommer inte att tas 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 2019.0.1 Patch 16: 14 november 2023

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

• Utökade listan över tillåtna tecken i PowerShell-uppgifter för Aktivera verifiering av argument till shell-uppgifter.

Installera korrigeringar

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

Pipelinkrav

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

• Om klassisk:

  Definiera variabeln på variabelfliken i pipelinen.

• YAML-exempel:

variables: 
- name: AZP_75787_ENABLE_NEW_LOGIC 
  value: true 

Versionsdatum för Azure DevOps Server 2019.0.1 Patch 15: 12 september 2023

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

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

Installera korrigeringar

1. Ladda ned och installera Azure DevOps Server 2019.0.1 Patch 15.

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.  

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 

Pipelinkrav

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

• Om klassisk:

  Definiera variabeln på variabelfliken i pipelinen.

• YAML-exempel:

variables: 
- name: AZP_75787_ENABLE_NEW_LOGIC 
  value: true 

Versionsdatum för Azure DevOps Server 2019.0.1 Patch 14: 8 augusti 2022

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

• CVE-2023-36869: Azure DevOps Server Spoofing Vulnerability.

Versionsdatum för Azure DevOps Server 2019.0.1 Patch 13: 17 maj 2022

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

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

Versionsdatum för Azure DevOps Server 2019.0.1 Patch 12: 26 januari 2022

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

• Åtgärdat Elasticsearch-sårbarhet genom att ta bort klassen jndilookup från log4j-binärfiler.

Installationssteg

1. Uppgradera servern med Patch 12.
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.

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

SHA-256-hash: 96C7AF3E3ED67C76451BA228427B3C0738EEB4A5835B6A91EBD3205A54C384D7

Versionsdatum för Azure DevOps Server 2019.0.1 Patch 11: 10 augusti 2021

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

• Åtgärda fel i användargränssnittet för byggdefinition.

Versionsdatum för Azure DevOps Server 2019.0.1 Patch 10: 13 april 2021

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

• CVE-2021-27067: Informationsupplysning

För att tillämpa Patch 10 måste du installera AzureResourceGroupDeploymentV2-uppgiften.

AzureResourceGroupDeploymentV2-aktivitetsinstallation

Installera

1. Extrahera AzureResourceGroupDeploymentV2.zip-paketet till en ny mapp på datorn. Exempel: 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 kommando 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 2019.0.1 Patch 9: 8 december 2020

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

• CVE-2020-1325: Azure DevOps Server Spoofing Vulnerability
• CVE-2020-17135: Azure DevOps Server Spoofing Vulnerability
• CVE-2020-17145: Azure DevOps Server och Team Foundation Server Förfalskningssårbarhet
• Åtgärda problem med att TFVC inte bearbetar alla resultat

Allmän patchinstallation

Om du har Azure DevOps Server 2019.0.1 bör du installera Azure DevOps Server 2019.0.1 Patch 9.

Verifiering av installation

• Alternativ 1: Kör devops2019.0.1patch9.exe CheckInstall, devops2019.0.1patch9.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 2019\Application Tier\Web Services\bin\Microsoft.VisualStudio.Services.Feed.Server.dll. Azure DevOps Server 2019 installeras på c:\Program Files\Azure DevOps Server 2019 som standard. När du har installerat Azure DevOps Server 2019.0.1 Patch 9 blir versionen 17.143.30723.4 .

Installation av AzurePowerShellV4-aktivitet

Förutsättningar

1. Installera Azure PowerShell Az-modulen Azure Powershell på din privata agentdator.

2. Skapa en pipeline med uppgiften AzurePowerShellV4. Du kommer endast att se ett Fel på standardavvikelse i uppgiften.

Installera

1. Extrahera AzurePowerShellV4.zip-paketet till en mapp med namnet AzurePowerShellV4.

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 kommando 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. Sökvägen till det extraherade paketet är D:\tasks (1)\AzurePowerShellv4.

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

Versionsdatum för Azure DevOps Server 2019.0.1 Patch 8: 8 september 2020

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

• DTS-1713492 – Oväntat beteende när AD-grupper läggs till i säkerhetsbehörigheter.

Versionsdatum för Azure DevOps Server 2019.0.1 Patch 7: 14 juli 2020

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

• CVE-2020-1326: Sårbarhet för skript mellan webbplatser
• Byggpipeline visar inkorrekt anslutning för obehöriga användare när du väljer annan Git-källa.
• Åtgärda fel vid ändring av arv till På eller Av i XAML-byggdefinition.

Versionsdatum för Azure DevOps Server 2019.0.1 Patch 6: 10 juni 2020

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

• CVE-2020-1327: Se till att Azure DevOps Server sanerar användarindata
• Lägga till stöd för SHA2 i SSH på Azure DevOps

Versionsdatum för Azure DevOps Server 2019.0.1 Patch 5: 10 mars 2020

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

• CVE-2020-0700: Sårbarhet för skript mellan webbplatser
• CVE-2020-0758: Sårbarhet för eskalering av privilegier
• CVE 2020-0815: Förhöjning av privilegiesårbarhet

Versionsdatum för Azure DevOps Server 2019.0.1 Patch 3: 10 september 2019

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

• CVE-2019-1305: XSS-sårbarhet (Cross site scripting) i Repos
• CVE-2019-1306: Sårbarhet för körning av fjärrkod i Wiki

Versionsdatum för Azure DevOps Server 2019.0.1 Patch 2: 13 augusti 2019

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

• Vi har lagt till information i tjänstanslutningar för att tydliggöra att de som standard är auktoriserade för alla pipelines.

Versionsdatum för Azure DevOps Server 2019.0.1 Patch 1: 9 juli 2019

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

• CVE-2019-1072: Sårbarhet vid körning av fjärrkod i spårning av arbetsobjekt
• CVE-2019-1076: XSS-sårbarhet (cross site scripting) i pull-begäranden

Versionsdatum för Azure DevOps Server 2019.0.1: 21 maj 2019

Azure DevOps Server 2019.0.1 är en sammanställning av felkorrigeringar. Den innehåller alla korrigeringar i Azure DevOps Server 2019-korrigeringar som tidigare släppts. Du kan installera Azure DevOps Server 2019.0.1 direkt eller uppgradera från Azure DevOps Server 2019 eller Team Foundation Server 2012 eller senare.

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

Azure-tavlor

• "Fältvillkoren för den här planen har ett fel." när du konfigurerar en plan. Rapporterat genom Developer Community.
• apiwitcontroller.executequery genererar ett undantag när en fråga har samma kolumn flera gånger.
• WorkItemServer.DownloadFile() misslyckas i klientobjektmodellen med vso.work_full oauth-omfång.
• Om du kopierar en inbäddad bild från ett arbetsobjektfält till ett annat arbetsobjektfält i ett annat projekt kan det skapa en bruten bild.

Azure-lagringsplatser

• "TF401019: GitRepositoryNotFoundException".

Azure-pipelines

• Fliken testanalys har en stjärna (*) som indikerar förhandsvisning, även om den här funktionen inte är i förhandsvisning.
• På fliken Versioner visas nu åtgärden för att hantera säkerhet för alla användare oavsett om de kan ändra behörigheterna eller inte.
• På landningssidorna för releaser skapade startutkaståtgärden tidigare en ny release, men nu påbörjar den utkastreleasen.

Azure-testplaner

• Filtret på 1 timme på TestRuns och TestResults CompletedDate är för detaljerat.
• I testfall arbetsobjekttyp ska typen "Testfall" inte lokaliseras.
• Testfall visas inte i MTM eller i en webbläsare.
• "Valideringssteg: Felmeddelande 'Du har inte behörighet att utlösa utgåvor på den associerade versionspipelinen' när du kör automatiserade tester från en test plan." Rapporterat genom Developer Community.
• Med hjälp av API:et för att ta bort testfallkan man ta bort testfall från andra projekt. Rapporterat genom Developer Community.
• Om du klickar på en arbetsobjektslänk i Test Runner öppnas arbetsobjektets URL i Test Runner i stället för standardwebbläsaren.
• Status för testfall uppdateras inte för användare som loggar ut från Test Runner.
• Användarnamn och e-postadress visas inte i användarlistrutan i Test Runner.

Azure Artifacts

• Flytta upp och Flytta ned är inte lokaliserade i uppströmssystemen.

Analytik

• Analysrapporter kan visa ofullständiga data eftersom modellen är markerad som "klar" innan den faktiskt är klar.
• Widgetar för hastighet, nedbränningsdiagram och uppbränningsdiagram visar planerat arbete för användare i olika tidszoner.
• En paus kan läggas på datainsamling för analys medan underhåll görs, vilket kan leda till inaktuella rapporter.

Allmänt

• Vänsternavigeringsobjekten pressas samman i IE när det inte finns tillräckligt med utrymme.

Förvaltning

• Ytterligare loggning har lagts till i samlingsuppgraderingen för att underlätta felsökning av problem.
• När TfsConfig offlineDetach misslyckas är felmeddelandet inte användbart.
• TfsJobAgent-tjänsten kraschar.
• Söktillägget installeras inte när konfigurationen har slutförts.
• Administrationskonsolen svarar inte när konfigurationsdatabasen är skadad.
• Service Hooks kanske inte bearbetar meddelanden korrekt.
• Indexering av kodsökning startar inte efter att sökningen har konfigurerats.
• Det finns olokaliserade strängar i sökresultaten.

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

Stöd för Visual Studio 2019 (VS2019) i Visual Studio Test-uppgift

Vi har lagt till stöd för Visual Studio 2019 till Visual Studio-testaktiviteten i pipelines. Om du vill köra tester med testplattformen för Visual Studio 2019 väljer du Senaste eller Visual Studio 2019 alternativ i listrutan Testplattformsversion.

Versionsdatum för Azure DevOps Server 2019 Patch 2: 14 maj 2019

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

• CVE-2019-0872: XSS-sårbarhet (Cross site scripting) i testplanerna
• CVE-2019-0971: Sårbarhet för informationsexponering i Repos API
• CVE-2019-0979: XSS-sårbarhet (Cross site scripting) i användarhubben

Versionsdatum för Azure DevOps Server 2019 Patch 1: 9 april 2019

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

• CVE-2019-0857: Förfalskning av sårbarhet i Wiki
• CVE-2019-0866: Sårbarhet vid fjärrkodkörning i pipelines
• CVE-2019-0867: XSS-sårbarhet (Cross site scripting) i Pipelines
• CVE-2019-0868: XSS-sårbarhet (Cross site scripting) i Pipelines
• CVE-2019-0869: säkerhetsproblem med HTML-inmatning i pipelines
• CVE-2019-0870: XSS-sårbarhet (Cross site scripting) i Pipelines
• CVE-2019-0871: XSS-sårbarhet (cross site scripting) i Pipelines
• CVE-2019-0874: XSS-sårbarhet (Cross site scripting) i Pipelines
• CVE-2019-0875: Förhöjd privilegiesårbarhet i boards

Lanseringsdatum för Azure DevOps Server 2019: 5 mars 2019

RC2 Utgivningsdatum: 22 januari 2019

Sammanfattning av nyheter i Azure DevOps Server 2019 RC2

Vi har lagt till följande funktioner i RC2:

• Länka GitHub Enterprise-commits och pull-begäranden till arbetsobjekt i Azure Boards
• Konfigurera byggen med YAML
• Kortkommentarerna inkluderar fel och anpassade typer av arbetsobjekt
• Förbättrad grenväljare
• ändringar i licensieringen av distribution av artefakter och versionshanteringspipeline

RC1 Utgivningsdatum: 19 november 2018

Sammanfattning av nyheter i Azure DevOps Server 2019 RC1

Azure DevOps Server 2019 introducerar en ny navigeringsupplevelse och många nya funktioner. Några av höjdpunkterna är:

• Ny navigeringsupplevelse
• Analytics Marketplace-tillägget för rapportering är nu tillgängligt
• stöd för Azure SQL Database
• Hantera arv i nya samlingar
• Hub för nya arbetsobjekt
• Nya Tavlor, Backloggar, och Sprint-nav
• hubb för nya frågor
• Standardisera beskrivningar av pull-begäranden med hjälp av mallar
• Ändra målgrenen för en pull request
• Hantera byggpipeline med hjälp av den nya versionssidan
• Hantera versionspipelines med hjälp av den nya versionssidan
• Visualisera versionsframstatus
• Uppdatera din agent lokalt
• Progressivt exponera och stegvis fasa distributioner genom att använda releasergrindar
• Överordnade källor
• Skapa innehållsförteckning för wiki-sidor

Du kan också gå till enskilda avsnitt för att se de nya funktionerna:

• Allmänt
• tavlor
• Repository
• Rörledningar
• Testplaner
• Föremål
• Wiki
• Rapportering

Allmänt

Meddelande om Azure DevOps Server

Den 10 september tillkännagav vi Azure DevOps som utvecklingen av Visual Studio Team Services och Team Foundation Server. Azure DevOps Server 2019 är vår första lokala version med det här nya varumärket. Mer information finns i vårt blogginlägg.

Ny navigeringsupplevelse

Vi introducerar en ny navigering för att modernisera användarupplevelsen. Den här nya navigeringen har distribuerats till Azure DevOps-tjänsten och är nu tillgänglig i Azure DevOps Server 2019. Mer information finns i vår blogg.

Ändringar i distributionspipelinelicensiering för artefakter och versionshantering

Baserat på användarfeedback gör vi två viktiga ändringar i våra licenser med Azure DevOps Server 2019. För det första behöver kunderna inte längre köpa artefakttillägget för att använda artefakter. En artefaktlicensanvändning kommer nu att ingå i den grundläggande licensen. Alla användare som har tilldelats en grundläggande licens kan nu använda artefakter. För det andra behöver kunderna inte längre köpa distributionspipelines för versionshantering. Precis som med byggpipelines, ingår nu distributionspipelines för hantering av versioner i Azure DevOps Server 2019.

Stöd för Azure SQL Database

För att förenkla upplevelsen av att köra Azure DevOps 2019 i Azure har vi aktiverat stöd för Azure SQL Database (Generell användning S3 och senare). På så sätt kan du utnyttja omfattande säkerhetskopieringsfunktioner och skalningsalternativ för att passa dina behov samtidigt som du minskar den administrativa kostnaden för att köra tjänsten. Observera att den virtuella värddatorn måste finnas i samma Azure-region som databasen för att svarstiden ska vara låg. Mer information finns i dokumentation.

Arbetsobjekt & testa SOAP-API:er för klientobjektmodell i framtida versioner

Azure DevOps Server 2019 fortsätter att stödja soap-API:et för arbetsobjektspårning och klientobjektmodellen. Den kommer dock att markeras som inaktuell i framtida versioner av Azure DevOps Server. Mer information finns i vår dokumentation.

Bearbeta arv på nya samlingar

Processarvet är nu tillgängligt för nya samlingar. Användarna måste fatta ett samvetsbeslut om processmodellen när de skapar en ny samling. Se vår dokumentation om vad arvsmodellen är och hur den skiljer sig från XML.

Utökad sökruta

Vi förstår vikten av sökning och tar tillbaka den expanderade sökrutan i produktrubriken. Dessutom kan du nu anropa sökrutan genom att bara klicka på "/" på valfri tjänstsida i Azure DevOps.

Här är standardsökrutan:

När du skriver ett "/" visas den expanderade sökrutan:

Min arbetsflyout

En ny funktion som vi är mycket glada över att presentera är panelet 'Mitt arbete'. Vi har hört feedback om att du inte vill förlora kontexten när du är i en del av produkten och vill ha information från en annan del. Med den här nya funktionen kan du komma åt den här utfällbara menyn var som helst i produkten, och den ger dig en snabb överblick över viktig information, inklusive dina arbetsobjekt, pull-begäranden och alla favoriter. Med den här nya utfällbara menyn, om du är fokuserad på din kod i Repos, men sedan snabbt vill kontrollera vilken arbetsuppgift du ska arbeta med härnäst, kan du helt enkelt klicka på den utfällbara menyn och se de arbetsuppgifter som tilldelats dig och välja nästa uppgift.

Nedan kan du se utfällningsmenyn mitt arbete som visar arbetsobjekt som tilldelats mig:

Här kan du se den andra pivoten som visar de PR:er som tilldelats mig. I den utfällbara menyn har du också en klickåtkomst för att visa fler pull-begäranden:

Här kan du se den senaste pivoten, som består av allt du har markerat som favoriter. Detta inkluderar dina favoritteam, instrumentpaneler, tavlor, kvarvarande uppgifter, frågor och lagringsplatser:

Styrelser

Länka GitHub Enterprise-incheckningar och pull-begäranden till Azure Boards-arbetsobjekt

Team som använder GitHub Enterprise för kod och vill ha omfattande projekthanteringsfunktioner kan nu integrera sina lagringsplatser med Azure Boards. Genom att du ansluter GitHub och Azure Boardskan du hämta alla funktioner som kvarvarande uppgifter, tavlor, sprintplaneringsverktyg, flera typer av arbetsobjekt och fortfarande ha ett arbetsflöde som integreras med utvecklararbetsflöden i GitHub.

Det är enkelt att länka commits och pull requests till arbetsobjekt. Nämn arbetsobjektet med hjälp av följande syntax:

AB#{work item ID}

Nämn ett arbetsobjekt i ett incheckningsmeddelande, en rubrik för pull-begäran eller en beskrivning av pull-begäran, så skapar Azure Boards en länk till artefakten. Tänk dig till exempel ett commit-meddelande som det här:

Adds support for deleting connections. Fixes AB#20.

Då skapas en länk från arbetsobjektet #20 till incheckningen i GitHub, som visas i arbetsobjektets avsnitt Utveckling. ​

Om orden "fix", "fixes" eller "fixed" föregår omnämnandet av arbetsobjektet (enligt ovan), flyttas arbetsobjektet till det slutförda tillståndet när commiten sammanfogas till huvudgrenen.

Team som använder Azure Pipelines för att skapa kod i GitHub ser också de arbetsobjekt som är länkade till deras GitHub-incheckningar i byggsammanfattningen.

Hubb för nya arbetsobjekt

Work Items Hub är vår nya hubb som fungerar som hem för dina arbetsobjekt! Här har du många olika listvyer av dina arbetsobjekt som är anpassade för dig. Du kan visa som tilldelats mig för att snabbt få en överblick över allt arbete som har tilldelats dig eller Nyligen uppdaterade som visar alla arbetsobjekt i projektet som senast har uppdaterats. Alla listalternativ visas nedan:

Om du vill begränsa listorna ytterligare kan du filtrera efter typ, tilldelad till, tillstånd, område, taggar och nyckelord. När du har önskad listvy kan du sedan sortera arbetsobjekten genom att klicka på kolumnens rubrik. Om en kolumn är för smal för att du ska kunna visa hela innehållet i kolumnen kan du enkelt ändra storlek på kolumnen i rubrikområdet. Dessa upplevelser visas nedan:

Nya styrelser, kvarvarande uppgifter och sprinthubbar

-restuppgifter-noden delades upp i tre unika noder för att förbättra användarupplevelsen. Även om den är kraftfull var den gamla Backlogs-hubben hem för många funktioner. Detta gjorde det ofta svårt att hitta den funktion eller funktion som användarna letade efter. För att lösa det här problemet har vi delat upp hubben för kvarvarande uppgifter i:

• -backloggar-hubben är nu endast dedikerad till backloggar för ett projekt. En backlog är en prioriterad arbetslista för teamet. Arbetslistor innehåller planeringsverktyg som arbetsobjektshierarki, prognostisering och ny sprintplaneringserfarenhet.
• Den nya Boards-hubben samlar alla Kanban-tavlor för ett projekt. Tavlor används för att kommunicera status och flöde. Kort (arbetsobjekt) flyttas från vänster till höger över hela linjen genom kolumner som definierats av teamet.
• Den nya Sprints hubben är hem för funktioner som används för att planera och utföra ett arbetsmoment. Varje sprint innehåller en sprint-backlog, en aktivitetstavla och en vy för att hantera teamets kapacitet.

Ny hubb för frågor

Den nya frågehubben effektiviserar många av de befintliga frågefunktionerna från den gamla hubben med ett modernare utseende och en mer modern känsla samt nya funktioner som gör det enklare att komma åt de frågor som är viktiga för dig. Några höjdpunkter i den nya upplevelsen är:

• Katalogsidor med information om vem som senast ändrade och möjlighet att söka efter sökfrågor
• Sökväg med unika URL:er för mappar som bokmärker viktiga grupper av sökfrågor
• Snabb åtkomst till dina favoritfrågor från resultatsidan

Läs mer om dessa spännande uppdateringar på vår DevOps-blogg.

Flytta arbetsobjekt till ett annat projekt och ändra en typ av arbetsobjekt

Nu kan du ändra arbetsobjekttypen eller flytta arbetsobjekt till ett annat projekt i en projektsamling. Dessa funktioner kräver att informationslagret är inaktiverat. När informationslagret är inaktiverat kan du använda Analystjänsten för att stödja dina rapporteringsbehov. Mer information om hur du inaktiverar informationslagret finns i Inaktivera informationslagret och kuben.

Funktioner för sprintplanering

De nya sprintplaneringsfunktionerna hjälper till att påskynda och förbättra sprintplaneringsupplevelsen.

• Skapa din nästa sprint eller prenumerera på ett befintligt sprintschema direkt från Sprints hubben.
• Använd den nya Planning-rutan i din backlog för att dra och släppa arbetsobjekt till framtida sprintar. Fönstret Planning innehåller sprintdatum, antal arbetsobjekt och planerad insats.
• Lägg till krav överst i Taskboard eller använd snabbskapning för att lägga till överst, längst ned eller i valfri rad i din sprint-backlog.
• Använd filter för Assignee, Work Item Type, State och Tags för att skräddarsy vyerna efter dina behov.

Nya katalogsidor

Alla nya hubbar, inklusive Backlogs, Boardsoch Sprints, har nu nya katalogsidor med följande avsnitt:

• Fortsätt där du slutade Det här nya avsnittet ger dig en snabblänk direkt till den sista (board | Kvarvarande uppgifter | Sprint) du var på.
• Favoriter Alla dina favoritkort, sprintar och kvarvarande uppgifter i alla lag.
• My Alla styrelser, kvarvarande uppgifter och sprintar för lag som du tillhör.
• Alla En fullständig lista över alla dina tavlor, kvarvarande uppgifter och sprintar.

Menyn Nya visningsalternativ

De nya hubbarna, inklusive Kvarvarande uppgifter, Boards och Sprints, har en ny Visa alternativ meny. Det här är ett nytt hem för alla åtgärder för att anpassa layout och sidinnehåll. Använd Visa alternativ för att aktivera ytterligare vyer, till exempel visa hierarki i kvarvarande uppgifter eller ändra alternativet Gruppera efter på en aktivitetstavla, aktivera sidopanelen för mappning och planering av sprintar eller utforska diagram med arbetsinformation.

Läs mer om dessa spännande uppdateringar, det nya teamprofilfönstret och Favoriter på vår DevOps-blogg.

Anteckningar på kort inkluderar buggar och anpassade typer av arbetsuppgifter

Kortanteckningar är älskade för sin intuitiva kontrolllistevy och interaktion. Tidigare var kortanteckningar begränsade till standardtyper på kvarvarande uppgifter och stödde inte buggar eller anpassade typer. Med den nya versionen har vi tagit bort begränsningen för arbetsobjekttyper och lagt till möjligheten att visa buggar och alla anpassade arbetsobjektstyper som en kortanteckning.

Tavlans inställningar för kortanteckningar har utökats till att omfatta alla typer av arbetsobjekt som är tillgängliga för den backloggnivån.

När anteckningar för arbetsobjekt är aktiverade inkluderas antalet för den typen av arbetsobjekt på kortet som en separat kontrolllista.

Snabbskapande av aktiverade typer av arbetsobjekt är också tillgängligt via kortkontextmenyn.

Flytta arbete med föreslagna områden och iterationer

Det kan vara vanligt att arbeta i samma område eller iteration och upprepade gånger bläddra igenom hierarkierna när du flyttar arbetsobjekt runt. Kontrollerna Area och Iteration sökväg innehåller nu en lista över nyligen använda värden som Förslag, vilket ger dig snabb åtkomst till att ange och gå vidare.

Dessutom ingår Iteration datum till höger om namnet så att du snabbt kan bedöma när en arbetsuppgift ska levereras.

Frågearbete i iterationsschemat med +/- @CurrentIteration

Makrot @CurrentIteration som hjälper ditt team att spåra arbete baserat på ditt iterationsschema stöder nu heltalens förskjutning. Håll enkelt koll på det arbete som inte stängdes med @CurrentIteration – 1 eller titta framåt på det arbete som planeras för framtida iterationer med @CurrentIteration + 1. Mer information finns i @CurrentIteration inlägg på Microsoft DevOps-bloggen.

Förtydliga fråge-iterationsscheman med parametern @CurrentIteration Team

Om du har använt @CurrentIteration makrot i frågor tidigare kanske du har märkt att resultaten kan variera om teamkontexten ändras i Teams med olika iterationsscheman. Nu när du skapar eller ändrar en fråga med makrot @CurrentIteration måste du också välja Team med det iterationsschema som är relevant för frågan. Med parametern Team kan du använda makrot @CurrentIteration i samma fråga men mellan team. Ett exempel kan vara en fråga för arbetsobjekt i två olika teamprojekt med olika iterationsnamn och till och med scheman. Det innebär att du inte längre behöver uppdatera frågor när sprintarna ändras! Mer information finns i @CurrentIteration inlägg på Microsoft DevOps-bloggen.

Sök arbete i områdebanor för en grupp med det nya @TeamAreas makrot

I inställningarna för ett team kan du associera en eller flera områdessökvägar, vilket hjälper dig att fokusera Backloggar, Tavlor, Planer, även Instrumentbrädor till just det teamets arbete. Om du ville skriva en fråga för ett team var du dock tvungen att lista de specifika områdessökvägarna för det teamet i frågeklasulerna. Nu finns det ett nytt @TeamAreas makro som du enkelt kan använda för att hänvisa till de områdessökvägar som är under ägande av det angivna teamet.

Fråga efter tomma RTF-fält

Hitta arbetsobjekt som har ett tomt RTF-fält, till exempel Beskrivning, med hjälp av den nya IsEmpty frågeoperator.

Hitta enkelt befintliga arbetsobjekt i länknings- och omnämnandeupplevelser

När du vill länka samman två befintliga arbetsobjekt kan du nu enkelt hitta det objekt som är viktigt för dig med hjälp av vår nya sökkontroll för arbetsobjekt. Frågeväljaren har ersatts med infogade förslag baserat på dina nyligen använda arbetsobjekt, samt en startpunkt för att söka efter ett specifikt arbetsobjekt efter ID eller rubrik.

Öppna arbetsobjekt från sökning

Tidigare gick det inte att öppna ett arbetsobjekt från sökresultatsidan om förhandsgranskningsfönstret för arbetsobjektet stängdes av. Detta skulle göra det svårt att gräva i sökresultaten. Nu kan du klicka på arbetsobjektets rubrik för att öppna arbetsobjekten i ett modalt fönster.

Repos

Förbättrad grenväljare

De flesta av funktionerna i Azure Repos kräver att du väljer en lagringsplats och sedan en gren på lagringsplatsen. För att förbättra den här upplevelsen för organisationer med ett stort antal grenar distribuerar vi en ny grenväljare. Med väljaren kan du nu välja dina favoritgrenar eller snabbt söka efter en gren.

Ta emot meddelanden när principer för pull-begärande kringgås

För team som använder pull-förfrågningar (PR) och branchpolicyerkan det finnas tillfällen då personer behöver åsidosätta och kringgå dessa policyer, till exempel när de implementerar en snabbkorrigering till ett produktionsproblem mitt i natten. Det är klokt att lita på att utvecklare gör det rätta och att använda åsidosättningsfunktionen sparsamt. Samtidigt behöver teamen ett sätt att kontrollera att dessa princip åsidosättningar används i rätt situationer. För att stödja detta har vi lagt till ett nytt meddelandefilter så att användare och team kan ta emot e-postaviseringar när en princip kringgås. Börja med En pull-begäran skapas eller uppdateras mall och välj Princip kringgå i listan med filter. Välj Principer förbigicks som värde, och du får ett meddelande varje gång en PR har slutförts och principer har förbigåtts.

Tillåt att du kringgår avdelningsprinciper utan att förlora push-skydd

Det finns många scenarier där du ibland behöver kringgå en grenprincip – återställa en ändring som orsakade en byggpaus, tillämpa en snabbkorrigering mitt i natten osv. Tidigare erbjöd vi en behörighet ("Undanta från principtillämpning") för att hjälpa team att hantera vilka användare som har beviljats möjlighet att kringgå grenprinciper när de slutför en pull-begäran. Den behörigheten möjliggjorde dock också att man kunde skicka direkt till branchen och kringgå PR-processen helt och hållet.

För att förbättra den här upplevelsen har vi delat upp den gamla behörigheten för att ge mer kontroll till team som beviljar förbikopplingsbehörigheter. Det finns två nya behörigheter för att ersätta den gamla:

1. Kringgå principer när du slutför pull-begäranden. Användare med den här behörigheten kommer att kunna använda funktionen åsidosättning för pull-begäranden.
2. Kringgå regler vid pushning. Användare med den här behörigheten kan skicka direkt till grenar som har nödvändiga principer konfigurerade.

Genom att bevilja den första behörigheten och neka den andra kan en användare använda kringgå alternativet när det behövs, men har fortfarande skyddet mot att oavsiktligt skicka till en gren med policyregler.

Mer information finns i dokumentationen Ange grenbehörigheter.

Beskriv snabbt pull-förfrågningar med hjälp av commitmeddelanden

När du skriver beskrivande incheckningsmeddelanden läggs värdet till i historiken för valfri Git-lagringsplats. För att uppmuntra kvalitetsmeddelanden i commit, kommer nya pull-begäranden (PR) som har flera commits att kräva att medarbetare anger en titel manuellt.

Beskrivningar av pull-begäranden fortsätter att vara tomma som standard, men en ny funktion gör det lättare att införliva incheckningsmeddelandena från PR-incheckningarna i PR-beskrivningen. Om du vill lägga till incheckningsmeddelanden klickar du bara på Lägg till incheckningsmeddelanden för att lägga till incheckningsmeddelandena i slutet av PR-beskrivningstexten.

Skapa pull-begäranden utan ett standardteam som granskare

När vi först introducerade pull request (PR)-upplevelsen trodde vi att det var klokt att tilldela alla PR:er till den teamkontext du hade valt när du skapade PR:n. Det här beteendet har varit en frustrationspunkt eftersom många inte märkte anslutningen mellan teamkontexten och PR-tilldelningen.

Som en del av de nya navigeringsändringarna tog vi tillfället i akt att ändra den här standardassociationen med team. Du ser två ändringar:

1. När du skapar en PR läggs inga granskare till som standard. Granskarlistan har en funktion som gör det enklare att lägga till personer och grupper som nyligen har lagts till i PR:er. Principen för obligatoriska granskare kan också vara till hjälp för team som vill säkerställa att specifika granskare inkluderas för att granska deras kod.
2. Hubben för Pull Requests har ett nytt anpassningsbart avsnitt. Som standard visar det här avsnittet PR:er "Tilldelade till mina team", som ger motsvarande funktioner som det gamla avsnittet. Men om du tillhör flera team visar det här avsnittet PR:er som tilldelats något av dina team. Avsnittet är också anpassningsbart – klicka bara på åtgärden "Anpassa den här vyn" nära avsnittsrubriken.

Standardisera beskrivningar av pull-begäranden med hjälp av mallar

Att skriva bra beskrivningar av pull-begäranden är ett bra sätt att hjälpa granskare att veta vad de kan förvänta sig när de granskar kod. De är också ett bra sätt att spåra saker som bör göras för varje ändring, till exempel testning, tillägg av enhetstester och uppdatering av dokumentation. Många av er har begärt att vi lägger till mallar för pull-begäranden för att göra det enklare för team att skriva bra beskrivningar, och vi har nu lagt till den funktionen.

Förutom att stödja en standardmall för PR-beskrivning kan team lägga till flera mallar som visas för dig i en meny på sidan skapa PR. Klicka bara på knappen Lägg till en mall för att välja från valfri mall på lagringsplatsen för att lägga till den i PR-beskrivningen.

Grenspecifika mallar stöds också om du vill använda en annan mall för en PR i en specifik gren eller grenmapp. Om du till exempel vill ha en mall som är specifik för alla grenar som börjar med "snabbkorrigering/" kan du lägga till en mall som ska användas för alla PR:er i dessa grenar.

För mer information om hur du skapar och använder mallar, se dokumentationen för mallar för pull-begäranden .

Ändra målgrenen för en pull-förfrågan

För de flesta team är nästan alla pull-begäranden inriktade på samma gren, till exempel main eller develop. Men om du behöver rikta in dig på en annan gren är det lätt att glömma att ändra målgrenen från standardvärdet. Med den nya funktionen för att ändra målgrenen för en aktiv pull-begäran är detta nu en enkel åtgärd. Klicka bara på pennikonen nära målgrenens namn i pull request-headern.

Förutom att korrigera misstag gör funktionen för att ändra målgrenar det också enkelt att "ändra riktning" på en pull request när målgrenen har sammanfogats eller tagits bort. Tänk dig ett scenario där du har en PR som riktar sig till en funktionsgren som innehåller vissa funktioner som dina ändringar är beroende av. Du vill granska dina beroende ändringar isolerat från andra ändringar i funktionsgrenen, så du börjar med att fokusera på features/new-feature. Granskare kan sedan bara se dina ändringar och lämna lämpliga kommentarer.

Tänk nu på vad som skulle hända om funktionsgrenen också hade en AKTIV PR och sammanfogades till main innan dina ändringar? Tidigare skulle du behöva överge dina ändringar och skapa en ny PR till main, eller sammanfoga din PR till features/new-featureoch sedan skapa en annan PR från features/new-feature till main. Med den här nya åtgärden för att uppdatera målgrenen kan du helt enkelt ändra målgrenen för PR från features/new-feature till mainoch bevara alla kontexter och kommentarer. Om du ändrar målgrenen skapas även en ny uppdatering av PR som gör det enkelt att se tillbaka på tidigare diff innan målgrenen ändras.

Utvecklare av tillägg kan ta reda på kontexten för det aktuella repo

En av utmaningarna för en författare av ett versionskontrolltillägg är att få kontexten för lagringsplatsen som visas för användaren, till exempel namn, ID och URL. För att hjälpa till med detta har vi lagt till VersionControlRepositoryService som en tilläggstillgänglig tjänst. Med detta kan en tilläggsförfattare fråga efter information om den aktuella Git-lagringsplatskontexten i webbgränssnittet. Den har för närvarande en metod, getCurrentGitRepository().

• Om en Git-lagringsplats har valts returneras ett GitRepository-objekt med grundläggande data om lagringsplatsen (namn, ID och URL)
• Om en TFVC-lagringsplats har valts eller om tjänsten nås utanför Azure Repos-sidorna returneras null.

Här är ett exempeltillägg som använder den här tjänsten.

Rörledningar

Hantera bygginstruktionsflöden med hjälp av den nya byggsidan

Vi gör flera förbättringar och lanserar en ny version av sidan Builds. Den här nya versionen kombinerar katalogen med alla dina byggpipelines och listan över aktuella versioner så att du snabbt kan navigera i projektets versioner för att se deras status. Den innehåller också en förhandsversion av testanalys för den valda pipelinen.

Hantera e-postmeddelanden om bygg- och distributionskomplettering bättre med förbättrad formatering

E-postmeddelanden om kompilering och distributionens slutförande har uppdaterats så att de kan filtreras enklare med hjälp av e-postregler. Nu innehåller ämnesraden mer relevant information i korthet, brödtexten innehåller mer information och deras styling har uppdaterats med det senaste varumärket.

Element i det nya formatet är:

• [Build result] [pipeline name] - [repository:branch] - [project name] - [commit]
• [Deployment result] [pipeline name] > [release name] : [stage name]

Här är några exempel:

• [Build succeeded] IdentityService.CI - MyRepo:main - MyProject - d3b90b80
• [Deployment succeeded] New release pipeline > NotificationSpecialRelease-1 : Stage 1

Följ den nya enhetliga Azure Pipelines-terminologin

Under olika byggen och versioner har olika termer historiskt använts för liknande begrepp. I andra fall var innebörden av termer vag. Du kan till exempel se skillnaden mellan en agentpool och en agentkö.

Terminologin har enhetligts i Azure Pipelines för att förtydliga dess begrepp. Nu visas följande enhetliga termer:

Mer information finns i dokumentationen Concepts.

Hantera utgivningspipelines med hjälp av sidan för nya utgåvor

En ny och helt omdesignad användarupplevelse finns tillgänglig för lanseringslandningssidan. Se en lista till vänster över de versionspipelines som du släpper ofta. Du kan också söka i dina pipelines och favoritmarkera dem.

Ändra till mappvyn för att skapa mappar för organisation och säkerhet. Säkerhet kan ställas in på mappnivå.

Visualisera versionsframstatus

Den nya versionsförloppsvyn ger dig liveuppdateringar av distributionsförloppet och åtkomst med ett klick för ytterligare information. Den nya vyn visualiserar versionspipelinen, vilket gör det lättare att förstå vad som händer och visar lämplig information och åtgärder i olika skeden av versionen.

Pipeline, versionsinformation och miljöer

Vyn Pipeline visar artefakterna för släppet och de miljöer där de kommer att distribueras. Området Release innehåller versionsinformation som versionsutlösare, artefaktversioner och taggar.

Miljöer modelleras på ett sätt som hjälper dig att förstå deras status, tillsammans med detaljerade framsteg. När som helst kan du komma till loggarna genom att klicka på statuslänken i miljön.

Före distribution och efter distribution

Om villkor före eller efter distribution har ställts in för en miljö, framgår det i miljön genom närvaro av godkännanden och portar. Förloppet för godkännanden och portar visas även i miljöns status. Du kan vidta åtgärder eller visa ytterligare information genom att klicka på miljöns villkorsikon som hänger till höger eller vänster i miljön.

Incheckningar och arbetsobjekt

Med varje ny version kan du se listan över associerade incheckningar och arbetsobjekt för varje miljö separat genom att klicka på miljön. Om listan är lång kan du använda filter för att hitta en incheckning eller ett arbetsobjekt som du är intresserad av.

Distributionsframsteg och loggar

Miljöerna visar liveuppdateringar för pågående distributioner, inklusive hur många faser och uppgifter som är slutförda och körtiden. När du klickar på miljöstatusen öppnas en vy som innehåller loggarna, med fokus på det som för närvarande är aktivt.

Du kan klicka in i loggarna för att öppna en fokuserad vy.

Inverkan av uppgradering till Azure DevOps Server 2019 på uppgifter: Windows Machine File Copy och PoweShell på måldatorn

Datorgrupper under Test Hub blev avvecklade i TFS 2017 RTM. Med Azure DevOps Server 2019 är tjänsten Datorgrupper inte längre tillgänglig. Detta påverkar användarna av "Windows Machine File Copy"-uppgift version 1.* och "PowerShell på måldatorer"-uppgift version 1.*. För att dina pipelines ska fortsätta att fungera,

• Du måste växla till aktivitetsversionen 2.* för Windows Machine File Copy och ange den fullständiga fqdn för måldatorn i stället för bara datornamnet.
• Växla till aktivitetsversion 2.* eller senare av 'Powershell på måldator' och ange det fullständiga fullständiga domännamnet (FQDN) för datorn eller datornamnet följt av Windows fjärrhanteringsportar (http/https). Till exempel targetMachine:5985 eller targetMachine:5986

Testresultat och utökningsbarhet

Resultaten från testkörningen visas också för varje miljö. Om du klickar på testresultaten öppnas en vy som innehåller testinformation, inklusive resultat från andra tillägg som bidrar till processen.

Befintliga tillägg fungerar i den här nya vyn, plus att det finns nya utökningspunkter som gör att tillägg utvecklas för att visa ännu mer information för en miljö. Se dokumentationen för bidrag och tillägg för mer information.

Konfigurera byggen med YAML

YAML-baserade byggpipelines är tillgängliga i din Azure DevOps Server. Automatisera pipelinen för kontinuerlig integrering med hjälp av en YAML-fil som är incheckad i ditt arkiv. En fullständig referens för YAML-schemat finns här.

För att stödja YAML-baserade byggpipelines på ett smidigare sätt har vi ändrat standardbeteendet för alla nya resurser som du skapar (t.ex. tjänstanslutningar, variabelgrupper, agentpooler och säkra filer) så att de kan användas i hela pipelinen för projektet. Om du vill ha strängare kontroll över dina resurser kan du inaktivera standardauktoriseringsmodellen (se bilden nedan). När du gör det måste någon med behörighet att använda resursen uttryckligen spara pipelinen i webbredigeraren när en resursreferens har lagts till i YAML-filen.

Koppla samman relaterade byggen med hjälp av utlösare vid avslutat bygge

Stora produkter har flera komponenter som är beroende av varandra. Dessa komponenter är ofta fristående byggda. När en överordnad komponent (till exempel ett bibliotek) ändras måste underordnade beroenden återskapas och återkallas. Team hanterar vanligtvis dessa beroenden manuellt.

Nu kan du utlösa en build vid framgångsrikt slutförande av en annan build. Artefakter som skapas av en uppströmsversion kan laddas ned och användas i den senare versionen, och du kan också hämta data från dessa variabler: Build.TriggeredBy.BuildId, Build.TriggeredBy.DefinitionId, Build.TriggeredBy.BuildDefinitionName. Mer information finns i dokumentationen om build-utlösare.

Tänk på att i vissa fall kan en enda flerfasversion uppfylla dina behov. En utlösare för byggslut är dock användbar om dina krav omfattar olika konfigurationsinställningar, alternativ eller ett annat team som ansvarar för den beroende processen.

Uppdatera din agent lokalt

Uppgifter som du installerar från galleriet kräver ibland en nyare version av pipelines-agenten. Om din Azure DevOps Server kan ansluta till Internet laddas nyare versioner ned automatiskt. Annars måste du uppgradera varje agent manuellt. Från och med den här versionen kan du konfigurera Azure DevOps Server så att den söker efter agentpaketfilerna på den lokala disken i stället för från Internet. Detta ger dig både flexibilitet och kontroll över vilka agentversioner du gör tillgängliga, utan att du behöver exponera Din Azure DevOps Server för Internet.

Url för statusikon för ny version

Skapa märken som är inbäddade på startsidan för en lagringsplats är ett vanligt sätt att visa lagringsplatsens hälsotillstånd. Även om vi hade byggmärken hittills fanns det några problem:

• URL:en var inte intuitiv
• Märket var inte specifikt för en gren
• Det fanns inget sätt för en användare att klicka på märket för att ta användaren till den senaste versionen av den definitionen

Nu lanseras ett nytt API för byggmärken som löser dessa problem. Det nya API:et gör det möjligt för användare att publicera status per gren och kan ta användarna till den senaste versionen av den valda grenen. Du kan hämta Markdown för den nya statusikonens URL genom att välja statusikonen menyåtgärd i nya Builds-sidan.

För bakåtkompatibilitet fortsätter vi även att respektera de äldre url:erna för byggmärket.

Lägg till anpassade versionsräknare till dina kompileringar

Räkneverk för byggen ger ett sätt att unikt numrera och märka byggen. Tidigare kunde du använda specialvariabeln $(rev:r) för att åstadkomma detta. Nu kan du definiera dina egna räknarvariabler i byggdefinitionen som ökas automatiskt varje gång du kör en version. Det gör du på fliken variabler i en definition. Den här nya funktionen ger dig mer kraft på följande sätt:

• Du kan definiera en anpassad räknare och ange dess startvärde. Du kan till exempel starta räknaren på 100. $(rev:r) börjar alltid vid 0.
• Du kan använda din egen anpassade logik för att återställa en räknare. $(rev:r) är kopplat till versionsnummergenerering och återställs automatiskt när det finns ett nytt prefix i versionsnumret.
• Du kan definiera flera räknare per definition.
• Du kan fråga efter värdet för en räknare utanför en kompilering. Du kan till exempel räkna antalet versioner som har körts sedan den senaste återställningen med hjälp av en räknare.

Mer information om byggräknare finns i dokumentationen om användardefinierade variabler.

Azure Policy-efterlevnad och säkerhetsverifieringar i Pipelines

Vi vill säkerställa stabilitet och säkerhet för programvara tidigt i utvecklingsprocessen samtidigt som vi samlar utveckling, säkerhet och drift. För att göra det har vi lagt till stöd för Azure Policy.

Med Azure Policy kan du hantera och förebygga IT-problem med principdefinitioner som framtvingar regler och effekter för dina resurser. När du använder Azure Policy följer resurserna företagets standarder och serviceavtal.

För att följa efterlevnads- och säkerhetsriktlinjerna som en del av lanseringsprocessen har vi förbättrat vår distributionsupplevelse för Azure-resursgrupper. Nu misslyckas distributionsuppgiften för Azure-resursgruppen med relevanta principrelaterade fel i händelse av överträdelser vid distribution av ARM-mallar.

Dessutom har vi lagt till en definitionsmall för Azure Policy Release. På så sätt kan användare skapa Azure-principer och tilldela dessa principer till resurser, prenumerationer eller hanteringsgrupper från själva versionsdefinitionen.

Utveckla på Linux/ARM-plattformar och Windows 32-bitarsplattformar

Azure Pipelines öppen källkod, plattformsoberoende agent har alltid stöd för 64-bitars (x64) Windows, macOS och Linux. Med den här versionen introducerar vi två nya plattformar som stöds: Linux/ARM och Windows/32-bitars. Dessa nya plattformar ger dig möjlighet att bygga vidare på mindre vanliga, men inte mindre viktiga, plattformar som Raspberry Pi, en Linux/ARM-dator.

Förbättrade upplevelser för tester i pipelines

fliken Tester nu har en modern upplevelse som ger dig omfattande, kontextbaserad testinformation för Pipelines. Den nya upplevelsen ger en testvy under pågående tester, en fullständig upplevelse av sidfelsökning, testhistorik i sitt sammanhang, rapportering av avbrutna testkörningar och sammanfattning på körningsnivå.

Visa exekvering av pågående tester

Tester, till exempel integrerings- och funktionstester, kan köras under lång tid, så det är viktigt att se testkörning vid en viss tidpunkt. Med testvyn Pågår behöver du inte längre vänta tills testkörningen har slutförts för att få veta testresultatet. Resultaten är tillgängliga nästan i realtid när de körs, vilket hjälper dig att vidta åtgärder snabbare. Du kan felsöka ett fel eller avbryta processen, rapportera en bugg eller avbryta pipelinen. Funktionen är för närvarande tillgänglig för både bygg- och versionspipeline med VS Test Task i multiagentfasen, med hjälp av Publish Test Results Task eller genom att publicera testresultat med API:er. I framtiden planerar vi att utöka denna upplevelse av testkörning med hjälp av en enda agent.

Vyn nedan visar sammanfattningen av pågående tester i den nya vyn för versionens framsteg, vilken rapporterar det totala antalet tester och antalet testfel vid en given tidpunkt.

Genom att klicka på In-Progress Testsammanfattning ovan kan du visa den detaljerade testsammanfattningen och information om misslyckade eller avbrutna tester i Testplaner. Testsammanfattningen uppdateras regelbundet med möjlighet att uppdatera detaljvyn på begäran, baserat på tillgängligheten för nya resultat.

Visa felsökningsinformation för testkörning på hela sidan

Felmeddelanden och stackspårningar är långa till sin natur och behöver tillräckligt med utrymme för att visa detaljerna under felsökning. Om du vill ha en avancerad felsökningsupplevelse kan du nu expandera test- eller testkörningsvyn till helsidesvyn, samtidigt som du kan utföra de åtgärder som krävs i kontextåtgärder som att skapa buggar eller kravassociation för det aktuella testresultatet.

Visa testhistorik i kontext

Tidigare skulle team behöva gå till Runs Hub för att visa historiken för ett testresultat. Med den nya upplevelsen tar vi testhistoriken i rätt kontext i Testplaner-fliken för bygg och publicering. Informationen om testhistoriken tillhandahålls progressivt och börjar med den aktuella versionsdefinitionen eller miljön för det valda testet, följt av andra grenar och miljöer för byggandet respektive utgåvan.

Visa avbrutna tester

Testkörningen kan avbrytas på grund av flera orsaker, till exempel felaktig testkod, källa under test och miljöproblem. Oavsett orsaken till avbrottet är det viktigt att du diagnostiserar beteendet och identifierar grundorsaken. Nu kan du visa de avbrutna testerna och testkörningarna, tillsammans med slutförda körningar i testplaner. Funktionen är för närvarande tillgänglig för både bygg- och versionspipeline med VS-testuppgift i multiagentfasen eller för publicering av testresultat med hjälp av API:er. I framtiden planerar vi att utöka denna upplevelse av testkörning med hjälp av en enda agent.

Stöd för testspårnings- och versionsmiljöer i Testhistorik

Vi lägger till stöd för att visa historiken för ett automatiserat test grupperat efter olika versionsmiljöer där testet körs. Om du skapar modeller av versionsmiljöer som versionspipelines eller testmiljöer och kör tester i sådana miljöer kan du ta reda på om ett test klarar sig i utvecklingsmiljön men misslyckas i integrationsmiljön. Du kan ta reda på om det klarar i den engelska lokaliseringen men misslyckas i en miljö som har turkisk lokalisering. För varje miljö hittar du statusen för det senaste testresultatet, och om testet har misslyckats i den miljön hittar du även den version som testet har misslyckats med.

Granska sammanfattade testresultat

Under testutförande kan ett test skapa flera testinstanser som bidrar till det övergripande resultatet. Några exempel är: tester som körs på nytt på grund av fel, tester som består av en ordnad kombination av andra tester (t.ex. beställt test) eller tester som har olika instanser baserat på angiven indataparameter (datadrivna tester). Eftersom dessa tester är relaterade måste de rapporteras tillsammans med det övergripande utfallet baserat på de enskilda testresultaten. Med den här uppdateringen introducerar vi en förbättrad version av testresultat som presenteras som en hierarki på fliken Tester i en version. Nu ska vi titta på ett exempel.

Tidigare introducerade vi möjligheten att köra misslyckade tester igen i uppgiften VS Test. Vi rapporterade dock bara om det sista försöket av ett test, vilket något begränsade användbarheten för den här funktionen. Vi har nu utökat den här funktionen för att rapportera varje instans av testkörningen som ett försök. Dessutom stöder testhanterings-API:et nu möjligheten att publicera och köra frågor mot hierarkiska testresultat. Mer information finns i dokumentationen för testresultat-API:et .

Visa testanalyser i Pipelines

Att spåra testkvalitet över tid och förbättra testmaterial är nyckeln till att upprätthålla en hälsosam pipeline. Testanalysfunktionen ger nästan realtidssynlighet i dina testdata för byggen och versionspipelines. Det hjälper till att förbättra effektiviteten i din pipeline genom att identifiera repetitiva kvalitetsproblem med hög påverkan.

Du kan gruppera testresultat efter olika element, identifiera viktiga tester för din gren eller dina testfiler eller öka detaljnivån för ett specifikt test för att visa trender och förstå kvalitetsproblem som flingor.

Visa testanalys för builds och versionförhandsgranskning nedan:

Mer information finns i vår dokumentation.

Förenkla definitioner med flera agentlösa uppgifter

Uppgifter i en agentlös fas orkestreras av och körs på servern. Agentlösa faser kräver inte någon agent eller måldatorer. Till skillnad från agentfaser kunde endast en uppgift läggas till i varje agentlös fas i definitionerna. Detta innebar att flera faser måste läggas till när det fanns mer än en agentlös uppgift i processen, vilket gjorde definitionen skrymmande. Vi har lättat på den här begränsningen, som gör att du kan underhålla flera uppgifter i en agentlös fas. Uppgifterna i samma fas skulle utföras sekventiellt, precis som de gör för agentfaser. För mer information, se dokumentationen för -serverfaser.

Gradvis avslöja och fasa distributioner med hjälp av releaseregler

Med hjälp av versionsgrindar kan du ange kriterier för programmets hälsotillstånd som måste uppfyllas innan en version flyttas upp till nästa miljö. Alla angivna portar utvärderas regelbundet före eller efter varje distribution, tills de alla har lyckats. Fyra typer av portar är tillgängliga direkt och du kan lägga till fler portar från Marketplace-. Du kommer att kunna granska att alla nödvändiga kriterier för en distribution har uppfyllts. Mer information finns i dokumentationen för versionsgrindar under.

Håll utplaceringar tills grindarnas framgång är konsekvent

Frisläppningsgrindar möjliggör automatisk utvärdering av hälsokriterier innan en version flyttas till nästa miljö. Som standard fortsätter släppet efter att ett lyckat prov för alla gränssnitt har tagits emot. Även om en grind är oberäknelig och det lyckade provet som tas emot är brus, fortskrider lanseringen. För att undvika den här typen av problem kan du nu konfigurera releasen så att den verifierar konsistensen i hälsotillståndet under en minimal tidsperiod innan du går vidare. Under körning säkerställer utgåvan att efterföljande utvärderingar av grindarna lyckas innan godkännande tillåts. Den totala tiden för utvärdering beror på "tid mellan omvärdering" och är vanligtvis mer än den konfigurerade minsta varaktigheten. Mer information finns i dokumentationen för distributionskontrollen för Release med hjälp av grindar.

Distribuera automatiskt till nya mål i en distributionsgrupp

Tidigare, när nya mål lades till i en distributionsgrupp, krävdes en manuell distribution för att säkerställa att alla mål har samma version. Nu kan du konfigurera miljön för att automatiskt distribuera den senaste lyckade versionen till de nya målen. För mer information, se dokumentationen om distributionsgrupper.

Distribuera byggen som taggats efter byggbearbetningen kontinuerligt

Kontinuerliga deploymentsutlösare skapar en release vid byggets färdigställande. Men ibland efterbearbetas byggen, och bygget bör endast släppas när denna bearbetning har slutförts. Nu kan du utnyttja byggtaggar, som kan tilldelas under efterbearbetningen, i utlösarfilter i releasen.

Ange en variabel vid lanseringstillfället

I en versionsdefinition kan du nu välja de variabler som du vill ange när du skapar versionen.

Värdet som anges för variabeln när versionen skapas används endast för den versionen. Den här funktionen hjälper dig att undvika flera steg för Create-in-Draft, uppdatera variablerna i utkast och utlösa versionen med variabeln.

Skicka miljövariabler till processer

CI/CD-aktivitetsförfattare kan ange en ny egenskap, showEnvironmentVariables, i task.json för att skicka miljövariabler till aktiviteter. När du gör det läggs en extra kontroll till på aktiviteten i versionsredigeraren. Detta är tillgängligt för powershell-, cmd- och Bash-uppgifter .

Detta möjliggör två scenarier:

• En uppgift kräver en miljövariabel med skiftlägesbevarande i variabelnamnet. I exemplet ovan skulle till exempel miljövariabeln som skickas till uppgiften vara "foo" och inte "FOO".
• Det gör att hemligheter kan skickas på ett säkert sätt till skripten. Detta är att föredra framför att skicka hemligheterna som argument till skripten eftersom operativsystemet på agenten kan logga anrop av processer och inkludera deras argument.

Klona variabelgrupper

Vi har lagt till stöd för kloning av variabelgrupper. När du vill replikera en variabelgrupp och bara uppdatera några av variablerna behöver du inte gå igenom den omständliga processen att lägga till variabler en i taget. Nu kan du snabbt göra en kopia av variabelgruppen, uppdatera värdena på rätt sätt och spara dem som en ny variabelgrupp.

Ignorera en versionsgrind för en distribution

Frisläppningsgrindar möjliggör automatisk utvärdering av hälsokriterier innan en version flyttas till nästa miljö. Som standardinställning fortsätter release-pipelinen endast när alla portar är i ordning samtidigt. I vissa situationer, till exempel när en version påskyndas eller efter manuell kontroll av status, kan en godkännare vilja ignorera en grind och tillåta att versionen fortsätter även om grinden ännu inte har utvärderats som godkänd. Dokumentation om releasegrindar för mer information.

Utför ytterligare testning med hjälp av en pull request-utlösare

Du har kunnat utlösa en build baserat på en pull request (PR) och få snabb feedback innan sammanslagningen under en längre tid. Nu kan du även konfigurera en PR-utlösare för en release. Status för versionen publiceras tillbaka till kodlagringsplatsen och kan visas direkt på PR-sidan. Det här är användbart om du vill utföra ytterligare funktionell eller manuell testning som en del av ditt PR-arbetsflöde.

Skapa Azure-tjänstanslutning med ett huvudnamn för tjänsten som autentiserar med ett certifikat

Nu kan du definiera en Azure-tjänstanslutning med tjänstens huvudnamn och certifikat för autentisering. Nu när Azure-tjänstanslutningen stöder en tjänstens huvudnamn som använder ett certifikat för autentisering, kan du nu distribuera till Azure Stack som är konfigurerat med AD FS. Om du vill skapa ett tjänsthuvudnamn med certifikatautentisering läser du artikeln om hur du skapar ett huvudnamn för tjänsten som autentiserar med ett certifikat.

Kör från en paketfil stöds i Azure App Service-distributioner

Azure App Service Deploy-aktiviteten (4.*) stöder nu RunFromPackage (kallades tidigare RunFromZip.

App Service har stöd för ett antal olika tekniker för att distribuera dina filer, till exempel msdeploy (även kallat WebDeploy), git, ARM med mera. Men alla dessa tekniker har en begränsning. Filerna distribueras i mappen wwwroot (specifikt d:\home\site\wwwroot) och körtiden kör sedan filerna därifrån.

Med Kör från-paketet finns det inte längre ett distributionssteg som kopierar de enskilda filerna till wwwroot. I stället pekar du bara på en zip-fil, och zip-filen monteras på wwwroot som ett skrivskyddat filsystem. Detta har flera fördelar:

• Minskar risken för problem med filkopieringslåsning.
• Kan distribueras till en produktionsapplikation (med omstart).
• Du kan vara säker på vilka filer som körs i din app.
• Förbättrar prestandan för Azure App Service-distributioner.
• Kan minska kalla starttider, särskilt för JavaScript-funktioner med stora npm-paketträd.

Distribuera Linux-kontainrar med appserverdistribution-uppgiften

4.*-versionen av Azure App Service Deploy-uppgiften stöder nu distribution av din egen anpassade container till Linux-baserade Azure Functions.

Linux-värdmodellen för Azure Functions baseras på Docker-containrar som ger större flexibilitet när det gäller paketering och användning av appspecifika beroenden. Funktioner i Linux kan finnas i två olika lägen:

1. Inbyggd containerbild: Du tar med koden för Funktionsappen och Azure tillhandahåller och hanterar containern (inbyggt bildläge), så ingen specifik Docker-relaterad kunskap krävs. Detta stöds i den befintliga versionen av App Service Deploy-uppgiften.
2. Anpassad containeravbildning: Vi har förbättrat App Service-implementeringsuppgiften för att stödja distribution av anpassade containeravbildningar till Azure Functions på Linux. När dina funktioner behöver en specifik språkversion eller kräver ett specifikt beroende eller en konfiguration som inte tillhandahålls i den inbyggda avbildningen kan du skapa och distribuera en anpassad avbildning till Azure Function i Linux med hjälp av Azure Pipelines.

Xcode-uppgiften stöder det nyligen släppta Xcode 10

Med Apples version av Xcode 10 kan du nu ställa in dina projekt för att skapa eller testas specifikt med Xcode 10. Din pipeline kan också köra jobb parallellt med en matris av Xcode-versioner. Du kan använda den Microsoft-värdbaserade macOS-agentpoolen för att köra dessa byggen. Se vägledning för att använda Xcode i Azure Pipelines.

Effektivisera distributionen till Kubernetes med Helm

Helm är ett verktyg som effektiviserar installationen och hanteringen av Kubernetes-program. Det har också fått mycket popularitet och samhällsstöd under det senaste året. En Helm-uppgift i Release är nu tillgänglig för att paketera och distribuera Helm-diagram till Azure Container Service (AKS) eller något annat Kubernetes-kluster.

Med hjälp av den här Helm-uppgiften kan du nu konfigurera en Helm-baserad CI/CD-pipeline för att leverera containrar till ett Kubernetes-kluster. Mer information finns i dokumentationen Distribuera med Kubernetes till Azure Container Service.

Kontrollera Helm-versionen som används i utgåvan

Uppgiften Helm Tool Installer hämtar en specifik version av Helm från Internet eller verktygscachen och lägger till den i PATH för agenten (värdbaserad eller privat). Använd den här uppgiften om du vill ändra den version av Helm som används i efterföljande uppgifter, till exempel .NET Core cli- uppgift. Genom att lägga till den här uppgiften före Helm Deploy uppgift i en bygg- eller versionsdefinition ser du till att du paketerar och distribuerar din app med rätt Helm-version. Den här uppgiften hjälper även till att installera verktyget kubectl, vilket är en förutsättning för att Helm ska kunna fungera.

Kontinuerlig distribution till Azure Database för MySQL

Nu kan du kontinuerligt distribuera till Azure Database for MySQL – Azures MySQL-databas som en tjänst. Hantera dina MySQL-skriptfiler i versionskontroll och distribuera kontinuerligt som en del av en versionspipeline med hjälp av en intern uppgift i stället för PowerShell-skript.

Använd förbättrade Windows-fjärrskrivbordsuppgifter baserade på PowerShell

Nya och förbättrade Windows-fjärrstyrningsuppgifter baserade på PowerShell är tillgängliga. Dessa förbättringar omfattar flera prestandakorrigeringar och stöd för liveloggar och konsolutdatakommandon, till exempel Write-Host och Write-Output.

PowerShell på måluppgift (version: 3.*): Du kan lägga till inbäddat skript, ändra PSSession-alternativ, kontrollera "ErrorActionPreference", och misslyckas vid standardfel.

Azure File Copy-uppgift (version: 2.*): Levereras med den senaste AzCopy (v7.1.0) som åtgärdar ett GitHub-problem.

Filtrera grenar för GitHub Enterprise eller externa Git-artefakter

När du släpper från GitHub Enterprise eller externa Git-lagringsplatser kan du nu konfigurera de specifika grenar som ska släppas. Du kanske till exempel bara vill distribuera versioner som kommer från en specifik gren till produktion.

Skapa program som skrivits i Go

Använd Go Tool Installer uppgift för att installera en eller flera versioner av Go Tool i farten. Den här uppgiften hämtar en specifik version av Go Tool som krävs av projektet och lägger till den i PATH för byggagenten. Om go-verktygets målversion redan är installerad på agenten hoppar den här uppgiften över processen att ladda ned och installera den igen.

Uppgiften Go hjälper dig att ladda ned beroenden, skapa eller testa ditt program. Du kan också använda den här uppgiften för att köra ett anpassat Go-kommando.

Kör infogade eller filbaserade Python-skript i din pipeline

En ny Python Script-uppgift förenklar körningen av Python-skript i din pipeline. Uppgiften kör ett skript från en Python-fil (.py) i ditt arkiv, eller så kan du manuellt ange ett skript i uppgiftens inställningar för att spara som en del av din pipeline. Uppgiften använder versionen av Python i sökvägen, eller så kan du ange en absolut sökväg till en Python-tolk som ska användas.

Utnyttja förbättrad Xcode-version och testutdata från xcpretty

xcpretty förbättrar läsbarheten för xcodebuild-utdata och genererar testresultat i JUnit-format. Xcode-byggaktiviteten använder nu automatiskt xcpretty när den är tillgänglig på agentdatorn, eftersom den finns på värdbaserade macOS-agenter. Även om xcpretty-utdata kan vara olika och mindre utförliga än xcodebuild-utdata, gör vi de fullständiga xcodebuild-loggarna tillgängliga för varje version.

Testplaner

Test Runner-klienten (Azure Test Plans) för att köra manuella tester för skrivbordsprogram

Nu kan du använda Test Runner-klienten (Azure Test Plans) för att köra manuella tester för skrivbordsprogram. Detta hjälper dig att flytta från Microsoft Test Manager till Azure Test Plans. Se vår vägledning här. Med Test Runner-klienten kan du köra dina manuella tester och registrera testresultaten för varje teststeg. Du har också funktioner för datainsamling, till exempel skärmbild, bildåtgärdslogg och ljudvideoinspelning. Om du upptäcker ett problem när du testar använder du Test Runner för att skapa en bugg med teststeg, skärmbilder och kommentarer som automatiskt ingår i buggen.

Test Runner (Azure Test Plans) kräver en engångsnedladdning och installation av löparen. Välj Kör för skrivbordsprogram enligt nedan.

Artefakter

Överordnade källor

Azure DevOps Server 2019 ger omfattande uppdateringar av de överordnade källorna som är tillgängliga i dina Azure Artifacts-feeds:

• Du kan lägga till nuget.org uppströmskällor till befintliga flöden som skapats i tidigare TFS-versioner. Leta efter banderollen ovanför feedens paket för mer information, inklusive beteendeändringar som du bör känna till innan du uppgraderar.
• Du kan lägga till andra Azure DevOps Server-feeds som överordnade källor i flödet, vilket innebär att du kan använda NuGet- och npm-paket från dessa feeds via ditt flöde.

Vi har också introducerat en ny roll i Azure Artifacts: "Kollaboratör". En medarbetare kan spara paket från en uppströmskälla, men kan inte publicera paket direkt i flödet (t.ex. genom att använda nuget publish). På så sätt kan du begränsa paketpublicering till en betrodd användare eller byggsystemet samtidigt som dina tekniker kan använda nya paket från dina överordnade källor.

Följ paketet

Vi har gjort det ännu lättare att konfigurera meddelanden med den nya Följ-knappen direkt i varje paket. Knappen Följ är också kompatibel med versionsvyer. Om du följer ett paket genom en vy får du bara uppdateringar för nya versioner som har uppgraderats till den vyn.

Ändra feedinställningar utan att behöva spara manuellt

Några av interaktionerna på sidan för flödesinställningar har förbättrats. Nu sparas ändringar som du gör, till exempel att lägga till en överordnad eller en behörighet, omedelbart. Det innebär att du inte behöver oroa dig för att förlora ändringar när du växlar mellan inställnings pivoter.

Förenkla autentiseringen med den nya leverantören för autentiseringsuppgifter för NuGet för plattformsoberoende användning

Att interagera med autentiserade NuGet-feeds blev bara mycket bättre. Den nya .NET Core-baserade Azure Artifacts Credential Provider fungerar med msbuild, dotnet och nuget(.exe) i Windows, macOS och Linux. Varje gång du vill använda paket från en Azure Artifacts-feed hämtar och lagrar autentiseringsprovidern automatiskt en token åt den NuGet-klient som du använder. Du behöver inte längre lagra och hantera en token manuellt i en konfigurationsfil.

Om du vill hämta den nya providern går du till GitHub- och följer anvisningarna för din klient och plattform.

Komprimera symboler när du publicerar till en fildelning

Vi har uppdaterat uppgiften Index & Publicera symboler för att stödja kompression av symboler när de delas till en fildelning.

Wiki

Publicera markdown-filer från en Git-lagringsplats som en Wiki

Utvecklare skapar dokumentation för "API:er", "SDK:er" och "hjälpdokument som förklarar kod" i kodlagringsplatser. Läsarna måste sedan söka igenom kod för att hitta rätt dokumentation. Nu kan du helt enkelt publicera markdown-filer från kodlagringsplatser och vara värd för dem i Wiki.

Från Wiki börjar du med att klicka på Publicera kod som wiki-. Sedan kan du ange en mapp på en Git-lagringsplats som ska höjas upp.

När du klickar på Publicerapubliceras alla markdown-filer under den valda mappen som en wiki. Detta mappar även chefen för grenen till wikin så att alla ändringar du gör i Git-lagringsplatsen återspeglas omedelbart.

Mer information finns i blogginlägget om produktdokumentation ,.

Länka till rubriker på en sida

Nu kan du klicka på länkikonen bredvid valfri avsnittsrubrik på en wiki-sida för att generera en URL direkt till det avsnittet. Du kan sedan kopiera webbadressen och dela den med gruppmedlemmar för att länka dem direkt till det avsnittet.

Bifoga filer och bilder i mappar

När du redigerar wiki-sidor offline kan det vara enklare att lägga till bifogade filer och bilder i samma katalog som wiki-sidan. Nu kan du lägga till en bifogad fil eller en bild i valfri mapp i wikin och länka den till din sida.

Bädda in en video i wiki

Nu kan du bädda in videor på en wiki-sida från onlinetjänster som Microsoft Stream och YouTube. Du kan lägga till den inbäddade video-URL:en med hjälp av följande syntax:

::: video
<iframe width="560" height="315" src="https://www.youtube.com/embed/7DbslbKsQSk" frameborder="0" allow="autoplay; encrypted-media" allowfullscreen></iframe>
:::

Byta namn på en wiki

Nu kan du byta namn på wikin i wiki-användargränssnittet och med hjälp av REST-API:er. På menyn Mer klickar du på Byt namn på wiki för att ge wikin ett minnesvärt namn.

Öppna sidan på ny flik

Nu kan du högerklicka på en wiki-sida och öppna den på ny flik eller helt enkelt trycka på CTRL + vänster klicka på en wiki-sida för att öppna den på en ny flik.

Behålla specialtecken i Wiki-sidrubriker

Nu kan du skapa wiki-sidor med specialtecken som : < > * ? | -. Nu sidor med titlar som "Vanliga frågor och svar?" eller "Konfigurationsguide" kan skapas i Wiki. Följande tecken översätts till utf-8-kodade strängar:

Visa brutna länkar

Alla länkar i en wiki som inte är korrekt länkade visas i en distinkt röd färg och en bruten länkikon, vilket ger dig en visuell ledtråd om alla brutna länkar på en wiki-sida.

Åtgärda brutna länkar när sidor flyttas

Brutna sidlänkar är en av de främsta orsakerna till dålig sidkvalitet i alla dokumentationslösningar. Tidigare i Wiki, när du flyttade en sida i trädstrukturen eller bytte namn på en sida, kunde den potentiellt bryta länkar till sidan från andra sidor och arbetsuppgifter. Nu kan du söka efter och åtgärda länkar innan de bryts.

När du byter namn på eller flyttar en sida uppmanas du att söka efter berörda absoluta eller relativa länkar.

Sedan visas en lista över länkarna till sidorna och arbetsobjekten som påverkas innan du vidtar åtgärder.

Skapa innehållsförteckning för wiki-sidor

Ibland kan wiki-sidor bli långa, med innehåll indelat i flera rubriker. Nu kan du lägga till en innehållsförteckning på en sida som har minst en rubrik med hjälp av [[_TOC_]] syntax.

Du kan också infoga innehållsförteckningen genom att klicka på lämplig knapp i formatfönstret när du redigerar sidan.

Mer information om hur du använder markdown i Azure DevOps finns i markdown-vägledningen dokumentationen.

Surface-metadata för wiki-sidor och förhandsgranskning av kod med YAML-taggar

Att lägga till metadata i dokumentationen kan hjälpa läsare och sökindex att hämta och visa meningsfullt innehåll. I den här uppdateringen omvandlas alla filer som innehåller ett YAML-block i början av filen till en metadatatabell med ett huvud och en rad. YAML-blocket måste ha formen av giltig YAML-uppsättning mellan trestreckade linjer. Den stöder alla grundläggande datatyper, listor, objekt som värde. Syntaxen stöds i Wiki och förhandsgranskning av kodfil.

EXEMPEL på YAML-taggar:

---
tag: post
title: Hello world
---

EXEMPEL på YAML-taggar med lista:

---
tags:
- post
- code
- web
title: Hello world
---

Publicera kod som wiki med bidragsbehörighet

Tidigare kunde endast användare som har behörigheten Skapa lagringsplats på en git-lagringsplats publicera kod som wiki. Detta gjorde lagringsplatsens administratörer eller skapare till en flaskhals för alla begäranden om att publicera markdown-filer som finns i git-lagringsplatser som wikis. Nu kan du Publicera kod som wiki- om du bara har Contribute-behörighet på kodlagringsplatsen.

Rapportering

Analytics Marketplace-tillägget för rapportering är nu tillgängligt

Analytics Marketplace-tillägget är nu tillgängligt för Azure DevOps Server. Analys är framtidens rapportering för Azure DevOps och Azure DevOps Server. Om du installerar Analytics-tillägget får du avancerade widgetar, Power BI-integreringoch OData-åtkomst.

För mer information, se "What is Analytics" och "Reporting Roadmap". Analys finns i offentlig förhandsversion. Den innehåller för närvarande data för Boards och automatiserade testresultat via Pipelines. Se tillgängliga data i Analytics Service.

Undersök bygghistorik via en widget på en ny byggdashboard

Vi har en ny och förbättrad widget för bygghistorik som du kan lägga till i dina instrumentpaneler. Med den här widgeten kan du nu visa en historik över byggen från en specifik gren på instrumentpanelen och konfigurera den i ett offentligt projekt för anonyma besökare.

Återkoppling

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.