Releaseopmerkingen voor Azure DevOpsServer 2020 Update 1

Developer Community | Systeemvereisten | licentievoorwaarden | DevOps Blog | SHA-1 Hashes

In dit artikel vindt u informatie over de nieuwste release voor Azure DevOps Server.

Zie Azure DevOps Server Requirementsvoor meer informatie over het installeren of upgraden van een Azure DevOps Server-implementatie. Als u Azure DevOps-producten wilt downloaden, gaat u naar de pagina Downloads van Azure DevOps Server.

Directe upgrade naar Azure DevOps Server 2020 wordt ondersteund vanuit Azure DevOps Server 2019 of Team Foundation Server 2015 of hoger. Als uw TFS-implementatie zich op TFS 2010 of eerder bevindt, moet u enkele tussentijdse stappen uitvoeren voordat u een upgrade uitvoert naar Azure DevOps Server 2019. Zie Azure DevOps on-premisesinstalleren en configureren voor meer informatie.

---

Veilig upgraden van Azure DevOps Server 2019 naar Azure DevOps Server 2020

Azure DevOps Server 2020 introduceert een nieuwe pijplijnuitvoering (build) retentiemodel dat werkt op basis van instellingen op projectniveau.

Azure DevOps Server 2020 verwerkt de retentie van builds anders, op basis van bewaarbeleid op pijplijnniveau. Bepaalde beleidsconfiguraties leiden ertoe dat pijplijnuitvoeringen na de upgrade worden verwijderd. Pijplijnuitvoeringen die handmatig zijn bewaard of worden bewaard door een release, worden niet verwijderd na de upgrade.

Lees ons blogbericht voor meer informatie over het veilig upgraden van Azure DevOps Server 2019 naar Azure DevOps Server 2020.

Releasedatum van Azure DevOps Server 2020 Update 1.2 Patch 15: 11 maart 2025

Bestand	SHA-256-hash
devops2020.1.2patch15.exe	66B6FDE4949C0B7A87B20F3BC8E0673774401929D8B75E37F599DFF8BA74ABE5

We hebben Patch 15 uitgebracht voor Azure DevOps Server 2020 Update 1.2 om het volgende op te nemen:

• Update taken vanwege de uitfasering van Edgio CDN. Bekijk de blogpost over het wijzigen van CDN-providers voor meer informatie.

Releasedatum van Azure DevOps Server 2020 Update 1.2 Patch 14: 12 november 2024

Bestand	SHA-256-hash
devops2020.1.2patch14.exe	89AF4B1FCA1E2BD813A42F0D3E568E64AB470E5FD0A2F87F9E4894B8CA361420

We hebben Patch 14 uitgebracht voor Azure DevOps Server 2020 Update 1.2 om een upgrade naar een kwetsbare afhankelijkheid op te nemen.

Releasedatum van Azure DevOps Server 2020 Update 1.2 Patch 13: 12 maart 2024

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

We hebben Patch 13 uitgebracht voor Azure DevOps Server 2020 Update 1.2 met oplossingen voor het volgende:

• Er is een probleem opgelost waarbij de proxyserver niet meer werkte na de installatie van Patch 12.

Releasedatum van Azure DevOps Server 2020 Update 1.2 Patch 12: 13 februari 2024

Bestand	SHA-256-hash
devops2020.1.2patch12.exe	C4C9EEBBDD3B07C36658C9F78AEA57A980AA633F99DF2A3AD5036F957F095E53

We hebben Patch 12 uitgebracht voor Azure DevOps Server 2020 Update 1.2 met oplossingen voor het volgende:

• Er is een fout opgelost waarbij de schijfruimte die wordt gebruikt door de proxycachemap onjuist werd berekend en de map niet correct werd opgeschoond.
• CVE-2024-20667: Beveiligingsprobleem met externe code-uitvoering van Azure DevOps Server.

Releasedatum van Azure DevOps Server 2020 Update 1.2 Patch 11: 12 december 2023

Bestand	SHA-256-hash
devops2020.1.2patch11.exe	C47B9C898C2E08527F1DDC3E7A5E67F1A11C3AFF860DE9B5FF3DD8718C3AAE87

We hebben Patch 11 uitgebracht voor Azure DevOps Server 2020 Update 1.2 met oplossingen voor het volgende:

• Er is een fout opgelost waarbij de beveiligingserfenis van de pre-implementatiegoedkeuring niet werkte in pipelinefasen.

Releasedatum van Azure DevOps Server 2020 Update 1.2 Patch 10: 14 november 2023

Er is een patch uitgebracht voor Azure DevOps Server 2020 Update 1.2 met oplossingen voor het volgende.

• Uitgebreide lijst met toegestane Tekens voor PowerShell-taken voor Parametervalidatie van shelltaken inschakelen.

Notitie

Als u oplossingen voor deze patch wilt implementeren, moet u een aantal stappen volgen om taken handmatig bij te werken.

Patches installeren

Belangrijk

We hebben updates uitgebracht voor de Azure Pipelines-agent met Patch 8 die is uitgebracht op 12 september 2023. Als u de agentupdates niet hebt geïnstalleerd zoals beschreven in de releaseopmerkingen voor Patch 8, raden we u aan deze updates te installeren voordat u Patch 10 installeert. De nieuwe versie van de agent na de installatie van Patch 8 is 3.225.0.

TFX configureren

1. Volg de stappen in de -uploadtaken in de projectverzamelingdocumentatie om tfx-cli te installeren en in te loggen.

Taken bijwerken met TFX

Bestand	SHA-256-hash
Tasks20231103.zip	389BA66EEBC32622FB83402E21373CE20AE040F70461B9F9AF9EFCED5034D2E5

1. Download en pak Tasks20231103.zipuit.
2. Wijzig de map in de uitgepakte bestanden.
3. Voer de volgende opdrachten uit om de taken te uploaden:

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 

Pijplijnvereisten

Als u het nieuwe gedrag wilt gebruiken, moet een variabele AZP_75787_ENABLE_NEW_LOGIC = true worden ingesteld in pijplijnen die gebruikmaken van de betrokken taken.

• Betreffende klassiek:

  Definieer de variabele op het tabblad Variabele in de pijplijn.

• YAML-voorbeeld:

variables: 
- name: AZP_75787_ENABLE_NEW_LOGIC 
  value: true 

Releasedatum van Azure DevOps Server 2020 Update 1.2 Patch 9: 10 oktober 2023

Belangrijk

We hebben updates uitgebracht voor de Azure Pipelines-agent met Patch 8 die is uitgebracht op 12 september 2023. Als u de agentupdates niet hebt geïnstalleerd zoals beschreven in de releaseopmerkingen voor Patch 8, raden we u aan deze updates te installeren voordat u Patch 9 installeert. De nieuwe versie van de agent na de installatie van Patch 8 is 3.225.0.

We hebben een patch uitgebracht. voor Azure DevOps Server 2020 Update 1.2 met oplossingen voor de volgende problemen.

• Er is een fout opgelost waarbij de identiteit van de analyse-eigenaar wordt weergegeven als inactieve identiteit op computers die bijgewerkt zijn met een patch.

Releasedatum van Azure DevOps Server 2020 Update 1.2 Patch 8: 12 september 2023

Er is een patch uitgebracht voor Azure DevOps Server 2020 Update 1.2 met oplossingen voor het volgende.

• CVE-2023-33136: Azure DevOps Server probleem met uitvoeren van externe code.
• CVE-2023-38155: Verhoging van privileges kwetsbaarheid in Azure DevOps Server en Team Foundation Server.

Belangrijk

Implementeer de patch in een testomgeving en zorg ervoor dat de pijplijnen van de omgeving werken zoals verwacht voordat u de oplossing toepast op productie.

