Azure DevOps-serviceupdates en integratieverbeteringen

Om ervoor te zorgen dat uw Azure DevOps-omgeving veilig blijft, maken we belangrijke service-updates. Dit omvat het beëindigen van de ondersteuning voor nieuwe OAuth-app-registraties vanaf april 2025, hoewel bestaande apps blijven werken totdat deze in 2026 volledig zijn beëindigd. Daarnaast is servernaamindicatie (SNI) vereist voor alle HTTPS-verbindingen vanaf 23 april 2025, en samen met updates voor TFVC check-in beleid in Azure Repos.

Naast deze updates kondigen we de nieuwste verbeteringen aan in onze Azure Boards + GitHub-integratie, waardoor het eenvoudiger is om branches, pull-aanvragen en commits te verbinden met werkitems. Bovendien bieden pijplijnen nu meer inzicht in afhankelijkheden van YAML-fasen, waardoor teams complexere werkstromen kunnen beheren met verbeterde efficiëntie.

Bekijk de releaseopmerkingen voor meer informatie.

Algemeen

• Geen nieuwe Azure DevOps OAuth-apps vanaf april 2025
• Servernaamindicatie (SNI) is nu verplicht voor Azure DevOps Services

Azure Boards:

• GitHub-integratie: Verbeteringen die zijn gekoppeld aan commits, branches en pull requests
• GitHub-integratie: buildstatus voor YAML-pijplijnen weergeven
• Limiet voor leveringsplannen verhoogd

Azure Repositories

• Wijzigingen in TFVC check-inbeleid
• Uitbreiding van GetRepository-API
• Uitbreiding van query-API voor pull-aanvragen

Azure-pipelines

• Verbeterde zichtbaarheid van afhankelijkheden van YAML-pijplijnfasen
• Nieuwe Agent CDN
• Node 16 wordt verwijderd uit pijplijnen-* Pijplijnagentpakketten

Azure-testplannen:

• Buitengebruikstelling van actielogboekregistratie en overschakelen naar schermopname
• Handmatige testuitvoering automatisch onderbreken

Algemeen

Geen nieuwe Azure DevOps OAuth-apps vanaf april 2025

Vanaf april 2025 ondersteunen we geen nieuwe registraties meer van Azure DevOps OAuth-apps. Dit is een eerste stap in de richting van onze langetermijnvisie voor het buiten gebruik stellen van het Azure DevOps OAuth-platform. We raden alle ontwikkelaars aan toepassingen te bouwen met Azure DevOps REST API's door het Microsoft Identity Platform te verkennen en vervolgens een nieuwe Entra-toepassing te registreren.

Alle bestaande Azure DevOps OAuth-apps blijven werken tot de officiële buitengebruikstelling van het platform in 2026. Meer informatie vindt u hier in onze blogpost.

Servernaamindicatie (SNI) is nu verplicht voor Azure DevOps Services

Vanaf 23 april 2025 is servernaamindicatie (SNI) vereist voor alle binnenkomende HTTPS-verbindingen met Azure DevOps Services.

SNI is een extensie voor het TLS-protocol waarmee clients de hostnaam kunnen opgeven waarmee ze verbinding maken. Alle moderne browsers en clientsoftware ondersteunen SNI en gebruiken deze standaard, waardoor de meeste gebruikers naadloos kunnen overstappen. In feite is meer dan 99.995% van het klantverkeer dat onze servers bereikt SNI-gereed.

Sommige clientsoftware is echter mogelijk niet compatibel met SNI vanwege verschillende factoren, zoals verouderd, onjuist geconfigureerde netwerkbibliotheken, runtimes of besturingssystemen. Er kunnen ook problemen optreden met proxy's of NGFW-firewalls. De volgende hulpprogramma's die worden gebruikt met Azure DevOps, kunnen worden beïnvloed door SNI-problemen:

• Gitclients
• IDE-invoegtoepassingen en -extensies (Team Explorer Everywhere)
• Software die wordt uitgevoerd op oudere Java-versies die geen ondersteuning bieden voor SNI (Java 6 en eerder) of waarvoor SNI niet standaard is ingeschakeld (sommige versies van Java 7 en 8)
• Oude browserversies (zie https://caniuse.com/sni)

SNI-problemen worden meestal weergegeven door verbindingsfouten, zoals:

• ERR_SSL_PROTOCOL_ERROR (SSL-protocolfout), ERR_CERT_COMMON_NAME_INVALID (Ongeldige gemeenschappelijke naam voor certificaat)
• javax.net.ssl.SSLHandshakeException, javax.net.ssl.SSLException
• Kan geen vertrouwensrelatie tot stand brengen voor het beveiligde SSL/TLS-kanaal

U kunt de SNI-compatibiliteit van uw systeem valideren door het statuseindpunt van Azure DevOps aan te roepen, die we hebben geconfigureerd om SNI te vereisen. Als deze aanroep is geslaagd, geeft deze aan dat de host, inclusief het besturingssysteem en de netwerkomgeving, SNI-compatibel is. Ga naar onze blogpost voor gedetailleerde instructies over het testen.

Azure Boards

GitHub-integratie: Verbeteringen die verband houden met commits, branches en pull requests

We verbeteren voortdurend de Boards + GitHub-integratie om de bruikbaarheidsgaten te sluiten en af te stemmen op de ervaring waarmee u bekend bent in Azure-opslagplaatsen.

Met deze update hebben we verschillende verbeteringen geïntroduceerd om het proces van het koppelen van vertakkingen, pull-aanvragen en commits aan werkitems te stroomlijnen.

• Wanneer een GitHub-vertakking is gekoppeld aan een werkitem, worden alle gekoppelde pull-aanvragen nu automatisch gekoppeld. U hoeft AB# niet handmatig te gebruiken.

• Zodra een pull-aanvraag is samengevoegd, wordt de samenvoegdoorvoering automatisch gekoppeld aan het werkitem.

• Als de vertakking wordt verwijderd nadat de pull-aanvraag is samengevoegd, wordt de vertakkingskoppeling automatisch verwijderd uit het werkitem.

Deze verbeteringen maken het gemakkelijker om de voortgang van uw ontwikkeling bij te houden en schone, up-to-datum werkitemkoppelingen te onderhouden.

GitHub-integratie: buildstatus voor YAML-pijplijnen weergeven

We streven ernaar om functiepariteit te bereiken tussen YAML en klassieke pijplijnen. Een belangrijke ontbrekende functie was de mogelijkheid om een koppeling 'Geïntegreerd in build' te bieden wanneer uw opslagplaats wordt gehost in GitHub. Met onze nieuwste release hebben we deze kloof opgelost door een optie toe te voegen in YAML-pijplijninstellingen om het volgende te controleren:

Zodra de build is voltooid, wordt de bijbehorende koppeling automatisch weergegeven op de bijbehorende werkitems, waardoor het algehele traceerbaarheidsverhaal wordt verbeterd.

Limiet voor leveringsplannen verhoogd

Voorheen beperkten we de leveringsplannen per project tot 1000. Met deze update hebben we het maximum aantal leveringsplannen per project verhoogd naar 1500. Meer informatie over het toevoegen en bewerken van leveringsplannen vindt u hier in de documentatie.

Azure Repositories

Wijzigingen in TFVC-incheckbeleid

Nieuwe versie (19.255.0-preview) van Microsoft.TeamFoundationServer.ExtendedClient NuGet-pakket

Het NuGet-pakket Microsoft.TeamFoundationServer.ExtendedClient is bijgewerkt met nieuwe TFVC-beleidsklassen en -methoden.

Beleidswijzigingen

Er worden wijzigingen aangebracht in de manier waarop TFVC-check-inbeleid wordt opgeslagen in Azure DevOps. Dit betekent ook dat updates worden doorgevoerd in de manier waarop de NuGet Microsoft.TeamFoundationServer.ExtendedClient communiceert met de service.

Als uw TFVC-project gebruikmaakt van beleid voor inchecken, migreert u deze beleidsregels naar de nieuwe indeling. U kunt dit op twee manieren doen:

1. Visual Studio gebruiken.

Als u nieuwe beleidsregels wilt maken met behulp van visual Studio-projectbeheerder, moet u Instellingen -> Teamproject -> Broncodebeheer -> Incheckenbeleid en nieuw beleid toevoegen (zonder 'Verouderd'-markering) met dezelfde parameters als oud:

2. Als u een aangepaste implementatie van Microsoft.TeamFoundationServer.ExtendedClient gebruikt om met de server te communiceren, volg dan de migratiehandleiding.

De migratie is vereist om TFVC-check-in compatibel te houden met de toekomstige Azure DevOps-versies. Voorlopig blijven zowel oud (verouderd) als nieuw beleid geldig en functioneel. Zie onze blogpost voor meer informatie over de toekomstige plannen.

Uitbreiding van GetRepository-API

We hebben de eigenschap toegevoegd creationDate aan het antwoord van Opslagplaatsen: de opslagplaats-API ophalen die de aanmaakdatum van de opslagplaats retourneert. De eigenschap is beschikbaar in de API-versies 7.2-preview en hoger.

Uitbreiding van query-API voor pull-aanvragen

We hebben een nieuwe Label-eigenschap geïntroduceerd in het antwoord van de Pull-aanvraagquery - Get API. U kunt nu opgeven of labels (tags) moeten worden opgenomen voor gerelateerde pull-aanvragen in elke query. Er is een nieuwe Include eigenschap beschikbaar - als deze is ingesteld op Labels, bevat de respons labels voor de opgegeven PR's. Als het als null wordt gelaten, worden labels niet opgenomen. Als u onbedoelde fouten wilt voorkomen, moet u ervoor zorgen dat deze NotSet niet expliciet is toegewezen. Dit resulteert in Bad Request.

Voorbeeld van nettolading aanvragen:

{
    "queries": [
        {
            "type": "lastMergeCommit",
            "include": "Labels",
            "items": [ 
                "0d6c9b2b524113113fced41aecbf8631a4649dec"
            ]
        },
        {
            "type": "lastMergeCommit",
            "items": [
                "b524113113f0dd41aecbf8631a4649dec6c9b2ce"
            ]
        }
    ]
}

Azure-pipelines

Verbeterde zichtbaarheid van afhankelijkheden van YAML-pijplijnfasen

YAML-pijplijnen bieden flexibiliteit voor het beheren van complexe werkstromen, maar het visualiseren van faseafhankelijkheden is een uitdaging geweest, met name in implementaties in meerdere regio's.

Het is niet altijd duidelijk geweest hoe fasen zijn verbonden. Als u bijvoorbeeld bepaalt of CUS3 afhankelijk is van WUS1, naast WUS2 en WUS3, moet de YAML rechtstreeks worden gecontroleerd.

Met deze sprint worden faseafhankelijkheden nu weergegeven wanneer een fase wordt uitgebreid, zodat u direct inzicht krijgt in de uitvoeringsvolgorde en upstreamvereisten.

Nieuwe agent CDN

Omdat Edgio CDN buiten gebruik wordt gesteld, wordt de domein-URL die eigendom is van Edgio https://vstsagentpackage.azureedge.net ook buiten gebruik gesteld. We voegen een nieuwe domein-URL https://download.agent.dev.azure.com toe die wordt ondersteund door het nieuwe CDN. Zorg ervoor dat u deze nieuwe domein-URL toevoegt aan de acceptatielijst van uw firewall. Downloads van agentpakketten voor zelf-hostende agents mislukken zodra de oude domein-URL is verwijderd. Raadpleeg het bericht voor meer informatie.

Node 16 wordt verwijderd uit pipelines-* Pijplijnagent-pakketten

Agenttaken kunnen worden geïmplementeerd in PowerShell of Node. De agent maakt meerdere versies van Node beschikbaar waarop taken kunnen worden gericht.

Wanneer er nieuwe Node-versies worden uitgebracht, worden taken bijgewerkt voor het gebruik van nieuwe Node-versies. De runtimecomponenten zijn bij de agent inbegrepen.

Naarmate Nodeversies buiten het upstream-onderhoudsvenster raken, blijven sommige pijplijntaken er nog steeds van afhankelijk. Azure DevOps werkt ondersteunde taken bij naar een ondersteunde Node-versie. Taken van derden hebben mogelijk nog steeds oudere Node-versies nodig voor uitvoering.

Hiervoor hebben we twee typen Pijplijnagentpakketten:

Als u een taak wilt uitvoeren waarvoor de Node 16-uitvoeringshandler is vereist op een agent waar Node 16 niet gebundeld is, kunt u de uitvoeringshandler installeren door de taak NodeTaskRunnerInstaller@0 in uw pijplijn in te voegen.

  steps:
  - task: NodeTaskRunnerInstaller@0
    inputs:
      runnerVersion: 16

Azure Test Plans (testplannen van Azure)

Buitengebruikstelling van actielogboekregistratie en overschakelen naar schermopname

Onze Desktop Azure Test Runner-client is afhankelijk van probleemstappenrecorder (PSR), een hulpprogramma dat is geïntroduceerd in Windows 7 die nu wordt afgeschaft in nieuwere Windows-versies. Als gevolg hiervan werkt de functionaliteit van het actielogboek in onze desktoptestloper mogelijk niet meer in toekomstige updates.

Om een ononderbroken testtracking te garanderen, raden we u aan over te schakelen naar schermopname in onze webrunner, Test & Feedback Extension, die een moderne, betrouwbare manier biedt om teststappen vast te leggen en te beheren. Neem contact op met ons ondersteuningsteam als u hulp nodig hebt bij de overgang naar de Test & Feedback-extensie.

Handmatige testuitvoering automatisch onderbreken

Verlies nooit uw voortgang in testruns dankzij automatisch pauzeren van de testcase-uitvoering. Met deze nieuwe functie wordt de uitvoering van uw testcase automatisch onderbroken als uw werk wordt onderbroken, zodat gedeeltelijke voortgang wordt opgeslagen zonder dat u handmatig hoeft te onderbreken. Of u nu de sessie stapt of sluit, u kunt uw testcase eenvoudig hervatten waar u was gebleven, waardoor het risico op gegevensverlies wordt verminderd en uw werkstroom wordt verbeterd. Door het gebruik van de automatische pauzefunctie, die het proces van pauzeren en hervatten vereenvoudigt, kunt u zich concentreren op testen zonder dat u zich zorgen hoeft te maken over het verliezen van uw voortgang. Probeer het eens en laat het ons weten via e-mail wat u ervan vindt!

Volgende stappen

Ga naar Azure DevOps en kijk eens.

Feedback geven

We horen graag wat u van deze functies vindt. Gebruik het Help-menu om een probleem te melden of een suggestie op te geven.

U kunt ook advies krijgen en uw vragen beantwoorden door de community op Stack Overflow.

Bedankt

Gepleiu Andrica