Paramètre permettant de désactiver la création de référentiels TFVC

  • Article

Avec cette mise à jour, nous introduisons un nouveau paramètre pour désactiver la création de dépôts TFVC. Cette modification se concentre sur les nouveaux projets tout en veillant à ce que vos dépôts TFVC existants ne soient pas affectés.

En outre, nous sommes heureux d’annoncer que dans Azure Pipelines, un nouveau point de terminaison d’API REST est disponible pour demander des jetons OIDC ! Cela permet aux développeurs de tâches de générer des idTokens pour l’authentification d’ID Entra, d’améliorer la sécurité et la facilité d’utilisation.

Enfin, dans Azure Boards, les chemins d’accès aux zones et aux itérations peuvent désormais être supprimés uniquement s’ils ne sont plus associés à des éléments de travail. Cette amélioration empêche les interruptions et garantit que les équipes conservent l’accès à leurs tableaux et backlogs.

Pour plus d’informations, consultez les notes de publication.

GitHub Advanced Security pour Azure DevOps

Azure Boards :

Azure Repos

Azure Pipelines

Azure Test Plans :

GitHub Advanced Security pour Azure DevOps

Documentation de l’API vue d’ensemble de la sécurité maintenant disponible

La documentation relative à l’API qui alimente l’onglet Risque de sécurité avancée est désormais disponible. Utilisez le point de terminaison /{organization}/_apis/reporting/summary/alerts pour afficher un résumé de la criticité des alertes sur tous les référentiels avancés compatibles avec la sécurité. Vérifiez que votre PAT ADO dispose de l’autorisation vso.advsec , ce qui permet de lire des alertes, des instances de résultats et des instances de résultat d’analyse.

Azure Boards

Modification de la suppression des chemins d’accès de zone et d’itération

La suppression d’une zone ou d’un chemin d’itération peut être perturbatrice. Il peut déplacer des éléments de travail vers un nouveau chemin et peut entraîner la perte d’accès des équipes à leurs tableaux et backlogs. Malgré les avertissements et les invites, les chemins d’accès sont parfois supprimés sans comprendre pleinement les conséquences. Pour résoudre ce problème, nous avons modifié le comportement : les chemins de zone et d’itération ne peuvent désormais être supprimés que s’ils ne sont plus utilisés par des éléments de travail.

Captures d’écran de la zone de suppression.

Azure Repos

Nouveau paramètre pour désactiver la création de référentiels TFVC

Au cours des dernières années, aucune nouvelle fonctionnalité n’a été ajoutée à Team Foundation Version Control (TFVC), car Git est devenu le système de contrôle de version préféré dans Azure Repos. Toutes les améliorations récentes de la sécurité, des performances et de l’accessibilité ont été apportées exclusivement aux référentiels Git, ce qui entraîne une baisse continue de l’utilisation de TFVC. Bien que certains s’appuient toujours sur TFVC et que nous n’avons pas l’intention de supprimer cet ensemble de fonctionnalités, nous prévoyons de supprimer progressivement TFVC pour les nouveaux projets et organisations, ainsi que pour les projets qui n’utilisent actuellement pas TFVC.

Dans le cadre de cette transition, nous introduisons un nouveau paramètre pour « Désactiver la création de référentiels TFVC », ce qui affecte uniquement la création de nouveaux référentiels TFVC et n’aura pas d’impact sur les dépôts existants.

Gif pour démonstration Désactiver la création de référentiels TFVC.

Azure Pipelines

Accéder à Azure Service Bus à partir de Pipelines à l’aide de l’authentification Microsoft Entra ID

Vous pouvez maintenant utiliser l’authentification Microsoft Entra ID pour accéder à Azure Service Bus à partir d’Azure Pipelines. Cela vous permet de tirer parti de la fédération des identités de charge de travail pour supprimer la gestion des secrets et Azure RBAC pour un contrôle d’accès affiné.

Les identités accédant à Azure Service Bus doivent avoir accès à l’un des rôles intégrés Azure pour Azure Service Bus sur Service Bus accessible.

tâche de PublishToAzureServiceBus@2

Les nouvelles tâches PublishToAzureServiceBus@2 peuvent être configurées à l’aide d’une connexion de service Azure. Créez une connexion de service Azure et remplissez les propriétés et serviceBusNamespace les serviceBusQueueName propriétés de la nouvelle tâche :

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

Les tâches de serveur personnalisé (sans agent) qui utilisent ServiceBus l’exécution peuvent spécifier une connexion de service Azure comme EndpointId et omettre ConnectionString. Consultez la création de tâches serveur.

Pipelines et tâches remplissent des variables pour personnaliser l’authentification de fédération des identités de charge de travail

Le point de terminaison de l’API REST pour demander des jetons OIDC est désormais disponible dans la variable de System.OidcRequestUri pipeline. Les développeurs de tâches peuvent tirer parti de cette variable pour générer un idToken pour l’authentification avec Entra ID.

Si vous utilisez des tâches de la Place de marché ou des tâches personnalisées à déployer sur Azure, sachez que ces tâches peuvent ne pas encore prendre en charge la fédération des identités de charge de travail. Nous recommandons aux développeurs de tâches d’activer la fédération des identités de charge de travail pour améliorer les mesures de sécurité.

Capture d’écran de la collaboration oidc.