Notitie

Als u oplossingen voor deze patch wilt implementeren, moet u een aantal stappen uitvoeren om de agent en taken handmatig bij te werken.

Patches installeren

1. Download en installeer Azure DevOps Server 2020 Update 1.2 patch 8.

De Azure Pipelines-agent bijwerken

1. Download de software-agent van: https://github.com/microsoft/azure-pipelines-agent/releases/tag/v3.225.0 - Agent_20230825.zip
2. Gebruik de stappen die worden beschreven in de documentatie van zelfgehoste Windows-agents om de agent in te zetten.  

Notitie

Het AZP_AGENT_DOWNGRADE_DISABLED moet worden ingesteld op 'true' om te voorkomen dat de agent wordt gedegradeerd. In Windows kan de volgende opdracht worden gebruikt in een beheeropdrachtprompt, gevolgd door opnieuw opstarten. setx AZP_AGENT_DOWNGRADE_DISABLED true /M

TFX configureren

1. Volg de stappen in de taken_upload naar de projectverzamelingsdocumentatie om tfx-cli te installeren en in te loggen.

Taken bijwerken met TFX

1. Download en pak Tasks_20230825.zipuit.
2. Wijzig de map in de uitgepakte bestanden.
3. Voer de volgende opdrachten uit om de taken te uploaden:

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 

Pijplijnvereisten

Als u het nieuwe gedrag wilt gebruiken, moet een variabele AZP_75787_ENABLE_NEW_LOGIC = true worden ingesteld in pijplijnen die gebruikmaken van de betrokken taken.

• Op klassiek:

  Definieer de variabele op het tabblad Variabele in de pijplijn.

• YAML-voorbeeld:

variables: 
- name: AZP_75787_ENABLE_NEW_LOGIC 
  value: true 

Releasedatum van Azure DevOps Server 2020 Update 1.2 Patch 7: 8 augustus 2023

We hebben een patch uitgebracht voor Azure DevOps Server 2020 Update 1.2 met oplossingen voor het volgende.

• CVE-2023-36869: Beveiligingsprobleem voor spoofing in Azure DevOps Server.
• SSH-service bijwerken ter ondersteuning van SHA2-256 en SHA2-512. Als u SSH-configuratiebestanden in code hebt voor het gebruik van RSA, moet u bijwerken naar SHA2 of de vermelding verwijderen.
• Probleem opgelost met relatieve koppelingen die niet werken in Markdown-bestanden.
• Er is een fout opgelost met opmerkingennavigatie op een doorvoerpagina.
• Er is een fout opgelost waarbij de identiteit van de analyse-eigenaar werd weergegeven als inactieve identiteit.
• Er is een oneindige lusfout opgelost op CronScheduleJobExtension.

Releasedatum van Azure DevOps Server 2020 Update 1.2 Patch 6: 13 juni 2023

We hebben een patch uitgebracht voor Azure DevOps Server 2020 Update 1.2 met oplossingen voor het volgende.

• CVE-2023-21565: Azure DevOps Server Spoofing Vulnerability.
• CVE-2023-21569: Beveiligingsprobleem met Spoofing van Azure DevOps Server.
• Er is een fout opgelost die het pushen van pakketten beïnvloedde bij het upgraden vanaf versie 2018 of eerder.
• Er is een fout opgelost waarbij het loskoppelen of koppelen van verzamelingen mislukt met de volgende foutmelding: 'TF246018: De databasebewerking heeft de time-outlimiet overschreden en is geannuleerd.

Releasedatum van Azure DevOps Server 2020 Update 1.2 Patch 5: 14 februari 2023

We hebben een patch uitgebracht voor Azure DevOps Server 2020 Update 1.2 met oplossingen voor het volgende.

• CVE-2023-21553: Beveiligingsprobleem met uitvoering van externe code van Azure DevOps Server
• Probleem met de toegankelijkheid van shelvesets in de webgebruikersinterface opgelost.
• Klanten moeten de tfsjobagent-service en de azure DevOps Server-toepassingsgroep opnieuw starten na het bijwerken van smtp-gerelateerde instellingen in de Azure DevOps Server-beheerconsole.

Releasedatum van Azure DevOps Server 2020 Update 1.2 Patch 4: 13 december 2022

We hebben een patch uitgebracht voor Azure DevOps Server 2020 Update 1.2 met oplossingen voor het volgende.

• De weergave van speciale tekens in IdentityPicker is gecorrigeerd.

• Testgegevens zijn niet verwijderd, waardoor de database toeneemt. Met deze oplossing hebben we de buildretentie bijgewerkt om te voorkomen dat er nieuwe zwevende testgegevens worden gemaakt.

Releasedatum van Azure DevOps Server 2020 Update 1.2 Patch 3: 18 oktober 2022

We hebben een patch uitgebracht voor Azure DevOps Server 2020 Update 1.2 met oplossingen voor het volgende.

• Los het probleem op met nieuw toegevoegde AD-identiteiten die niet worden weergegeven in identiteitskiezers voor beveiligingsdialoogvensters.
• Los een probleem op met het filter Aangevraagd door lid van groep in de webhook-instellingen.
• Los het probleem met Gated check-in builds op wanneer de organisatie-instellingen voor de pipeline de reikwijdte van de taakauthorisatie hebben ingesteld op Het beperken van de reikwijdte van de taakauthorisatie tot het huidige project voor niet-releasepipelines.
• Er is een probleem opgelost bij het ophalen van het toegangstoken van Azure bij het tot stand brengen van een serviceverbinding achter een geauthenticeerde proxy.

Releasedatum van Azure DevOps Server 2020 Update 1.2 Patch 2: 9 augustus 2022

We hebben een patch uitgebracht voor Azure DevOps Server 2020 Update 1.2 met oplossingen voor het volgende.

• Los de fout met de identiteitswaarde op tijdens het toewijzen van een werkitem aan een identiteit die in verschillende domeinen wordt weergegeven.

Releasedatum van Azure DevOps Server 2020 Update 1.2 Patch 1: 12 juli 2022

We hebben een patch uitgebracht voor Azure DevOps Server 2020 Update 1.2 met oplossingen voor het volgende.

• In API's voor testuitvoeringen is het vervolgtoken dat wordt geretourneerd groter dan de waarde 'maxLastUpdatedDate' die is opgegeven.

Releasedatum van Azure DevOps Server 2020 Update 1.2: 17 mei 2022

Azure DevOps Server 2020 Update 1.2 is een verzamelupdate van bugfixes. U kunt Azure DevOps Server 2020 Update 1.2 rechtstreeks installeren of upgraden vanaf Azure DevOps Server 2020 of Team Foundation Server 2013 of hoger.

Notitie

Het hulpprogramma voor gegevensmigratie is ongeveer drie weken na deze release beschikbaar voor Azure DevOps Server 2020 Update 1.2. U kunt onze lijst met momenteel ondersteunde versies voor import-hierbekijken.

Deze release bevat oplossingen voor het volgende:

• Azure DevOps Server 2020.1.2 schakelt het nieuwe bewaarmodel (geïntroduceerd in Azure DevOps Server 2020) uit om verlies van pijplijnuitvoeringen (builds) te voorkomen. Dit betekent dat het systeem:

  • Leases maken voor de meest recente 3 builds die zijn gegenereerd tijdens het uitvoeren van Server 2020
  • Voor YAML-pijplijnen en klassieke pijplijnen zonder retentiebeleid per pijplijn, worden builds bewaard volgens de maximumretentie-instellingen op verzamelingsniveau .
  • Voor klassieke pipelines met een aangepast bewaarbeleid per pipeline worden builds bewaard volgens het specifieke bewaarbeleid van de pipeline.
  • De bouwversies met huurovereenkomsten tellen niet mee voor het minimum dat nodig is om de instelling te behouden.

