Delen via


Instelling voor het uitschakelen van het maken van TFVC-opslagplaatsen

Met deze update introduceren we een nieuwe instelling om het maken van TFVC-opslagplaatsen uit te schakelen. Deze wijziging is gericht op nieuwe projecten en zorgt ervoor dat uw bestaande TFVC-opslagplaatsen niet worden beïnvloed.

Daarnaast kondigen we graag aan dat er in Azure Pipelines een nieuw REST API-eindpunt beschikbaar is voor het aanvragen van OIDC-tokens. Hierdoor kunnen taakontwikkelaars idTokens genereren voor Entra ID-verificatie, waardoor de beveiliging en het gebruiksgemak worden verbeterd.

Ten slotte kunnen in Azure Boards, gebieds- en iteratiepaden nu alleen worden verwijderd als ze niet meer zijn gekoppeld aan werkitems. Deze verbetering voorkomt onderbrekingen en zorgt ervoor dat teams toegang tot hun borden en achterstand behouden.

Bekijk de releaseopmerkingen voor meer informatie.

GitHub Advanced Security voor Azure DevOps

Azure Boards:

Azure-opslagplaatsen

Azure-pipelines

Azure Test Plans:

GitHub Advanced Security voor Azure DevOps

Api-documentatie voor beveiligingsoverzicht is nu beschikbaar

Documentatie voor de API die het tabblad Overzicht van geavanceerde beveiliging mogelijk maakt, is nu beschikbaar. Gebruik het eindpunt /{organization}/_apis/reporting/summary/alerts om een samenvatting te bekijken van waarschuwingskritiek in alle geavanceerde opslagplaatsen met beveiliging. Zorg ervoor dat uw ADO PAT beschikt over de vso.advsec machtiging, die de mogelijkheid verleent om waarschuwingen, resultatenexemplaren en instanties van analyseresultaten te lezen.

Azure Boards

Wijzigen voor het verwijderen van gebieds- en iteratiepaden

Het verwijderen van een gebied of iteratiepad kan verstorend zijn. Het kan werkitems naar een nieuw pad verplaatsen en kan ertoe leiden dat teams de toegang tot hun borden en achterstand verliezen. Ondanks waarschuwingen en prompts worden paden soms verwijderd zonder de gevolgen volledig te begrijpen. Om dit te verhelpen, hebben we het gedrag gewijzigd: paden naar gebieden en iteratie kunnen nu alleen worden verwijderd als ze niet meer worden gebruikt door werkitems.

Schermopnamen van het gebied verwijderen.

Azure-opslagplaatsen

Nieuwe instelling voor het uitschakelen van het maken van TFVC-opslagplaatsen

In de afgelopen jaren zijn er geen nieuwe functies toegevoegd aan Team Foundation Version Control (TFVC), omdat Git het voorkeursversiebeheersysteem is geworden in Azure-opslagplaatsen. Alle recente verbeteringen in beveiliging, prestaties en toegankelijkheid zijn uitsluitend aangebracht in Git-opslagplaatsen, wat leidt tot een continue afname van TFVC-gebruik. Hoewel sommige nog steeds afhankelijk zijn van TFVC en we niet van plan zijn om deze functieset te verwijderen, plannen we TFVC geleidelijk uit te fasering voor nieuwe projecten en organisaties, evenals voor projecten die momenteel geen TFVC gebruiken.

Als onderdeel van deze overgang introduceren we een nieuwe instelling voor het uitschakelen van het maken van TFVC-opslagplaatsen. Dit heeft alleen invloed op het maken van nieuwe TFVC-opslagplaatsen en heeft geen invloed op bestaande.

Gif om het maken van TFVC-opslagplaatsen uit te schakelen.

Azure-pipelines

Toegang krijgen tot Azure Service Bus vanuit pijplijnen met behulp van Microsoft Entra ID-verificatie