Les tâches qui prennent une connectedService:AzureRM entrée dans task.json peuvent être mises à jour pour prendre en charge la fédération des identités de charge de travail en procédant comme suit :

  • Utilisez l’API REST Oidctoken pour demander un idToken (flèche 1 dans le diagramme ci-dessus).
  • Échangez l’idToken pour un jeton d’accès à l’aide du flux d’informations d’identification fédéré de l’API OAuth, en spécifiant l’idToken comme client_assertion (flèches 2 et 4 dans le diagramme ci-dessus) ;
    ou :
  • Pour les tâches qui agissent en tant que wrapper autour d’un outil qui effectue l’authentification elle-même, utilisez la méthode d’authentification des outils pour spécifier le jeton fédéré.

Les tâches de nœud peuvent utiliser le package npm azure-pipelines-tasks-artifacts-common pour obtenir l’idToken. Reportez-vous à l’exemple de code pour obtenir des détails sur l’implémentation.

Demande d’un idToken frais

La variable de pipeline et AZURESUBSCRIPTION_SERVICE_CONNECTION_ID la System.OidcRequestUri variable d’environnement exposées dans les tâches permettent AzurePowerShell@5 aux auteurs de AzureCLI@2 pipelines de s’authentifier à partir de leur propre 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

Nouvelles tentatives pour les tâches serveur

Les tâches serveur qui appellent des systèmes externes, tels que AzureFunction ou InvokeRESTAPI, peuvent parfois échouer en raison d’erreurs temporaires telles que l’épuisement des ressources de calcul. Auparavant, ces défaillances entraîneraient l’échec de l’ensemble du travail et potentiellement du pipeline.

Pour améliorer la résilience contre les erreurs temporaires, nous avons introduit la prise en charge de la propriété dans les retryCountOnTaskFailure tâches serveur. Supposons que vous disposez du code YAML suivant dans votre pipeline :

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

Si https://api.fabrikamfiber.com une erreur temporaire se produit, Azure Pipelines réessaye la requête jusqu’à trois fois (la tentative initiale plus deux nouvelles tentatives spécifiées par retryCountOnTaskFailure). Chaque nouvelle tentative inclut une période d’attente croissante. Le nombre maximal de nouvelles tentatives autorisées est de 10.

Il retryCountOnTaskFailure n’est pas disponible pour la ManualValidation tâche et d’autres tâches qui n’impliquent pas d’appels système externes.

Tâches qui utilisent une version de l’exécuteur de nœud de fin de vie pour exécuter des avertissements d’émission

Les tâches de pipeline qui s’appuient sur une version de nœud qui ne sont plus conservées commencent à recevoir des avertissements :

La version <version> de la tâche TaskName dépend d’une version de nœud (10) qui est en fin de vie. Contactez le propriétaire de l’extension pour obtenir une version mise à jour de la tâche. Les gestionnaires de tâches doivent consulter les conseils de mise à niveau des nœuds : https://aka.ms/node-runner-guidance

Pour supprimer ces avertissements, vous pouvez définir un environnement ou une variable de pipeline au niveau du pipeline (travail) ou de la tâche. Par exemple :

variables:
  AZP_AGENT_CHECK_IF_TASK_NODE_RUNNER_IS_DEPRECATED: false

DockerCompose@0 utilise Docker Compose v2 en mode de compatibilité v1

Docker Compose v1 atteint sa fin de vie et sera supprimé des agents hébergés le 24 juillet 2024. Nous avons mis à jour la tâche DockerCompose@0 pour utiliser Docker Compose v2 en mode de compatibilité v1 si Docker Compose v1 n’est pas disponible sur l’agent.

Toutefois, le mode de compatibilité ne traite pas tous les problèmes de compatibilité. Consultez Migrer vers Composer V2. Certains utilisateurs auront besoin de plus de temps pour mettre à jour leurs projets Docker Compose pour la compatibilité docker Compose v2. Dans ce cas, suivez ces instructions pour utiliser la tâche DockerComposeV0 avec docker-compose v1.

REMARQUE : Ce guide est basé sur la documentation Install Compose autonome

Utiliser docker-compose v1 sur Windows

Ajoutez l’étape PowerShell à votre pipeline pour télécharger docker-Compose v1.29.2 et l’utiliser avec la tâche DockerComposeV0 sur 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

Utiliser docker-compose v1 sur Linux

Ajoutez l’étape bash à votre pipeline pour télécharger Docker-Compose v1.29.2 et l’utiliser avec la tâche DockerComposeV0 sur 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

Tester et envoyer des commentaires dans manifest V3

Nous sommes heureux d’annoncer une nouvelle mise à jour de l’extension test et commentaires Azure DevOps ! Cette mise à niveau passe de notre implémentation de manifest version 2 à la version 3, en s’alignant sur la planification de dépréciation de Google pour Manifest V2.

Bien que les fonctionnalités principales de l’extension restent inchangées, cette mise à jour améliore la sécurité et les performances. L’extension mise à jour sera déployée progressivement sur les navigateurs Chrome et Edge au cours des prochaines semaines. Nous allons surveiller les performances et les commentaires pour garantir une transition fluide avant de développer le déploiement en fonction des résultats.

Pour plus d’informations, consultez notre billet de blog récent sur cette mise à jour. Tester l’extension de commentaires dans le manifeste V3

Étapes suivantes

Notes

Ces fonctionnalités seront déployées au cours des deux à trois prochaines semaines.

Accédez à Azure DevOps et jetez un coup d’œil.

Accéder à Azure DevOps

Comment fournir des commentaires

Nous aimerions savoir ce que vous pensez de ces fonctionnalités. Utilisez le menu Aide pour signaler un problème ou faire une suggestion.

Faire une suggestion

Vous pouvez également obtenir des conseils et répondre à vos questions par la communauté sur Stack Overflow.

Merci,

Silviu Andrica