• Wijzigingsset- en opmerkingen over planken koppelingen werden niet correct omgeleid. Wanneer opmerkingen werden toegevoegd aan bestanden in wijzigingensets of plankensets, werden deze opmerkingen niet omgeleid naar de juiste plaats in de bestandsweergave.

• Kan de buildwachtrij niet overslaan met behulp van de knop Volgende uitvoeren. Voorheen was de knop Volgende uitvoeren alleen ingeschakeld voor beheerders van projectverzamelingen.

• Alle persoonlijke toegangstokens intrekken nadat het Active Directory-account van een gebruiker is uitgeschakeld.

Releasedatum van Azure DevOps Server 2020.1.1 Patch 4: 26 januari 2022

We hebben een patch uitgebracht voor Azure DevOps Server 2020.1.1 met oplossingen voor het volgende.

• E-mailmeldingen werden niet verzonden bij gebruik van controle @mention in een werkitem.
• Het voorkeurs-e-mailadres werd niet bijgewerkt in het gebruikersprofiel. Dit heeft geresulteerd in e-mailberichten die naar het vorige e-mailadres zijn verzonden.
• De koptekst is niet weergegeven op de pagina Projectoverzicht. De koptekst werd een paar milliseconden weergegeven en verdween.
• Verbetering van active Directory-gebruikerssynchronisatie.
• Er is een kwetsbaarheid voor Elasticsearch opgelost door de jndilookup-klasse te verwijderen uit binaire log4j-bestanden.

Installatiestappen

1. Voer een upgrade uit van de server met Patch 4.
2. Controleer de registerwaarde op HKLM:\Software\Elasticsearch\Version. Als de registerwaarde er niet is, voegt u een tekenreekswaarde toe en stelt u de versie in op 5.4.1 (naam = versie, waarde = 5.4.1).
3. Voer de commando PS C:\Program Files\{TFS Version Folder}\Search\zip> .\Configure-TFSSearch.ps1 -Operation update uit zoals opgegeven in het readme-bestand. Er kan een waarschuwing worden geretourneerd, zoals: Kan geen verbinding maken met de externe server. Sluit het venster niet, omdat de update nieuwe pogingen uitvoert totdat het is voltooid.

Notitie

Als Azure DevOps Server en Elasticsearch op verschillende computers zijn geïnstalleerd, volgt u de onderstaande stappen.

1. Voer een upgrade uit van de server met Patch 4.
2. Controleer de registerwaarde op HKLM:\Software\Elasticsearch\Version. Als de registerwaarde er niet is, voegt u een tekenreekswaarde toe en stelt u de versie in op 5.4.1 (naam = versie, waarde = 5.4.1).
3. Kopieer de inhoud van de map met de naam zip, die zich op C:\Program Files\{TFS Version Folder}\Search\zip bevindt, naar de map remote file van Elasticsearch.
4. Voer Configure-TFSSearch.ps1 -Operation update uit op de elasticsearch-servercomputer.

SHA-256 Hash: 451F0BB73132EFCD2B3D2922F0040DBF2BCF2808C35D3C37CA5A3CD8F65F29D6

Releasedatum van Azure DevOps Server 2020.1.1 Patch 3: 15 december 2021

Patch 3 voor Azure DevOps Server 2020.1.1 bevat oplossingen voor het volgende.

• Herstel de werkitemmacro voor query's met 'Bevat woorden'. Eerder retourneerden query's onjuiste resultaten voor waarden die een regeleinde bevatten.
• Verhoog de limieten voor de tekenlengte van Maven-pakketversies.
• Probleem met lokalisatie van indelingsstatussen voor aangepaste werkitems.
• Lokalisatieprobleem in sjabloon voor e-mailmeldingen.
• Probleem met de evaluatie van NOTSAMEAS-regels wanneer er meerdere NOTSAMEAS-regels zijn gedefinieerd voor een veld.

Releasedatum van Azure DevOps Server 2020.1.1 Patch 2: 26 oktober 2021

Patch 2 voor Azure DevOps Server 2020.1.1 bevat oplossingen voor het volgende.

• Voorheen kon Azure DevOps Server alleen verbindingen maken met GitHub Enterprise Server. Met deze patch kunnen projectbeheerders verbindingen maken tussen Azure DevOps Server en opslagplaatsen op GitHub.com. U vindt deze instelling op de pagina GitHub-verbindingen onder projectinstellingen.
• Los het probleem met de widget Testplan op. Het testuitvoeringsrapport toont een onjuiste gebruiker in de resultaten.
• Probleem opgelost waarbij de overzichtspagina van Projectoverzicht niet kan worden geladen.
• Los het probleem op waarbij e-mailberichten niet worden verzonden ter bevestiging van de productupgrade.

Releasedatum van Azure DevOps Server 2020.1.1 Patch 1: 14 september 2021

Patch 1 voor Azure DevOps Server 2020.1.1 bevat oplossingen voor het volgende.

• Los het probleem met het downloaden/uploaden van artifacts op.
• Los het probleem met inconsistente testresultatengegevens op.

Releasedatum van Azure DevOps Server 2020 Update 1.1: 17 augustus 2021

Azure DevOps Server 2020 Update 1.1 is een verzameling van bugfixes. U kunt Azure DevOps Server 2020 Update 1.1 rechtstreeks installeren of upgraden van Azure DevOps Server 2020 of Team Foundation Server 2013 of hoger.

Notitie

Het hulpprogramma voor gegevensmigratie is ongeveer drie weken na deze release beschikbaar voor Azure DevOps Server 2020 Update 1.1. U kunt onze lijst met momenteel ondersteunde versies voor import-hierbekijken.

Deze release bevat oplossingen voor de volgende fouten:

Azure Boards

• De hyperlink 'Werkitem weergeven' in de e-mailberichten met meldingen maakt geen gebruik van de openbare URL.

Azure Repositories

• De weergave van selectievakjes voor inherente beperkte samenvoegingstypen is verbeterd om het mogelijk te maken limiet-samenvoegingstypen aan te passen nadat cross-repository beleidsregels zijn ingesteld.

Azure Pipelines

• Bij het wijzigen van de instelling voor Agent Update werden instellingen niet doorgegeven aan andere toepassingslagen in de omgeving.

Algemeen

• Spelfouten opgelost in de serverconfiguratiewizard.
• Vergroting van de uitbreidingspakketgrootte en de mogelijkheid om de grootte in het register te wijzigen.

Azure-testplannen

• Kan niet teruggaan naar testresultaten nadat u terug bent geraakt van de geschiedenis naar de overzichtspagina.

---

Releasedatum van Azure DevOps Server 2020.1 Patch 2: 10 augustus 2021

We hebben een patch uitgebracht voor Azure DevOps Server 2020.1 waarmee het volgende wordt opgelost.

• Fout in de gebruikersinterface van de builddefinitie opgelost.
• Browsegeschiedenis gewijzigd om bestanden weer te geven in plaats van de hoofdopslagplaats.

Releasedatum van Azure DevOps Server 2020.1 Patch 1: 15 juni 2021

We hebben een patch uitgebracht voor Azure DevOps Server 2020.1 waarmee het volgende wordt opgelost.

• Veilige cookies die worden gebruikt in autorisatiestromen die SameSite=Nonebevestigen.

• Los het probleem met de Notification SDK op. Eerder werden meldingenabonnementen met het filter Gebiedspad niet correct geparseerd.

Releasedatum van Azure DevOps Server 2020.1 RTW: 25 mei 2021