U kunt nu Microsoft Entra ID-verificatie gebruiken voor toegang tot Azure Service Bus vanuit Azure Pipelines. Hierdoor kunt u profiteren van workloadidentiteitsfederatie om geheimenbeheer en Azure RBAC te verwijderen voor fijnmazig toegangsbeheer.

Identiteiten die toegang hebben tot Azure Service Bus, moeten een van de ingebouwde Azure-rollen krijgen voor Azure Service Bus op de Service Bus die wordt geopend.

PublishToAzureServiceBus@2 taak

De nieuwe PublishToAzureServiceBus@2-taken kunnen worden geconfigureerd met behulp van een Azure-serviceverbinding. Maak een Azure-serviceverbinding en vul de serviceBusQueueName en serviceBusNamespace eigenschappen van de nieuwe taak in:

- task: PublishToAzureServiceBus@2
  inputs:
    azureSubscription: my-azure-service-connection
    serviceBusQueueName: my-service-bus-queue
    serviceBusNamespace: my-service-bus-namespace
    useDataContractSerializer: false
    messageBody: |
      {
        "foo": "bar"
      }
Servertaken

Aangepaste servertaken (zonder agent) die gebruikmaken van ServiceBus uitvoering, kunnen een Azure-serviceverbinding opgeven als EndpointId en weglaten ConnectionString. Zie Het ontwerpen van servertaken.

Pijplijnen en taken vullen variabelen in om federatieverificatie van workloadidentiteit aan te passen

Het REST API-eindpunt voor het aanvragen van OIDC-tokens is nu beschikbaar in de System.OidcRequestUri pijplijnvariabele. Taakontwikkelaars kunnen deze variabele gebruiken om een idToken te genereren voor verificatie met Entra-id.

Als u Marketplace-taken of aangepaste taken gebruikt om te implementeren in Azure, moet u er rekening mee houden dat deze taken mogelijk nog geen ondersteuning bieden voor federatie van workloadidentiteiten. We raden taakontwikkelaars aan om workloadidentiteitsfederatie in te schakelen om de beveiligingsmaatregelen te verbeteren.

Schermopname van oidc-samenwerking.

Taken die invoer connectedService:AzureRM in task.json kunnen worden bijgewerkt om de federatie van workloadidentiteiten te ondersteunen door de volgende stappen uit te voeren:

  • Gebruik de Oidctoken REST API om een idToken aan te vragen (pijl 1 in het bovenstaande diagram).
  • Exchange het idToken voor een toegangstoken met behulp van de federatieve referentiestroom van de OAuth-API, waarbij het idToken wordt opgegeven als client_assertion (pijlen 2 & 4 in het bovenstaande diagram);
    of:
  • Voor taken die fungeren als een wrapper rond een hulpprogramma dat verificatie zelf uitvoert, gebruikt u de verificatiemethode van de hulpprogramma's om het federatieve token op te geven.

Knooppunttaken kunnen gebruikmaken van het npm-pakket azure-pipelines-tasks-artifacts om het idToken te verkrijgen. Raadpleeg het codevoorbeeld voor implementatiedetails.

Een nieuw idToken aanvragen

Met de System.OidcRequestUri pijplijnvariabele en AZURESUBSCRIPTION_SERVICE_CONNECTION_ID omgevingsvariabele die in de AzureCLI@2 taken AzurePowerShell@5 worden weergegeven, kunnen auteurs van pijplijnen verifiëren vanuit hun eigen script:

PowerShell Az
- task: AzurePowerShell@5
  inputs:
    azureSubscription: 'my-azure-subscription'
    scriptType: inlineScript
    inline: |        
      # Request fresh idToken
      Invoke-RestMethod -Headers @{
                        Authorization  = "Bearer $(System.AccessToken)"
                        'Content-Type' = 'application/json'
                      } `
                      -Uri "${env:SYSTEM_OIDCREQUESTURI}?api-version=7.1&serviceConnectionId=${env:AZURESUBSCRIPTION_SERVICE_CONNECTION_ID}" `
                      -Method Post `
                      | Select-Object -ExpandProperty oidcToken
                      | Set-Variable idToken

    # Fetch current context
    $azContext = Get-AzContext

    # Start new Az session
    Connect-AzAccount -ApplicationId $azContext.Account.Id `
                      -TenantId $azContext.Tenant.Id `
                      -SubscriptionId $azContext.Subscription.Id `
                      -FederatedToken $idToken
