Releaseopmerkingen voor Azure DevOps Server 2022 Update 2
| Developer Community | Systeemvereisten en Compatibiliteit | Licentievoorwaarden | DevOps Blog | SHA-256 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 Server-producten wilt downloaden, gaat u naar de pagina Downloads van Azure DevOps Server.
Directe upgrade naar Azure DevOps Server 2022 Update 2 wordt ondersteund vanuit Azure DevOps Server 2019 of Team Foundation Server 2015 of hoger. Als uw TFS-implementatie zich op TFS 2013 of eerder bevindt, moet u enkele tussentijdse stappen uitvoeren voordat u een upgrade uitvoert naar Azure DevOps Server 2022. Zie de installatiepagina voor meer informatie.
Releasedatum van Azure DevOps Server 2022 Update 2 Patch 3: 11 februari 2025
Notitie
Op maandag 24 februari 2025 hebben we Patch 3 voor Azure DevOps Server 2022.2 opnieuw uitgebracht. Als u de eerdere versie van deze patch eerder hebt geïnstalleerd, werkt u deze bij met behulp van de opgegeven koppeling. Met deze nieuwe release wordt een probleem opgelost waardoor YAML-pijplijnen mislukken. Meer informatie over het probleem vindt u in de Developer Community.
| Bestand | SHA-256-hash |
|---|---|
| devops2022.2patch3 | F5C2DA846B8A38A1FB55D1EB555FB2FD6B974B0436F573CC01A0FEBAF3D67521 |
We hebben Patch 3 uitgebracht voor Azure DevOps Server 2022 Update 2 om het volgende op te nemen:
- Updates in Artifacts om Python Enhancement Proposals (PEPs) 685toe te voegen. Dit bijgewerkte adres bevat feedback die wordt gedeeld in de Developer Community.
Releasedatum van Azure DevOps Server 2022 Update 2 Patch 2: 12 november 2024
| Bestand | SHA-256-hash |
|---|---|
| devops2022.2patch2.exe | 70930BE091607B490890A48C250DAB6C2087F7F610CC695C9C632C679A491D23 |
We hebben Patch 2 uitgebracht voor Azure DevOps Server 2022 Update 2 om een upgrade naar een kwetsbare afhankelijkheid op te nemen.
Releasedatum van Azure DevOps Server 2022.2 RTW: 9 juli 2024
Samenvatting van wat is er nieuw in Azure DevOps Server 2022.2 RTW
Notitie
We hebben Azure DevOps Server 2022.2 opnieuw uitgebracht om een probleem met het laden van Teams-namen op te lossen. Het probleem is gemeld in het blogbericht 'Azure DevOps Server 2022.2 RTW nu beschikbaar'. Als u de versie van Azure DevOps Server 2022.2 hebt geïnstalleerd die op 9 juli is uitgebracht, kunt u Patch 1 voor Azure DevOps Server 2022.2 installeren om het probleem op te lossen. Patch 1 is niet vereist als u Azure DevOps Server 2022.2 voor het eerst installeert sinds de downloadkoppelingen zijn bijgewerkt om de oplossing op te nemen.
Azure DevOps Server 2022.2 RTW is een verzameling van bugfixes. Het bevat alle functies in de Azure DevOps Server 2022.2 RC eerder uitgebracht. U kunt Azure DevOps Server 2022.2 rechtstreeks installeren of upgraden van Azure DevOps Server 2020, 2019 of Team Foundation Server 2015 of hoger. De volgende problemen en beveiligingsproblemen zijn opgelost met deze release:
- CVE-2024-35266: Beveiligingsprobleem met Spoofing van Azure DevOps Server
- CVE-2024-35267: Beveiligingsprobleem met Spoofing van Azure DevOps Server
- feedbackticket voor ontwikkelaarscommunity: agentversie wordt niet bijgewerkt na een upgrade naar Azure DevOps Server 2022.1 en het gebruik van updateagent in agentgroepconfiguratie
- Feedbackticket voor Ontwikkelaarscommunity: Probleem met het laden van de Teamconfiguratiepagina
- feedbackticket voor de ontwikkelaarscommunity: onjuiste datumverwerking in PR-e-mailmeldingen voor bepaalde regionale indelingen oplossen
Releasedatum van Azure DevOps Server 2022 Update 2 RC: 7 mei 2024
Azure DevOps Server 2022.2 RC bevat veel nieuwe functies. Enkele van de hoogtepunten zijn:
- limieten voor gebieds- en iteratiepaden
- Goedkeuringen en controles in pijplijnen overslaan
- verbeterde YAML-validatie
- Azure Artifacts-ondersteuning voor Cargo Crates
- nieuwe dashboarddirectory-ervaring
- Snel Kopiëren en Importeren met Testplan of Suite-ID
U kunt ook naar afzonderlijke secties gaan om alle nieuwe functies voor elke service te bekijken:
Algemeen
Testresultatentaak publiceren
De taak Testresultaten publiceren ondersteunt nu testuitvoeringsbijlagen voor de JUnit-rapportindeling.
Nieuwe versie van de Azure DevOps Web Extension SDK
Met deze update brengen we een nieuwe versie van de Azure DevOps Web Extension SDK uit. Met de client-SDK kunnen webextensies communiceren met het hostframe. Deze kan worden gebruikt voor het volgende:
- Stel de host op de hoogte dat de extensie is geladen of fouten bevat
- Basiscontextuele informatie over de huidige pagina ophalen (informatie over huidige gebruiker, host en extensie)
- Themagegevens ophalen
- Een autorisatietoken verkrijgen voor gebruik in REST-aanroepen terug naar Azure DevOps
- Externe services ophalen die worden aangeboden door het hostframe
U vindt een volledige API-verwijzing in de documentatie voor het azure-devops-extension-sdk-pakket. Deze nieuwe versie biedt ondersteuning voor de volgende modules:
ondersteuning voor ES-modules: SDK ondersteunt nu ES-modules (ECMAScript) naast de bestaande AMD-modules (Asynchronous Module Definition). U kunt de SDK nu importeren met behulp van de syntaxis van de ES-module, die prestatieverbeteringen biedt en de toepassingsgrootte vermindert.
Terugwaartse compatibiliteit voor AMD-modules: Bestaande ondersteuning voor AMD-modules blijft intact. Als uw project AMD-modules gebruikt, kunt u deze blijven gebruiken zoals voorheen zonder wijzigingen.
Hoe te gebruiken:
Voor ES-modules kunt u onze modules importeren met behulp van de importinstructie:
import * as SDK from 'azure-devops-extension-sdk';
// Use the module here
Als u AMD-modules gebruikt, kunt u de SDK blijven importeren met behulp van de require-functie:
require(['azure-devops-extension-sdk'], function(SDK) {
// Use the module here
});
Planken
Limieten voor gebieds- en iteratiepaden
Limieten spelen een belangrijke rol bij het handhaven van de gezondheid en efficiëntie van een grote, wereldwijde service. Met deze release introduceren we vaste limieten van 10.000 per project voor zowel gebieds- als iteratiepaden. Ga naar de pagina Werktracking, proces en projectlimieten voor meer informatie over verschillende limieten in de service.
Besturingselementen voor ontwikkeling en implementatie
We verwijderen nu de besturingselementen Ontwikkeling en/of Implementatie uit het werkitem, afhankelijk van hoe uw project is geconfigureerd. U kunt bijvoorbeeld uw projectinstellingen configureren om repositories en/of pipelines uit te schakelen.
Wanneer u naar het werkitem gaat, worden de bijbehorende besturingselementen voor ontwikkeling en implementatie verborgen in het formulier.
Als u besluit een GitHub-opslagplaats te verbinden met Azure Boards, wordt het besturingselement Ontwikkeling voor GitHub-opslagplaatsen weergegeven.
Repos
Nieuw vertakkingsbeleid waardoor gebruikers hun eigen wijzigingen niet kunnen goedkeuren
Om de controle te verbeteren over de wijzigingen die de gebruiker goedkeurt en voldoet aan strengere wettelijke/nalevingsvereisten, bieden we een optie om te voorkomen dat de gebruiker zijn eigen wijzigingen goedkeurt, tenzij dit expliciet is toegestaan.
Gebruiker met de mogelijkheid om het vertakkingsbeleid te beheren, kan nu de zojuist toegevoegde optie 'Ten minste één goedkeuring vereisen voor elke iteratie' onder 'Wanneer nieuwe wijzigingen worden gepusht' overschakelen. Wanneer deze optie is geselecteerd, is ten minste één goedkeuringsstem vereist voor de laatste wijziging van de bronbranch. De goedkeuring van de gebruiker wordt niet meegeteld bij een eerdere niet-goedgekeurde iteratie die door die gebruiker wordt gepusht. Als gevolg hiervan is aanvullende goedkeuring vereist voor de laatste iteratie door een andere gebruiker.
In de volgende afbeelding ziet u een pull-aanvraag die is gemaakt door gebruiker A en 4 doorvoeringen (iteraties) die zijn gemaakt voor die pull-aanvraag door gebruikers B, C, A en C. Nadat de tweede iteratie (doorvoer uitgevoerd door gebruiker B) is uitgevoerd, heeft gebruiker C dat goedgekeurd. Op dat moment werd goedkeuring van de eerste commit van gebruiker A geïmpliceerd (toen het pull-verzoek werd aangemaakt) en zal het pas geïntroduceerde beleid van kracht worden. Na de vijfde iteratie (laatste doorvoering van gebruiker C) is de goedkeuring uitgevoerd door gebruiker A. Deze impliciete goedkeuring voor eerdere doorvoering door gebruiker C, maar impliceerde geen goedkeuring voor de tweede door gebruiker A uitgevoerde doorvoer in de vierde iteratie. Als u het zojuist geïntroduceerde beleid wilt voltooien, moet de niet-goedgekeurde iteratie vier worden goedgekeurd door goedkeuring van gebruiker B, C of een andere gebruiker die geen wijzigingen heeft aangebracht in de pull-aanvraag.
Notitie
Er is een bekend probleem waarbij branch policies een groep, die is geconfigureerd als recensent, als goedkeuringsentiteit neemt. Stel dat er een vereiste goedkeuring is die wordt uitgevoerd door een gebruiker van Groep G. Gebruiker A is lid van die groep G. Nadat gebruiker A goedkeuring heeft gegeven zoals in de bovenstaande afbeelding (na de vijfde iteratie), keurt de groeps-G-goedkeuring de wijziging goed die door gebruiker A wordt uitgevoerd. Dit wordt niet verwacht en wordt opgelost in de RTW-release.
Ondersteuning voor filter zonder blob en zonder boomstructuur
Belangrijk
De functie is standaard uitgeschakeld. Als u de functie wilt inschakelen, voert u de volgende query uit op de configuratiedatabase:
exec prc_SetRegistryValue 1,'#\FeatureAvailability\Entries\Git.EnablePartialClone\AvailabilityState\', 1
Azure DevOps ondersteunt nu twee extra filters tijdens het klonen/ophalen. Dit zijn:
--filter=blob:none en
--filter=tree:0 De eerste optie (blobloze kloon) wordt het beste gebruikt voor regelmatige ontwikkeling, terwijl de tweede optie (boomloze kloon) beter geschikt is voor die gevallen waarin u de kloon verwijdert, bijvoorbeeld na het uitvoeren van een build.
SSH-RSA veroudering
Azure-opslagplaatsen bieden twee methoden voor gebruikers om toegang te krijgen tot een Git-opslagplaats in Azure-opslagplaatsen: HTTPS en SSH. Als u SSH wilt gebruiken, moet u een sleutelpaar maken met een van de ondersteunde versleutelingsmethoden. In het verleden ondersteunen we alleen SSH-RSA en hebben we gebruikers gevraagd de SSH-RSA hier in te schakelen.
Met deze update kondigen we de afschaffing van SSH-RSA aan als een ondersteunde versleutelingsmethode voor het maken van verbinding met Azure-opslagplaatsen met behulp van SSH. Meer informatie vindt u in het einde van SSH-RSA ondersteuning voor Azure-opslagplaatsen blogbericht.
Pijpleidingen
Onbedoelde pijplijnuitvoeringen voorkomen
Als uw YAML-pijplijn momenteel geen trigger sectie opgeeft, wordt deze uitgevoerd voor wijzigingen die naar de opslagplaats zijn gepusht. Dit kan verwarring veroorzaken over waarom een pijplijn is uitgevoerd en kan leiden tot veel onbedoelde uitvoeringen.
We hebben een instelling op zowel verzamelingsniveau als projectniveau voor Pipelines toegevoegd met de naam Impliciete YAML CI-trigger uitschakelen, waarmee u dit gedrag kunt wijzigen. U kunt ervoor kiezen om pijplijnen niet te activeren als hun triggersectie ontbreekt.
Probeer een fase opnieuw wanneer de goedkeuringen en controles verlopen.
Bij een time-out van goedkeuringen en controles wordt de fase waartoe ze behoren overgeslagen. Fasen met een afhankelijkheid van de overgeslagen fase worden ook overgeslagen.
U kunt nu een fase opnieuw proberen wanneer er een time-out optreedt voor goedkeuringen en controles. Voorheen was dit alleen mogelijk toen er een time-out optreedt voor een goedkeuring.
Goedkeuringen en controles overslaan
Goedkeuringen en Controles helpen bij het beveiligen van de toegang tot belangrijke resources, zoals serviceverbindingen, repositories of agentpools. Een veelvoorkomende use-case is het gebruik van goedkeuringen en controles bij de implementatie in productie en u wilt de ARM-serviceverbinding beveiligen.
Stel dat u de volgende controles voor de serviceverbinding hebt toegevoegd: een goedkeuring, een controle op kantooruren en een Azure-functiecontrole aanroepen (om een vertraging tussen verschillende regio's af te dwingen).
Stel dat u een hotfix-implementatie moet uitvoeren. U start een pijplijnrun, maar het gaat niet verder; het wacht tot de meeste controles zijn voltooid. U kunt zich niet veroorloven te wachten tot de goedkeuringen en controles zijn voltooid.
Met deze release hebben we het mogelijk gemaakt om actieve goedkeuringen en controles te omzeilen, zodat u uw hotfix kunt voltooien.
U kunt lopende goedkeuringen, kantooruren, Azure-functie-aanroepen en REST API-aanroepen overslaan.
Een goedkeuring omzeilen.
Sla controle kantooruren over.
Azure Function-controle overslaan. Omzeilen controle van kantooruren.
Wanneer een controle wordt overgeslagen, kunt u deze zien in het deelvenster Controles.
U kunt een controle alleen omzeilen als u een beheerder bent van de resource waarvoor de controles zijn gedefinieerd.
Azure-functiecontroles opnieuw uitvoeren
Stel dat u uw systeem in meerdere fasen implementeert. Voordat u de tweede fase implementeert, is er een goedkeuringscontrole en een Azure-functiecontrole die een geloofwaardigheidscontrole uitvoeren op het reeds geïmplementeerde deel van het systeem.
Wanneer u de goedkeuringsaanvraag bekijkt, ziet u dat de saniteitscontrole twee dagen eerder is uitgevoerd. In dit scenario bent u mogelijk op de hoogte van een andere implementatie die het resultaat van de sanity-controle heeft beïnvloed.
Met deze update kunt u Azure-functie opnieuw uitvoeren en REST API-controles aanroepen. Deze functionaliteit is alleen beschikbaar voor controles die zijn geslaagd en waarvoor geen nieuwe pogingen zijn gedaan.
Notitie
U kunt een controle alleen opnieuw uitvoeren als u een beheerder bent van de resource waarop de controles zijn gedefinieerd.
Ondersteuning voor GitHub Enterprise-server in vereiste sjablooncontrole
Sjablonen zijn een beveiligingsmechanisme waarmee u de fasen, taken en stappen van pijplijnen in uw projectcollectie kunt beheren.
Met de Sjablooncontrole vereisen kunt u afdwingen dat een pijplijn voortbouwt op een set goedgekeurde sjablonen voordat u toegang krijgt tot een beveiligde resource, zoals een agentpool of serviceverbinding.
U kunt nu sjablonen opgeven die zich in gitHub Enterprise Server-opslagplaatsen bevinden.
Beheerdersrol voor alle omgevingen
Omgevingen in YAML-pijplijnen vertegenwoordigen een rekenresource waarnaar u uw toepassing implementeert, bijvoorbeeld een AKS-cluster of een set virtuele machines. Ze bieden u beveiligingscontroles en traceerbaarheid voor uw implementaties.
Het beheren van omgevingen kan behoorlijk lastig zijn. Dit komt doordat wanneer een omgeving wordt gemaakt, de persoon die deze maakt, automatisch de enige beheerder wordt. Als u bijvoorbeeld de goedkeuringen en controles van alle omgevingen op gecentraliseerde wijze wilt beheren, moet u elke omgevingsbeheerder vragen om een specifieke gebruiker of groep toe te voegen als beheerder en vervolgens REST API gebruiken om de controles te configureren. Deze aanpak is tijdrovend, foutgevoelig en schaalt niet wanneer er nieuwe omgevingen worden toegevoegd.
In deze release hebben we een beheerdersrol toegevoegd op het niveau van de omgevingshub. Dit brengt omgevingen op niveau met serviceverbindingen of agentpools. Als u de beheerdersrol wilt toewijzen aan een gebruiker of groep, moet u al een omgevingshubbeheerder of eigenaar van een projectverzameling zijn.
Een gebruiker met deze beheerdersrol kan machtigingen beheren, beheren, weergeven en gebruiken in elke omgeving. Dit omvat het openen van omgevingen voor alle pijplijnen.
Wanneer u een gebruikersbeheerderrol op omgevingsniveau verleent, worden ze beheerders voor alle bestaande omgevingen en voor toekomstige omgevingen.
Verbeterde YAML-validatie
Als u wilt controleren of de YAML-syntaxis juist is, kunt u de functionaliteit van de Azure Pipelines-webeditor gebruiken Valideren. Daarom is het belangrijk dat deze functionaliteit zoveel mogelijk YAML-problemen ondervangt.
YAML-validatie is nu grondiger als het gaat om expressies.
Wanneer u YAML-pijplijnen schrijft, kunt u functies gebruiken om variabele waarden te definiëren.
Stel dat u de volgende variabelen definieert:
variables:
Major: '1'
Minor: '0'
Patch: $[counter(fromat('{0}.{1}', variables.Major, variables.Minor ), 0)]
De Patch variabele wordt gedefinieerd met behulp van de functie counter en de andere twee variabelen. In de bovenstaande YAML-code is het woord format onjuist gespeld. Deze fout is eerder niet gedetecteerd. De Valideer functionaliteit detecteert dit en geeft een foutbericht weer.
Azure Pipelines detecteert onjuiste variabeledefinities op pijplijn-/fase-/taakniveau.
In YAML-pijplijnen kunt u de uitvoering van de fase overslaan met behulp van voorwaarden. Typfouten kunnen hier ook worden weergegeven, zoals in het volgende voorbeeld.
steps:
- task: NuGetCommand@2
condition: eq(variable.Patch, 0)
inputs:
command: pack
versioningScheme: byPrereleaseNumber
majorVersion: '$(Major)'
minorVersion: '$(Minor)'
patchVersion: '$(Patch)'
De NuGetCommand taak wordt alleen uitgevoerd als de waarde van de Patch variabele 0 is. Nogmaals, er is een typefout in de voorwaarde, en de Valideer functionaliteit zal deze weergeven.
Azure Pipelines detecteert onjuiste YAML-voorwaarden die zijn gedefinieerd op pijplijn-/fase-/taakniveau.
REST API's voor omgevingen
Een Environment is een verzameling resources waarnaar u implementaties vanuit een pijplijn kunt richten. Omgevingen bieden u de implementatiegeschiedenis, traceerbaarheid voor werkitems en doorvoeringen en mechanismen voor toegangsbeheer.
Wij weten dat u omgevingen programmatischwilt maken, dus hebben we documentatie gepubliceerd voor de REST API.
Verbeteringen aan de REST API voor goedkeuringen
We hebben het zoeken naar goedkeuringen verbeterd die zijn toegewezen aan een gebruiker door de groepen op te slaan waartoe de gebruiker behoort in de zoekresultaten.
Goedkeuringen bevatten nu informatie over de pijplijnuitvoering waartoe ze behoren.
De volgende GET REST API-aanroep https://fabrikam.selfhosted/fabrikam/FabrikamFiber/_apis/pipelines/approvals?api-version=7.2-preview.2&top=1&assignedTo=john@fabrikam.com&state=pending retourneert bijvoorbeeld
{
"count": 1,
"value":
[
{
"id": "7e90b9f7-f3f8-4548-a108-8b80c0fa80e7",
"steps":
[],
"status": "pending",
"createdOn": "2023-11-09T10:54:37.977Z",
"lastModifiedOn": "2023-11-09T10:54:37.9775685Z",
"executionOrder": "anyOrder",
"minRequiredApprovers": 1,
"blockedApprovers":
[],
"_links":
{
"self":
{
"href": "https://dev.azure.com/fabrikam/26dcfaeb-d8fe-495c-91cb-fec4acb44fbb/_apis/pipelines/approvals/7e80b987-f3fe-4578-a108-8a80c0fb80e7"
}
},
"pipeline":
{
"owner":
{
"_links":
{
"web":
{
"href": "https://dev.azure.com/buildcanary/26dcfaeb-d8fe-495c-91cb-fec4acb44fbb/_build/results?buildId=73222930"
},
"self":
{
"href": "https://dev.azure.com/buildcanary/26dcfaeb-d8fe-495c-91cb-fec4acb44fbb/_apis/build/Builds/73222930"
}
},
"id": 73222930,
"name": "20231109.1"
},
"id": "4597",
"name": "FabrikamFiber"
}
}
]
}
Pijplijnlogboeken bevatten nu resourcegebruik
Azure-pijplijnlogboeken kunnen nu metrische gegevens over resourcegebruik vastleggen, zoals geheugen, CPU-gebruik en beschikbare schijfruimte. De logboeken bevatten ook resources die worden gebruikt door de pijplijnagent en onderliggende processen, waaronder taken die in een taak worden uitgevoerd.
Als u vermoedt dat uw pijplijntaak resourcebeperkingen kan ondervinden, schakelt u uitgebreide logboekregistratie in zodat informatie over het gebruik van resources in de pijplijnlogboeken wordt opgenomen. Dit werkt op elke agent, onafhankelijk van het hostingmodel.
Azure Pipelines-agent ondersteunt nu Alpine Linux
De Pijplijnagent v3.227 ondersteunt nu Alpine Linux versie 3.13 en hoger. Alpine Linux is een populaire basiscontainerafbeelding. U vindt de agent op de releases pagina. Alpine Linux-versies van de agent hebben een voorvoegsel vsts-agent-linux-musl bijvoorbeeld vsts-agent-linux-musl-x64-3.227.1.tar.gz.
Azure Pipelines-taken maken gebruik van Node 16
Taken in de pijplijn worden uitgevoerd met behulp van een runner, waarbij in de meeste gevallen Node.js wordt gebruikt. Azure Pipelines-taken die een Node als runner gebruiken, gebruiken nu allemaal Node 16. Omdat Node 16 de eerste Node-versie is voor systeemeigen ondersteuning voor Apple silicon, wordt hiermee ook volledige taakondersteuning voor macOS op Apple silicon voltooid. Agents die worden uitgevoerd op Apple silicon hebben Rosetta niet nodig om te draaien.
Naarmate de einddatum van 16 knooppunten vooruitis verplaatst, zijn we begonnen met het uitvoeren van taken met Node 20.
Verhoogde limieten voor Azure Pipeline om overeen te komen met de maximale grootte van Azure Resource Manager (ARM)-templates van 4 MB.
U kunt de Azure Resource Manager-sjabloonimplementatie taak gebruiken om een Azure-infrastructuur te maken. In reactie op uw feedback hebben we de integratielimiet van Azure Pipelines van 2 MB tot 4 MB verhoogd. Dit zal in lijn zijn met de maximale grootte van 4 MB van de ARM-sjablonen , waardoor groottebeperkingen worden opgelost tijdens de integratie van grote sjablonen.
AzureRmWebAppDeployment-taak biedt ondersteuning voor Microsoft Entra ID-verificatie
De taken AzureRmWebAppDeploymentV3 en AzureRmWebAppDeployment@4 zijn bijgewerkt ter ondersteuning van App Service met basisverificatie uitgeschakeld. Als basisverificatie is uitgeschakeld in de App Service, gebruiken de taken AzureRmWebAppDeploymentV3/4 Microsoft Entra ID-verificatie om implementaties uit te voeren op het App Service Kudu-eindpunt. Hiervoor is een recente versie van msdeploy.exe geïnstalleerd op de agent, wat het geval is op de Windows-2022/Windows-Latest Hosted agents (zie taakverwijzing).
Uitschakelen van het overschrijven van de status van het code-dekkingsbeleid naar Mislukt wanneer de build mislukt
Voorheen werd de status van het codedekkingsbeleid overschreven naar 'Mislukt' als uw build in pull-aanvraag mislukte. Dit was een blokkade voor sommigen van jullie die de build als een optionele controle hadden en het codedekkingsbeleid als een verplichte controle voor PR's, resulterend in PR's die worden geblokkeerd.
Het codedekkingsbeleid wordt nu niet overschreven naar 'Mislukt' als de build mislukt. Deze functie wordt ingeschakeld voor alle klanten.
Artefacten
Introductie van Azure Artifacts-ondersteuning voor ladingkratten
We zijn verheugd om aan te kondigen dat Azure Artifacts nu systeemeigen ondersteuning biedt voor Cargo-kratten. Deze ondersteuning omvat functiegelijkheid met betrekking tot onze bestaande protocollen, naast dat crates.io beschikbaar is als een upstream-bron. Rust-ontwikkelaars en -teams kunnen nu naadloos hun Cargo-kratten gebruiken, publiceren, beheren en delen, terwijl ze gebruikmaken van de robuuste infrastructuur van Azure en in de vertrouwde Azure DevOps-omgeving blijven.
Aankondiging van afschaffing voor NuGet Restore v1- en NuGet Installer v0-pijplijntaken
Als u de pijplijntaken NuGet Restore v1 en NuGet Installer v0 gebruikt, gaat u onmiddellijk over naar de NuGetCommand@2 pijplijntaak. U ontvangt binnenkort waarschuwingen in uw pijplijnen als de overgang nog niet is uitgevoerd. Als er geen actie wordt ondernomen, zullen uw builds vanaf 27 november 2023 mislukken.
Ondersteuning voor Azure Artifacts voor npm-controle
Azure Artifacts ondersteunt nu npm audit en npm audit fix opdrachten. Met deze functie kunnen gebruikers beveiligingsproblemen van hun project analyseren en oplossen door automatisch onveilige pakketversies bij te werken. Ga voor meer informatie naar Npm-audit gebruiken om beveiligingsproblemen in pakketten te detecteren en op te lossen.
Berichtgeving
Nieuwe dashboarddirectory-ervaring
We hebben naar uw feedback geluisterd en zijn blij om de nieuwe dashboarddirectory-ervaring te introduceren. Het bevat niet alleen een modern UI-ontwerp, maar u kunt ook sorteren op elke kolom, met de toevoeging van de laatst geconfigureerde kolom. In deze kolom krijgt u meer inzicht in het algehele dashboardgebruik in uw projectverzameling. Daarnaast kunt u nu filteren op dashboards op team- of projectniveau, zodat u alleen toegang hebt tot de lijst met wat u moet zien terwijl u de dashboards verbergt die u niet wilt weergeven.
Probeer het nu en laat ons weten wat u ervan vindt in onze Azure DevOps-community
Filteren van werkitems
We zijn blij om het filteren van werkitemgrafiek aan te kondigen. Met deze functie kunt u de muisaanwijzer over de grafiek met werkitems bewegen voor een snel overzicht en inzoomen op specifieke grafieksegmenten voor gedetailleerde inzichten. U hoeft geen aangepaste query's meer te maken om toegang te krijgen tot het exacte stukje gegevens dat u nodig hebt. U kunt nu in slechts een paar klikken toegang krijgen tot uw werkitems in werkitemgrafieken.
Uw feedback is van groot belang bij het vormgeven van de toekomst van deze functie. Probeer het nu en laat ons weten wat u ervan vindt in onze Azure DevOps-community.
Resultaten van codedekking voor mappen
Resultaten voor codedekking zijn nu beschikbaar voor elk afzonderlijk bestand en elke map in plaats van alleen als nummer op het hoogste niveau. De codedekkingsweergave wordt weergegeven wanneer de mapweergavemodus knop wordt ingeschakeld. In deze modus kunt u inzoomen en de codedekking voor die geselecteerde substructuur bekijken. Gebruik de wisselknop om te schakelen tussen de nieuwe en oude weergaven.
Testplannen
Snel kopiëren en invoeren met testplan- of suite-ID
U kunt nu eenvoudig meerdere testplannen in Azure Test Plans afhandelen. Als erkenning van de uitdagingen waarmee u eerder te maken had met lange vervolgkeuzelijsten voor het importeren, kopiëren of klonen van testcases, vooral bij uitgebreide plannen of suites, hebben we stappen ondernomen om uw werkstroom te stroomlijnen.
We zijn verheugd om de functie Testplan en Suite ID Search aan te kondigen. Voer uw testplan of suite-id in voor het snel importeren of kopiëren van testcases zonder vertragingen. Deze update maakt deel uit van onze doorlopende toezegging om uw testbeheerervaring te verbeteren, waardoor deze intuïtiever en minder tijdrovend is.
nl-NL: 
Update voor Azure Test Runner
We delen graag dat Azure Test Runner is bijgewerkt naar een nieuwere versie. Deze update verbetert de stabiliteit en prestaties, zodat u uw tests zonder onderbrekingen of vertragingen kunt uitvoeren. De oudere versie van Azure Test Runner wordt niet meer ondersteund. Voor de beste prestaties en betrouwbaarheid van uw testbewerkingen raden we u aan om zo snel mogelijk bij te werken naar de nieuwste versie.
Wat is er nieuw?
- Verbeterde stabiliteit en prestaties: We hebben aanzienlijke verbeteringen aangebracht in de Test Runner, waarbij problemen worden opgelost die sommige gebruikers hebben ervaren. Deze upgrade zorgt voor een betrouwbaarder testproces, waardoor onderbrekingen van uw werk worden geminimaliseerd.
- upgradeprompt: Om de overgang naar de nieuwe versie naadloos te maken, wordt u gevraagd om een upgrade uit te voeren. Dit zorgt ervoor dat iedereen gemakkelijk naar de verbeterde versie op uw gemak kan overstappen, waardoor de compatibiliteit en prestaties worden verbeterd.
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-.