Samenvatting van wat is er nieuw in Azure DevOps Server 2020.1 RTW

Azure DevOps Server 2020.1 RTW is een verzameling van foutoplossingen. Het bevat alle functies in de Azure DevOps Server 2020.1 RC2 die eerder zijn uitgebracht. Azure DevOps Server 2020.1 RTW- is een samengeteld aantal opgeloste fouten. U kunt Azure DevOps Server 2020.1 rechtstreeks installeren of upgraden van Azure DevOps Server 2020, 2019 of Team Foundation Server 2015 of hoger.

Notitie

Het hulpprogramma voor gegevensmigratie is ongeveer drie weken na deze release beschikbaar voor Azure DevOps Server 2020 Update 1. U kunt onze lijst met momenteel ondersteunde versies voor import-hierbekijken.

Releasedatum van Azure DevOps Server 2020.1 RC2: 13 april 2021

Overzicht van wat er nieuw is in Azure DevOps Server 2020.1 RC2

Azure DevOps Server 2020.1 RC2 is een verzameling van oplossingen voor fouten. Het bevat alle functies in de Azure DevOps Server 2020.1 RC1 die eerder zijn uitgebracht.

Releasedatum van Azure DevOps Server 2020.1 RC1: 23 maart 2021

Overzicht van wat er nieuw is in Azure DevOps Server 2020.1 RC1

Azure DevOps Server 2020.1 RC1 introduceert veel nieuwe functies. Enkele van de hoogtepunten zijn:

• Regels voor beperkingen van statusovergangen in bordjes
• Belanghebbenden kunnen nu werkitems verplaatsen over de kolommen van het bord
• Releasebeveiliging verbeteren door het bereik van toegangstokens te beperken
• verbeterde ervaring voor pull-aanvragen
• triggers voor meerdere opslagplaatsen in pijplijnen

U kunt ook naar afzonderlijke secties gaan om alle nieuwe functies voor elke service te bekijken:

• Borden
• opslagplaatsen
• pijplijnen
• artefacten

---

Borden

Beperkingsregels voor statusovergang

We blijven de functiepariteitsverschil tussen gehoste XML en het overgenomen procesmodel sluiten. Met deze nieuwe regel voor het type werkitem kunt u voorkomen dat werkitems van de ene status naar de andere worden verplaatst. U kunt bijvoorbeeld voorkomen dat bugs van Nieuw naar Opgelost gaan. In plaats daarvan moeten ze van Nieuw -> Actief -> Opgelost gaan

U kunt ook een regel maken om statusovergangen per groepslidmaatschap te beperken. Alleen gebruikers in de groep Goedkeurders kunnen bijvoorbeeld gebruikersverhalen verplaatsen van Nieuw -> Goedgekeurd.

Werkitem kopiëren om onderliggende items te kopiëren

Een van de meest aangevraagde functies voor Azure Boards is de mogelijkheid om een werkitem te kopiëren waarmee ook de onderliggende werkitems worden gekopieerd. We hebben een nieuwe optie toegevoegd om "onderliggende werkitems op te nemen" in het dialoogvenster voor het kopiëren van werkitems. Wanneer deze optie is geselecteerd, wordt het werkitem gekopieerd en worden alle onderliggende werkitems gekopieerd (maximaal 100).

Verbeterde regels voor geactiveerde en opgeloste velden

Tot nu toe zijn de regels voor geactiveerd door, activeringsdatum, opgelost dooren oplossingsdatum een mysterie geweest. Ze zijn alleen ingesteld voor systeemwerkitemtypen en zijn specifiek voor de statuswaarde 'Actief' en 'Opgelost'. We hebben de logica gewijzigd, zodat deze regels niet langer voor een specifieke status gelden. In plaats daarvan worden ze geactiveerd door de categorie (statuscategorie) waarin de status zich bevindt. Laten we bijvoorbeeld zeggen dat u de aangepaste status 'Moet Getest Worden' hebt in de categorie Opgelost. Wanneer het werkitem verandert van "Actief" in "Moet getest worden," worden de Opgelost door en Opgeloste datum regels geactiveerd.

Hierdoor kunnen klanten aangepaste statuswaarden maken en toch de velden Geactiveerd door, Geactiveerde Datum, Opgelost dooren Opgeloste Datum genereren, zonder aangepaste regels te hoeven gebruiken.

Belanghebbenden kunnen werkitems verplaatsen over de kolommen van het bord

Belanghebbenden hebben altijd de status van werkitems kunnen wijzigen. Maar wanneer ze naar het Kanbanbord gaan, kunnen ze de werkitems niet van de ene kolom naar de andere verplaatsen. In plaats daarvan moeten belanghebbenden elk werkitem één voor één openen en de statuswaarde bijwerken. Dit is al lang een pijnpunt voor klanten en we zijn blij om aan te kondigen dat u nu werkitems kunt verplaatsen over de kolommen van het bord.

Systeem werkitemtypen voor achterstandenlijsten en overzichtsborden

U kunt nu een systeemwerkitemtype toevoegen aan het backlogniveau naar keuze. Deze typen werkitems zijn in het verleden alleen beschikbaar vanuit query's.

Proces	Werkitemtype
Agile	Probleem
Scrum	Belemmering
CMMI	Wijzigingsaanvraag
	Probleem
	Recensie
	Risico

Het toevoegen van een systeemwerkitemtype aan een achterstandsniveau is eenvoudig. Ga naar uw aangepaste proces en klik op het tabblad Achterstandsniveaus. Selecteer het gewenste backlogniveau (bijvoorbeeld: Vereistenachterstand) en kies de bewerkingsoptie. Voeg vervolgens het type werkitem toe.

Limiet voor GitHub-app-opslagplaatsen in Azure Boards verhoogd

De opslagplaatslimiet voor de Azure Boards-toepassing in de GitHub Marketplace is verhoogd van 100 tot 250.

De status van het werkitem aanpassen wanneer de pull-aanvraag wordt samengevoegd

Niet alle werkstromen zijn hetzelfde. Sommige klanten willen hun gerelateerde werkitems sluiten wanneer een pull-aanvraag is voltooid. Anderen willen de werkitems instellen op een andere status die moet worden gevalideerd voordat ze worden gesloten. We moeten beide toestaan.

We hebben een nieuwe functie waarmee u de werkitems kunt instellen op de gewenste status wanneer de pull-aanvraag wordt samengevoegd en voltooid. Hiervoor scannen we de beschrijving van de pull request en zoeken we naar de statuswaarde gevolgd door de #mention van de werkitems. In dit voorbeeld stellen we twee gebruikersverhalen in op Opgelost en sluiten we twee taken.

Uw werkitem koppelen aan builds in een ander project

U kunt nu eenvoudig uw buildafhankelijkheden in een project bijhouden door uw werkitem te koppelen aan een build, gevonden in build of geïntegreerd in build.

Beschrijving bewerken (Help-tekst) op systeemvelden

U hebt altijd de beschrijving van aangepaste velden kunnen bewerken. Maar voor systeemvelden zoals prioriteit, ernst en activiteit kon de beschrijving niet worden bewerkt. Dit was een functie-kloof tussen de gehoste XML en Overgenomen, waardoor sommige klanten niet naar het overgenomen model kunnen migreren. U kunt nu de beschrijving van systeemvelden bewerken. De bewerkte waarde heeft alleen invloed op dat veld in het proces en voor dat type werkitem. Dit biedt u de flexibiliteit om verschillende beschrijvingen te hebben voor hetzelfde veld voor verschillende typen werkitems.

De status van het werkitem aanpassen wanneer de pull-aanvraag wordt samengevoegd