Azure-CLI
- task: AzureCLI@2
  inputs:
    addSpnToEnvironment: true
    azureSubscription: 'my-azure-subscription'
    scriptType: bash
    scriptLocation: inlineScript
    inlineScript: |
      # Request fresh idToken
      OIDC_REQUEST_URL="${SYSTEM_OIDCREQUESTURI}?api-version=7.1&serviceConnectionId=${AZURESUBSCRIPTION_SERVICE_CONNECTION_ID}"
      ARM_OIDC_TOKEN=$(curl -s -H "Content-Length: 0" -H "Content-Type: application/json" -H "Authorization: Bearer $(System.AccessToken)" -X POST $OIDC_REQUEST_URL | jq -r '.oidcToken')

      # Save subscription context
      ARM_SUBSCRIPTION_ID=$(az account show --query id -o tsv)

      # New az-cli session
      az login --service-principal -u $servicePrincipalId --tenant $tenantId --allow-no-subscriptions --federated-token $ARM_OIDC_TOKEN
      az account set --subscription $ARM_SUBSCRIPTION_ID

Nieuwe pogingen voor servertaken

Servertaken die externe systemen aanroepen, zoals AzureFunction of, kunnen af en InvokeRESTAPItoe mislukken vanwege tijdelijke fouten, zoals uitputting van rekenresources. Voorheen zouden dergelijke fouten ertoe leiden dat de hele taak en mogelijk de pijplijn mislukken.

Ter verbetering van de tolerantie tegen tijdelijke fouten hebben we ondersteuning geïntroduceerd voor de retryCountOnTaskFailure eigenschap in servertaken. Stel dat u de volgende YAML-code in uw pijplijn hebt:

- stage: deploy
  jobs:
  - job:
    pool: server
    steps:
    - task: AzureFunction@1
      retryCountOnTaskFailure: 2
      inputs:
        function: 'https://api.fabrikamfiber.com'
        key: $(functionKey)
        method: 'POST'
        waitForCompletion: 'false'

Als https://api.fabrikamfiber.com er een tijdelijke fout optreedt, probeert Azure Pipelines de aanvraag maximaal drie keer opnieuw (de eerste poging plus twee nieuwe pogingen die zijn opgegeven door retryCountOnTaskFailure). Elke nieuwe poging omvat een toenemende wachttijd. Het maximum aantal toegestane nieuwe pogingen is 10.

Deze retryCountOnTaskFailure is niet beschikbaar voor de ManualValidation taak en andere taken waarvoor geen externe systeemaanroepen nodig zijn.

Taken die een end-of-life Node runner-versie gebruiken om waarschuwingen uit te voeren

Pijplijntaken die afhankelijk zijn van een knooppuntversie die niet meer worden onderhouden , ontvangen waarschuwingen:

De taakversie TaskName <version> is afhankelijk van een knooppuntversie (10) die het einde van de levensduur heeft. Neem contact op met de eigenaar van de extensie voor een bijgewerkte versie van de taak. Taakonderhouders moeten richtlijnen voor knooppuntupgrades bekijken: https://aka.ms/node-runner-guidance

Als u deze waarschuwingen wilt onderdrukken, kunt u een omgevings- of pijplijnvariabele instellen op het niveau van de pijplijn (taak) of op taakniveau. Voorbeeld:

variables:
  AZP_AGENT_CHECK_IF_TASK_NODE_RUNNER_IS_DEPRECATED: false

