Partager via


Azure Pipelines - Mise à jour sprint 246

Fonctionnalités

Ubuntu 24.04 sur les agents hébergés par Azure Pipelines

L’image Ubuntu 24.04 est désormais disponible pour les agents hébergés par Azure Pipelines. Pour utiliser cette image, mettez à jour votre fichier YAML pour inclure vmImage:'ubuntu-24.04':

- job: ubuntu2404
  pool:
    vmImage: 'ubuntu-24.04'
  steps:
  - bash: |
      echo Hello from Ubuntu 24.04
      lsb_release -d

Remarque

L’étiquette ubuntu-latest d’image continuera de pointer vers ubuntu-22.04 jusqu’à ce que plus tard cette année.

Consultez le fichier lisez-moi de l’image Ubuntu 24.04 pour les logiciels installés.

Utiliser la fédération des identités de charge de travail dans les tests d’intégration Azure

En juin, les bibliothèques Azure Identity for.NET, C++, Go, Java, JavaScript et Python ont ajouté la prise en charge de la fédération des identités de charge de travail. Cela a ajouté la possibilité pour le code exécuté à partir des tâches AzureCLI@2 et AzurePowerShell@5 de s’authentifier auprès de Microsoft Entra (par exemple, pour accéder à Azure) avec la AzurePipelinesCredential classe.

De nombreux clients utilisent les bibliothèques Azure Identity dans les tests d’intégration appelés à partir d’autres tâches. Nous avons maintenant ajouté la prise en charge des AzurePipelinesCredential tâches DotNetCoreCLI@2, Maven@4 et VSTest@3.

Vous pouvez définir la connectedService propriété sur une connexion de service Azure configurée avec la fédération d’identité de charge de travail. La AzurePipelinesCredential définition doit être nécessaire SYSTEM_ACCESSTOKEN .

- task: DotNetCoreCLI@2
  inputs:
    command: 'run'
    connectedService: <Azure service connection configured with workload identity federation>
  env:
    SYSTEM_ACCESSTOKEN: $(System.AccessToken)

Pour plus d’informations sur AzurePipelinesCredential, consultez ce billet de blog.

Nouvelle expérience de création de connexion de service Azure avec prise en charge améliorée des identités managées

La nouvelle expérience de création de connexion de service Azure offre une flexibilité accrue et des valeurs par défaut sécurisées. Elle aligne également la terminologie avec Microsoft Entra ID, afin que les utilisateurs qui créent manuellement des objets Microsoft Entra ID aient une meilleure compréhension lors de la navigation dans différents portails.

Lors de la création d’une connexion de service Azure Resource Manager, les différentes options permettant de configurer l’identité sont désormais disponibles dans une boîte de dialogue unifiée unique qui remplace les éléments de niveau supérieur distincts utilisés précédemment :

Capture d’écran des options de niveau supérieur de connexion de service Azure.

Le type d’identité répertorie tous les schémas d’authentification pris en charge par la connexion de service Azure :

Capture d’écran du type d’identité.

Pour les inscriptions d’applications, vous pouvez sélectionner indépendamment les informations d’identification pour qu’elles soient une fédération d’identité de charge de travail ou un secret.

Prise en charge de l’identité managée de connexion de service Azure

Vous pouvez maintenant sélectionner une identité managée préexistante et l’utiliser pour configurer une connexion de service qui utilise la fédération d’identité de charge de travail. Tout d’abord, créez une identité managée affectée par l’utilisateur.

Ensuite, créez une connexion de service Azure et sélectionnez le type d’identité d’identité managée. Cela configure les informations d’identification d’identité fédérée sur l’identité managée.

Capture d’écran de la prise en charge de Managed Identity.

L’option permettant d’utiliser une identité managée affectée à un agent (pool) a été renommée Identité managée (affectée par l’agent). Pour empêcher le partage d’identités managées sur-privilégiées, il est recommandé d’utiliser une identité managée avec une fédération d’identité de charge de travail au lieu d’identités managées affectées aux pools d’agents.

L’identité managée est également l’option recommandée pour les utilisateurs qui ne peuvent pas créer d’inscription d’application si cette option est désactivée dans l’ID Microsoft Entra.

Pour utiliser une identité managée avec la fédération d’identité de charge de travail, sélectionnez d’abord l’abonnement et le groupe de ressources qui contient votre identité managée. Cela peut être différent de l’abonnement auquel la connexion de service accède dans les travaux de pipeline. Sélectionnez l’identité managée configurée pour la fédération d’identité de charge de travail. L’utilisateur a besoin du rôle Contributeur d’identité managée ou des autorisations équivalentes sur l’identité managée pour créer des informations d’identification d’identité fédérées dessus.

Continuez à sélectionner l’abonnement qui sera utilisé comme étendue de déploiement pour la connexion de service.

Capture d’écran de la sélection De l’identité managée.

Champ Référence de gestion des services

Certaines organisations nécessitent que la référence de gestion des services d’une inscription d’application soit remplie avec des informations de contexte pertinentes à partir d’une base de données ITSM. Si nécessaire, les utilisateurs peuvent spécifier cette référence au moment de la création de la connexion de service.

Plus d’informations

La nouvelle expérience de création de connexion de service Azure est déployée au cours du mois suivant. Pour plus d’informations, consultez l’article suivant :

Étapes d’exécution des enfants lorsque l’étape parente échoue

Nous avons facilité la poursuite des déploiements à l’aide d’Azure Pipelines. Cela est utile, par exemple, lorsque vous utilisez Pipelines pour déployer de nouvelles versions de votre application dans plusieurs régions Azure.

Supposons que vous devez déployer dans cinq régions Azure consécutives. Supposons que votre pipeline a une étape pour chaque région, et que chaque étape a un travail qui exécute une AzureResourceManagerTemplateDeployment tâche, puis qu’il journalise certaines données de télémétrie. Ce dernier est agréable à avoir, mais pas critique. Imaginez qu’il existe un problème lors de la journalisation des données de télémétrie. À présent, l’étape échoue et le déploiement s’arrête.

À partir de ce sprint, lorsqu’une étape échoue, vous pouvez reprendre l’exécution de ses étapes enfants.

Capture d’écran de l’exécution des étapes enfants en cas d’échec de l’étape parente.

É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.

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.