Pull-aanvragen verwijzen vaak naar meerdere werkitems. Wanneer u een pull-aanvraag maakt of bijwerkt, kunt u een aantal hiervan sluiten, een aantal hiervan oplossen en de rest open houden. U kunt nu opmerkingen gebruiken, zoals de opmerkingen die worden weergegeven in de onderstaande afbeelding om dat te bereiken. Zie documentatie voor meer informatie.

aanpassen

Ouderveld op het taakbord

Vanwege vele verzoeken kunt u nu het veld Ouder toevoegen aan zowel de kaarten van het kind als die van de ouder op het takenbord.

De regel "Toegewezen aan" verwijderen van het bug-werkitemtype

Er zijn verschillende verborgen systeemregels voor alle verschillende typen werkitems in Agile, Scrum en CMMI. Deze regels bestaan al meer dan tien jaar en werken over het algemeen prima zonder klachten. Er zijn echter een aantal regels die niet meer welkom zijn. Een regel in het bijzonder heeft veel pijn veroorzaakt voor nieuwe en bestaande klanten en we hebben besloten dat het tijd was om het te verwijderen. Deze regel bestaat in het werkitemtype Bug in het Agile-proces.

"Stel de toegewezen waarde in op Gemaakt door wanneer de status wordt gewijzigd in Opgelost"

We hebben veel feedback ontvangen over deze regel. Als antwoord hebben we deze regel verwijderd uit het werkitemtype Bug in het Agile-proces. Deze wijziging is van invloed op elk project met behulp van een overgenomen Agile- of een aangepast, overgenomen Agile-proces. Voor klanten die graag gebruikmaken van en afhankelijk zijn van deze huidige regel, raadpleegt u ons blogbericht over de stappen die u kunt ondernemen om de regel opnieuw toe te voegen door aangepaste regels toe te passen.

Verwijderde items op de pagina Werkitems

De pagina Werkitems is een geweldige plek om snel items te vinden die u hebt gemaakt of die aan u zijn toegewezen, onder andere. Het biedt verschillende gepersonaliseerde draaipunten en filters. Een van de belangrijkste klachten voor het draaipunt 'Toegewezen aan mij' is dat het verwijderde werkitems weergeeft (dat wil zeggen werkitems met de status Verwijderd). En we zijn het ermee eens! Verwijderde items zijn werk dat niet langer van waarde is en dus is verwijderd uit de achterstand, dus het opnemen in deze weergave is niet nuttig.

U kunt nu alle verwijderde items verbergen in de weergave Toegewezen aan mij op de pagina Werkitems.

Repos

Standaardvoorkeur voor vertakkingsnaam

Azure Repos biedt nu een aanpasbare standaardbranche-naam voor Git. In opslagplaatsinstellingen kunt u elke juridische vertakkingsnaam kiezen die moet worden gebruikt wanneer een opslagplaats wordt geïnitialiseerd. Azure Repos heeft altijd ondersteuning geboden voor het wijzigen van de standaardnaam van de tak voor een bestaande repository.

Voor meer informatie, zie Vertakkingen beheren en De standaardbranch wijzigen.

Instelling op organisatieniveau voor standaardbranch

Er is nu een instelling op het niveau van de verzameling voor de naam van uw favoriete beginvertakking voor nieuwe opslagplaatsen. Als een project geen naam voor de eerste vertakking heeft gekozen, wordt deze instelling op organisatieniveau gebruikt. Als u de naam van de eerste vertakking niet hebt opgegeven in de organisatie-instellingen of de projectinstellingen, gebruiken nieuwe opslagplaatsen een door Azure DevOps gedefinieerde standaardinstelling.

op organisatieniveau

Een nieuw verificatiebereik toevoegen voor het toevoegen van pr-opmerkingen

In deze release wordt een nieuw OAuth-bereik toegevoegd voor het lezen/schrijven van opmerkingen bij pull-aanvragen. Als u een bot of automatisering hebt die alleen hoeft te communiceren met opmerkingen, kunt u deze een PAT geven met alleen dit bereik. Dit proces vermindert de straalstraal als de automatisering een bug heeft of als het token is aangetast.

Verbeteringen in de Pull Request-gebruikservaring

De nieuwe ervaring voor pull-aanvragen is verbeterd met de volgende mogelijkheden:

• de optionele controles beter zichtbaar maken

Klanten gebruiken optionele controles om de aandacht van een ontwikkelaar op potentiële problemen te vestigen. In de vorige ervaring was het voorheen duidelijk wanneer deze controles mislukken. Dat is echter niet het geval in de preview-ervaring. Een groot groen vinkje op de vereiste controles maskert de fouten in optionele controles. Gebruikers konden alleen ontdekken dat optionele controles zijn mislukt door het deelvenster Controles te openen. Ontwikkelaars doen dat niet vaak wanneer er geen indicatie is van een probleem. In deze implementatie hebben we de status van optionele controles beter zichtbaar gemaakt in de samenvatting.

• Ctrl-klikken op de menu-items

Tabbladenmenu's in een Pull Request bieden geen ondersteuning voor Ctrl-klik. Gebruikers openen vaak nieuwe browsertabbladen wanneer ze een pull-aanvraag controleren. Dit is opgelost.

• locatie van [+] annotatie

In het overzicht van bestanden in een pull request wordt een markering [+] weergegeven om auteurs en reviewers te helpen nieuwe bestanden te identificeren. Omdat de aantekening na het beletselteken was, was het vaak niet zichtbaar voor langere bestandsnamen.

• PR updates vervolgkeuzelijst krijgt weer tijdsgegevens

In de dropdown om bestanden bij te werken en te vergelijken in een pull request is een belangrijk element in de preview-ervaring verloren gegaan. Het werd niet weergegeven toen die update werd uitgevoerd. Dit is opgelost.

• **Verbeterde indeling voor opmerkingenfilter **

Bij het filteren van opmerkingen op de overzichtspagina van een pull-aanvraag, stond de vervolgkeuzelijst aan de rechterkant, maar werd de tekst links uitgelijnd. Dit is opgelost.

• navigatie naar bovenliggende commits

Op de pagina Commits kunt u de wijzigingen in een bepaalde commit vergelijken met de ouder commit. U kunt echter naar de bovenliggende commit gaan en meer inzicht krijgen in hoe deze commit verschilt van zijn eigen bovenliggende commit. Dit is vaak nodig wanneer u alle wijzigingen in een release wilt begrijpen. We hebben een ouderkaart toegevoegd aan een commit om u te helpen dit te bereiken.

• Meer ruimte voor mappen en bestanden met lange namen op het PR-bestandentabblad

Mappen en bestanden met lange namen zijn afgekapt vanwege een gebrek aan horizontale afstand in de bestandsstructuur. We hebben wat extra ruimte in de boom vrijgemaakt door de inspringing van de boom te wijzigen zodat deze overeenkomt met het hoofdknooppunt en door de knop met het beletselteken van de pagina te verbergen, behalve wanneer eroverheen wordt gegaan met de muis.

Afbeelding van de nieuwe bestandsstructuur:

Afbeelding van de bestandsstructuur wanneer u de muisaanwijzer boven een map plaatst:

• Scrollpositie behouden bij het resizen van het diff-deelvenster op het tabblad PR-bestanden

Wanneer u het formaat van het diff-deelvenster naast elkaar wijzigt op het tabblad PR-bestanden, verliest de gebruiker zijn scrollpositie. Dit probleem is opgelost; de scrollpositie van de gebruiker blijft nu behouden bij het aanpassen van de grootte van een diff-venster.

• Zoeken naar een commit met een mobiel apparaat