DockerCompose@0 gebruikt Docker Compose v2 in de compatibiliteitsmodus v1

Docker Compose v1 zal het einde van de levensduur bereiken en wordt verwijderd van gehoste agents op 24 juli 2024. We hebben de DockerCompose@0 taak bijgewerkt voor het gebruik van Docker Compose v2 in de v1-compatibiliteitsmodus als Docker Compose v1 niet beschikbaar is op de agent.

In de compatibiliteitsmodus worden echter niet alle compatibiliteitsproblemen opgelost. Zie Migreren naar Compose V2. Sommige gebruikers hebben meer tijd nodig om hun Docker Compose-projecten bij te werken voor compatibiliteit met Docker Compose v2. In die gevallen volgt u deze instructies om de DockerComposeV0-taak te gebruiken met docker-compose v1.

OPMERKING: deze handleiding is gebaseerd op de zelfstandige documentatie voor Install Compose

Docker-compose v1 gebruiken in Windows

Voeg de PowerShell-stap toe aan uw pijplijn om docker-Compose v1.29.2 te downloaden en te gebruiken met de DockerComposeV0-taak in Windows:

variables:
    dockerComposePath: C:\docker-compose

steps:
- powershell: |
    mkdir -f $(dockerComposePath)
    # GitHub now requires TLS1.2. In PowerShell, run the following
    [Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12
    Start-BitsTransfer -Source "https://github.com/docker/compose/releases/download/1.29.1/docker-compose-windows-x86_64.exe" -Destination $(dockerComposePath)\docker-compose.exe
  displayName: Download docker-compose
- task: DockerCompose@0
  inputs:
    containerregistrytype: 'Azure Container Registry'
    dockerComposeFile: '**/docker-compose.yml'
    action: 'Run a Docker Compose command'
    dockerComposeCommand: 'run'
    dockerComposePath: $(dockerComposePath)\docker-compose.exe

docker-compose v1 gebruiken in Linux

Voeg de bash-stap toe aan uw pijplijn om Docker-Compose v1.29.2 te downloaden en te gebruiken met de DockerComposeV0-taak op Linux:

variables:
    dockerComposePath: /tmp/docker-compose

steps:
- bash: |
    sudo mkdir $(dockerComposePath)
    sudo curl -SL https://github.com/docker/compose/releases/download/1.29.2/docker-compose-linux-x86_64 -o $(dockerComposePath)/docker-compose
    sudo chmod 755 $(dockerComposePath)/docker-compose
  displayName: Download docker-compose
- task: DockerCompose@0
  inputs:
    containerregistrytype: 'Azure Container Registry'
    dockerComposeFile: $(Build.SourcesDirectory)/DockerComposeV0/docker-compose.yml
    action: 'Run a Docker Compose command'
    dockerComposeCommand: 'run'
    dockerComposePath: $(dockerComposePath)/docker-compose

Azure Test Plans

Extensie testen en feedback in Manifest V3

We zijn verheugd om een nieuwe update voor de Azure DevOps Test- en Feedback-extensie aan te kondigen. Met deze upgrade wordt onze implementatie van manifestversie 2 naar versie 3 overgestapt, in overeenstemming met het afschaffingsschema van Google voor Manifest V2.

Hoewel de kernfuncties van de extensie ongewijzigd blijven, verbetert deze update de beveiliging en prestaties. De bijgewerkte extensie wordt geleidelijk geïmplementeerd in zowel Chrome- als Edge-browsers in de komende weken. We controleren de prestaties en feedback om een soepele overgang te garanderen voordat de implementatie wordt uitgebreid op basis van de resultaten.

Bekijk onze recente blogpost over deze update voor meer informatie. Test & Feedback-extensie in Manifest V3

Volgende stappen

Notitie

Deze functies worden de komende twee tot drie weken uitgerold.

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.

Een suggestie doen

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

Met vriendelijke groet,

Gepleiu Andrica