Wanneer u de pagina Doorvoeringen op een mobiel apparaat bekijkt, is het zoekvak afwezig in de nieuwe interface. Als gevolg hiervan is het moeilijker voor u om een commit te vinden aan de hand van zijn hash en deze te openen. Dit is nu opgelost.

• Verbeterd gebruik van ruimte voor nieuwe PR-bestandsverschillen in de mobiele weergave

We hebben deze pagina bijgewerkt om beter gebruik te maken van de ruimte, zodat gebruikers meer van het bestand kunnen zien in mobiele weergaven in plaats van 40% van het scherm door een koptekst te gebruiken.

• Verbeterde afbeeldingen in PR-samenvattingsweergave

Afbeeldingen die in een pull request zijn bewerkt, werden niet weergegeven in de samenvattingsweergave van de pull request, maar werden wel correct weergegeven in de weergave van de pull request-bestanden. Dit probleem is opgelost.

• Verbeterde vertakkingservaring bij het maken van een nieuwe pull-aanvraag

Vóór deze update was deze ervaring niet ideaal omdat de wijzigingen zouden worden vergeleken met de standaardbranch van de opslagplaats in plaats van de vergelijkingsbranch.

Pijpleidingen

Aanvullend agentplatform: ARM64

We hebben Linux/ARM64 toegevoegd aan de lijst met ondersteunde platforms voor de Azure Pipelines-agent. Hoewel de codewijzigingen minimaal waren, moesten veel werkzaamheden achter de schermen eerst worden voltooid en we zijn verheugd om de release aan te kondigen.

Ondersteuning voor tagfilters voor pijplijnbronnen

We hebben nu tags toegevoegd in YAML-pijplijnen. U kunt tags gebruiken om de CI-pijplijn in te stellen om uit te voeren of wanneer deze automatisch moet worden geactiveerd.

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

In het bovenstaande fragment ziet u dat tags kunnen worden gebruikt om de standaardversie van de CI-pijplijn (continue integratie) te bepalen die moet worden uitgevoerd wanneer de cd-pijplijnuitvoering (continue implementatie) niet wordt geactiveerd door een andere bron/resource of een geplande uitvoeringstrigger.

Als u bijvoorbeeld een geplande trigger hebt ingesteld voor uw CD-pijplijn die u alleen wilt uitvoeren als uw CI de productietag heeft, zorgt de tags in de sectie triggers ervoor dat de CD-pijplijn alleen wordt geactiveerd als aan de taggingvoorwaarde wordt voldaan door de CI-voltooiingsgebeurtenis.

Bepalen welke taken zijn toegestaan in pijplijnen

U kunt nu Marketplace-taken uitschakelen. Sommige van jullie staan mogelijk Marketplace-extensies toe, maar niet de taken voor pijplijnen die ermee komen. Voor nog meer controle kunt u ook alle ingebouwde taken onafhankelijk uitschakelen (behalve afrekenen, wat een speciale handeling is). Als beide instellingen zijn ingeschakeld, zijn de enige taken die in een pijplijn mogen worden uitgevoerd, de taken die zijn geüpload met behulp van tfx-. Ga naar https://dev.azure.com/<your_org>/_settings/pipelinessettings en zoek de sectie 'Taakbeperkingen' om aan de slag te gaan.

Exclusief beleid voor implementatievergrendeling

Met deze update kunt u ervoor zorgen dat slechts één uitvoering tegelijk in een omgeving wordt geïmplementeerd. Als u de optie "Exclusief vergrendelen" voor een omgeving kiest, zal slechts één uitvoering plaatsvinden. Latere processen die naar die omgeving willen worden geïmplementeerd, worden gepauzeerd. Zodra de uitvoering met de exclusieve vergrendeling is voltooid, wordt de nieuwste uitvoering voortgezet. Tussenliggende uitvoeringen worden geannuleerd.

Fasenfilters voor pijplijnresource-triggers

We hebben ondersteuning toegevoegd voor 'fasen' als filter voor pijplijnbronnen in YAML. Met dit filter hoeft u niet te wachten totdat de volledige CI-pijplijn is voltooid om uw CD-pijplijn te activeren. U kunt er nu voor kiezen om uw CD-pijplijn te activeren na voltooiing van een specifieke fase in uw CI-pijplijn.

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

Wanneer de gespecificeerde fasen in het triggerfilter met succes zijn voltooid in uw CI-pijplijn, wordt er automatisch een nieuwe run geactiveerd voor uw CD-pijplijn.

Algemene op webhooks gebaseerde triggers voor YAML-pijplijnen

Tegenwoordig hebben we verschillende resources (zoals pijplijnen, containers, build en pakketten) waarmee u artefacten kunt gebruiken en geautomatiseerde triggers kunt inschakelen. Tot nu toe kunt u het implementatieproces echter niet automatiseren op basis van andere externe gebeurtenissen of services. In deze release introduceren we ondersteuning voor webhooktriggers in YAML-pijplijnen om integratie van pijplijnautomatisering met elke externe service mogelijk te maken. U kunt zich abonneren op externe gebeurtenissen via de webhooks (Github, Github Enterprise, Nexus, Aritfactory, enzovoort) en uw pijplijnen activeren.

Hier volgen de stappen voor het configureren van de webhooktriggers:

1. Stel een webhook in uw externe service in. Bij het maken van uw webhook moet u de volgende informatie opgeven:

   • Aanvraag-URL - "https://dev.azure.com/<ADO-verzameling>/_apis/public/distributedtask/webhooks/<WebHook-naam>?api-versie=6.0-preview"
   • Geheim: dit is optioneel. Als u uw JSON-nettolading wilt beveiligen, geeft u de geheime waarde op

2. Maak een nieuwe "Binnenkomende Webhook"-serviceverbinding. Dit is een nieuw geïntroduceerd serviceverbindingstype waarmee u drie belangrijke gegevens kunt definiëren:

   • Webhooknaam: De naam van de webhook moet overeenkomen met de webhook die is aangemaakt in uw externe service.
   • HTTP-header: de naam van de HTTP-header in de aanvraag die de payload-hashwaarde bevat voor verificatie van de aanvraag. In het geval van GitHub is de aanvraagheader bijvoorbeeld 'X-Hub-Signature'
   • Geheime: Het geheime wordt gebruikt om de payload-hash te analyseren die dient voor de verificatie van het binnenkomende verzoek (dit is optioneel). Als u een geheim hebt gebruikt bij het maken van uw webhook, moet u dezelfde geheime sleutel opgeven

   

3. Er wordt een nieuw resourcetype met de naam webhooks geïntroduceerd in YAML-pijplijnen. Als u zich wilt abonneren op een webhook-gebeurtenis, moet u een webhookresource in uw pijplijn definiëren en deze naar de binnenkomende webhookserviceverbinding laten verwijzen. U kunt ook aanvullende filters definiëren voor de webhookresource op basis van de JSON-nettoladinggegevens om de triggers voor elke pijplijn verder aan te passen en u kunt de nettoladinggegevens gebruiken in de vorm van variabelen in uw taken.

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

4. Wanneer een webhookgebeurtenis wordt ontvangen door de inkomende webhookserviceverbinding, wordt een nieuwe run geactiveerd voor alle pijplijnen die zijn geabonneerd op de webhookgebeurtenis.

Ondersteuning voor YAML-resourcetriggerproblemen bieden en traceerbaarheid.

Het kan verwarrend zijn wanneer pijplijntriggers niet worden uitgevoerd zoals je ze verwacht. Om dit beter te begrijpen, hebben we een nieuw menu-item toegevoegd op de pagina pijplijndefinitie met de naam 'Triggerproblemen' waar informatie wordt weergegeven met betrekking tot waarom triggers niet worden uitgevoerd.

Resourcetriggers kunnen om twee redenen niet worden uitgevoerd.

1. Als de bron van de opgegeven serviceverbinding ongeldig is of als er syntaxisfouten in de trigger zijn, wordt de trigger helemaal niet geconfigureerd. Deze worden weergegeven als fouten.

2. Als de triggervoorwaarden niet overeenkomen, wordt de trigger niet uitgevoerd. Wanneer dit gebeurt, wordt er een waarschuwing weergegeven, zodat u kunt begrijpen waarom de voorwaarden niet overeenkomen.

   

Triggers voor meerdere opslagplaatsen

U kunt meerdere opslagplaatsen in één YAML-bestand opgeven en ervoor zorgen dat een pijplijn wordt geactiveerd door updates voor een van de opslagplaatsen. Deze functie is bijvoorbeeld handig in de volgende scenario's:

• U gebruikt een hulpprogramma of bibliotheek uit een andere opslagplaats. U wilt tests voor uw toepassing uitvoeren wanneer het hulpprogramma of de bibliotheek wordt bijgewerkt.
• U houdt uw YAML-bestand in een afzonderlijke opslagplaats van de toepassingscode. U wilt de pijplijn telkens activeren wanneer een update naar de toepassingsopslagplaats wordt gepusht.

Met deze update werken multi-repo triggers alleen voor Git-opslagplaatsen in Azure Repos. Ze werken niet voor GitHub- of BitBucket-opslagplaatsresources.

Hier volgt een voorbeeld waarin wordt getoond hoe u meerdere opslagplaatsresources in een pijplijn definieert en hoe u triggers configureert voor al deze resources.

trigger:
- main

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

De pijplijn in dit voorbeeld wordt geactiveerd als er updates zijn voor:

• main branch in de self opslagplaats bevattende het YAML-bestand
• main en release vertakkingen in tools opslagplaats

Zie Meerdere opslagplaatsen in uw pijplijnvoor meer informatie.

Uploaden van agentlogboeken verbeterd

Wanneer een agent stopt met communiceren met de Azure Pipelines-server, wordt de taak die het uitvoerde, achtergelaten. Als u toevallig de logboeken van de streamingconsole bekijkt, hebt u misschien wat aanwijzingen gekregen over wat de agent precies aan de hand had voordat deze niet meer reageerde. Maar als u dat niet was, of als u de pagina vernieuwde, waren die consolelogboeken verdwenen. Met deze release, als de agent niet meer reageert voordat het alle logboeken verstuurt, bewaren we de consolelogboeken als het beste alternatief. Consolelogboeken zijn beperkt tot 1000 tekens per regel en kunnen af en toe onvolledig zijn, maar ze zijn veel nuttiger dan niets weergeven. Het onderzoeken van deze logboeken kan u helpen bij het oplossen van problemen met uw eigen pijplijnen en het zal onze ondersteuningstechnici zeker helpen bij het oplossen van problemen.

Containervolumes optioneel koppelen met het kenmerk Alleen-lezen

Wanneer u een containertaak uitvoert in Azure Pipelines, worden verschillende volumes met de werkruimte, taken en andere materialen toegewezen als volumes. Deze volumes zijn standaard ingesteld op lees-/schrijftoegang. Voor betere beveiliging kunt u de volumes koppelen met het kenmerk Alleen-lezen door de containerspecificatie in YAML te wijzigen. Elke sleutel onder mountReadOnly kan worden ingesteld op true voor alleen-lezen (de standaardwaarde is false).

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

Fijnmazige controle over het starten/stoppen van containers

Over het algemeen raden we u aan Azure Pipelines toe te staan de levenscyclus van uw taak- en servicecontainers te beheren. In sommige ongebruikelijke scenario's wilt u deze echter zelf starten en stoppen. Met deze release hebben we die mogelijkheid ingebouwd in de Docker-taak.

Hier volgt een voorbeeldpijplijn met behulp van de nieuwe mogelijkheid:

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

Daarnaast bevatten we de lijst met containers in een pijplijnvariabele, Agent.ContainerMapping. U kunt dit gebruiken als u bijvoorbeeld de lijst met containers in een script wilt inspecteren. Het bevat een tekenreeks-JSON-object dat de resourcenaam ('builder' uit het bovenstaande voorbeeld) toegeeft aan de container-id die de agent beheert.

Voor elke stap de taakbundels uitpakken

Wanneer de agent een taak uitvoert, worden eerst alle taakbundels gedownload die nodig zijn voor de stappen van de taak. Normaal gesproken worden voor prestaties de taken eenmaal per taak uitgepakt, zelfs als de taak in meerdere stappen wordt gebruikt. Als u zich zorgen maakt over niet-vertrouwde code die de uitgepakte inhoud wijzigt, kunt u wat prestaties inruilen door de agent de taak bij elk gebruik uit te laten pakken. Als u deze modus wilt inschakelen, geeft u --alwaysextracttask door bij het configureren van de agent.

Releasebeveiliging verbeteren door het bereik van toegangstokens te beperken

Voortbouwend op ons initiatief om beveiligingsinstellingen voor Azure Pipelines te verbeteren, bieden we nu ondersteuning voor het beperken van het bereik van toegangstokens voor releases.

Elke taak die in releases wordt uitgevoerd, krijgt een toegangstoken. Het toegangstoken wordt gebruikt door de taken en door uw scripts om terug te bellen naar Azure DevOps. We gebruiken bijvoorbeeld het toegangstoken om broncode op te halen, artefacten te downloaden, logboeken te uploaden, testresultaten te testen of OM REST-aanroepen naar Azure DevOps uit te voeren. Er wordt een nieuw toegangstoken gegenereerd voor elke taak en het verloopt zodra de taak is voltooid.

Met deze update bouwen we voort op het verbeteren van de beveiliging van pijplijnen door het bereik van toegangstokens te beperken en hetzelfde uit te breiden naar klassieke releases.

Deze functie is standaard ingeschakeld voor nieuwe projecten en verzamelingen. Voor bestaande verzamelingen moet u deze inschakelen in verzameling Instellingen > Pijplijnen > Instellingen. > Het bereik voor taakautorisatie beperken tot het huidige project voor releasepijplijnen. Meer informatie hier.

Verbeteringen in de YAML Preview-API

U kunt nu een voorbeeld bekijken van de volledige YAML- van een pijplijn zonder deze uit te voeren. Daarnaast hebben we een speciale nieuwe URL gemaakt voor de preview-functie. Nu kunt u POST naar https://dev.azure.com/{collection}/{project}/_apis/pipelines/{pipelineId}/preview om de voltooide YAML-hoofdtekst op te halen. Deze nieuwe API gebruikt dezelfde parameters als het in de wachtrij plaatsen van een uitvoering, maar vereist niet langer de machtiging 'Queue builds'.

Voer deze taak volgende uit

Hebt u ooit een bugfix gehad die u nodig had om op dit moment te implementeren maar moest wachten achter CI- en PR-taken? Met deze release kunt u nu de prioriteit van een wachttijtaak verhogen. Gebruikers met de machtiging Beheren voor de pool , meestal poolbeheerders, zien een nieuwe knop 'Volgende uitvoeren' op de pagina met taakdetails. Als u op de knop klikt, wordt de taak zo snel mogelijk uitgevoerd. (U hebt natuurlijk nog steeds beschikbare parallelle uitvoering en een geschikte agent nodig.)

Sjabloonexpressies toegestaan in YAML-resources blok

Voorheen waren compilatie-expressies (${{ }}) niet toegestaan in de sectie resources van een YAML-bestand van Azure Pipelines. Met deze release hebben we deze beperking voor containers opgeheven. Hiermee kunt u de inhoud van de runtimeparameter in uw resources gebruiken, bijvoorbeeld om een container te kiezen tijdens de wachttijd. We zijn van plan deze ondersteuning uit te breiden naar andere resources in de loop van de tijd.

Controle over geautomatiseerde taakupdates vanuit Marketplace

Wanneer u een YAML-pijplijn schrijft, geeft u normaal gesproken alleen het primaire versienummer van de opgenomen taken op. Hierdoor kunnen uw pijplijnen automatisch de meest recente functietoevoegingen en oplossingen voor fouten gebruiken. Soms moet u teruggaan naar een vorige puntrelease van een taak. Met deze update hebben we de mogelijkheid toegevoegd om dit te doen. U kunt nu een volledige versie van de taak major.minor.patch opgeven in uw YAML-pijplijnen.

We raden u niet aan dit regelmatig te doen en deze alleen te gebruiken als tijdelijke tijdelijke oplossing wanneer u merkt dat een nieuwere taak uw pijplijnen onderbreekt. Hiermee wordt ook geen oudere versie van een taak vanuit Marketplace geïnstalleerd. Het moet al bestaan in uw collectie of uw pijplijn zal falen.

Voorbeeld:

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

Ondersteuning voor knooppunt 10 in agent en taken

Omdat Node 6 niet meer wordt ondersteund, migreren we de taken om te werken met Node 10. Voor deze update hebben we bijna 50% in-box-taken gemigreerd naar Node 10. De agent kan nu zowel Node 6- als Node 10-taken uitvoeren. In een toekomstige update wordt Node 6 volledig uit de agent verwijderd. Bereid u voor op de verwijdering van Node 6 van de agent door uw interne extensies en aangepaste taken bij te werken zodat ze binnenkort ook Node 10 gebruiken. Als u Node 10 wilt gebruiken voor uw taak, werkt u in uw task.json, onder execution, bij van Node naar Node10.

YAML-conversie verbeteren in de klassieke buildontwerper

Met deze release introduceren we een nieuwe functie 'exporteren naar YAML' voor build-pijplijnen voor designer. Sla uw pijplijndefinitie op en zoek vervolgens 'Exporteren naar YAML' in het menu ....

De nieuwe exportfunctie vervangt de functie 'Weergeven als YAML' die eerder in de klassieke buildontwerper is gevonden. Deze functie was onvolledig omdat alleen kon worden gecontroleerd wat de webgebruikersinterface wist van de build, wat soms leidde tot onjuiste YAML die werd gegenereerd. De nieuwe exportfunctie houdt precies rekening met de manier waarop de pijplijn wordt verwerkt en genereert YAML met volledige betrouwbaarheid voor de ontwerppijplijn.

Nieuwe conversie van het webplatform : opslagplaatsinstellingen

We hebben de twee pagina's met opslagplaatsinstellingen geconverteerd naar één ervaring die is bijgewerkt naar een nieuw webplatform. Deze upgrade maakt niet alleen de ervaring sneller en moderner, maar deze pagina's bieden ook één toegangspunt voor alle beleidsregels van het projectniveau tot het vertakkingsniveau.

Met deze nieuwe ervaring is navigatie voor projecten met een aanzienlijk aantal opslagplaatsen eenvoudiger geworden vanwege snellere laadtijden en een extra zoekfilter. U kunt ook beleidsregels op projectniveau en de lijst met beleidsregels voor meerdere opslagplaatsen weergeven op het tabblad Beleid.

Als u in een opslagplaats klikt, kunt u beleidsregels en machtigingen weergeven die zijn ingesteld op het niveau van de opslagplaats. Op het tabblad Beleid kunt u een lijst bekijken van elke afzonderlijke vertakking waarop het beleid is ingesteld. Klik nu op de vertakking om het beleid allemaal weer te geven terwijl u de instellingenpagina van de opslagplaats nooit verlaat.

Wanneer beleidsregels worden geërfd van een hoger niveau dan waarmee u werkt, geven we aan waar het beleid is geërfd naast elke afzonderlijke beleidsregel. U kunt ook naar de pagina navigeren waarop het beleid op een hoger niveau is ingesteld door op de naam van het bereik te klikken.

De beleidspagina zelf is ook bijgewerkt naar het nieuwe webplatform met samenvouwbare secties. Om de ervaring van het zoeken naar een bepaald buildvalidatie-, statuscontrole- of automatische revisorbeleid te verbeteren, hebben we zoekfilters toegevoegd voor elke sectie.

Integratie van ServiceNow-wijzigingsbeheer met YAML-pijplijnen

De Azure Pipelines-app voor ServiceNow helpt u bij het integreren van Azure Pipelines en ServiceNow Change Management. Met deze update bevorderen we onze reis om Azure Pipelines bewust te maken van het wijzigingsbeheerproces dat in ServiceNow wordt beheerd, naar YAML-pijplijnen.

Door de controle 'ServiceNow Change Management' op een resource te configureren, kunt u nu pauzeren zodat de wijziging kan worden goedgekeurd voordat u de build naar die resource implementeert. U kunt automatisch een nieuwe wijziging voor een fase maken of wachten op een bestaande wijzigingsaanvraag.

U kunt de UpdateServiceNowChangeRequest taak ook toevoegen aan een servertaak om de wijzigingsaanvraag bij te werken met de implementatiestatus, notities, enzovoort.

Artefacten

Mogelijkheid om organisatiebrede feeds te maken vanuit de gebruikersinterface

We brengen de mogelijkheid voor klanten terug om verzamelingsfeeds te maken en te beheren via de webgebruikersinterface voor zowel on-premises als gehoste services.

U kunt nu binnen het bereik van de organisatie feeds maken via de gebruikersinterface, door naar Artefacten te gaan:> Feed maken en een type feed kiezen binnen het bereik.

Hoewel we het gebruik van feeds met projectbereik wel aanbevelen in overeenstemming met de rest van Azure DevOps-aanbiedingen, kunt u opnieuw feeds met verzamelingsbereik maken, beheren en gebruiken via de gebruikersinterface en verschillende REST API's. Raadpleeg onze feedsdocumentatie voor meer informatie.

REST API voor het bijwerken van pakketversies nu beschikbaar voor Maven-pakketten

U kunt nu de REST API updatepakketversie van Azure Artifacts gebruiken om Maven-pakketversies bij te werken. Voorheen kon u de REST API gebruiken om pakketversies bij te werken voor NuGet-, Maven-, npm- en Universal Packages, maar niet voor Maven-pakketten.

Als u Maven-pakketten wilt bijwerken, gebruikt u de HTTP PATCH-opdracht als volgt.

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

U kunt het volgende instellen:

URI-parameters

naam	in	Vereist	type	Beschrijving
artifactId	pad	WAAR	snaar	Artifact-id van het pakket
voeden	pad	WAAR	tekenreeks	Naam of id van de feed
groepId	pad	WAAR	string	Groeps-ID van het pakket
collectie	pad	WAAR	tekenreeks	De naam van de Azure DevOps-verzameling
Versie	pad	WAAR	touwtje	Versie van het pakket
project	pad		koord	Project-id of projectnaam
api-version	vraag	WAAR	snaar	De versie van de API die moet worden gebruikt. Dit moet worden ingesteld op '5.1-preview.1' om deze versie van de API te gebruiken

aanvraaginhoud

naam	type	Beschrijving
Weergaven	JsonPatchOperation-	De weergave waaraan de pakketversie wordt toegevoegd

Raadpleeg de REST API-documentatie naarmate deze wordt bijgewerkt voor meer informatie.

feedback

We horen graag van u! U kunt een probleem melden of een idee geven en dit bijhouden via Developer Community- en advies krijgen over Stack Overflow-.

---

boven aan pagina