Partager via

Améliorations apportées à la copie du tableau de bord

  • Article

Nous sommes heureux d’annoncer des améliorations attendues de la préversion du tableau de bord de copie. Vous pouvez maintenant copier un tableau de bord dans une autre équipe, la même équipe ou un autre projet, et la configuration de l’équipe et des requêtes est mise à jour dans le nouveau tableau de bord. Cela réduit davantage le travail nécessaire pour créer des tableaux de bord similaires à partir de zéro pour plusieurs équipes.

Pour plus d’informations, consultez les descriptions des fonctionnalités suivantes.

Général

Azure Pipelines

Rapports

Général

Attribuer un rôle Administrateur Azure DevOps à un groupe Azure AD

Le rôle Administrateur Azure DevOps, nécessaire pour configurer les stratégies de locataire Azure AD dans Azure DevOps, peut désormais être attribué à des groupes Azure AD. En savoir plus sur l’utilisation des groupes Azure AD pour gérer les attributions de rôles dans Azure AD.

Azure Pipelines

Nouvelles tentatives automatiques pour une tâche

Lorsque vous avez une tâche flaky qui échoue par intermittence dans un pipeline, vous devrez peut-être réexécuter le pipeline pour qu’elle réussisse. Dans la plupart des cas, la meilleure façon de traiter une tâche ou un script flaky consiste à corriger la tâche ou le script lui-même. Par instance, si votre tâche de test échoue dans un pipeline en raison de tests peu fiables, il est toujours judicieux de les corriger et de les rendre plus fiables. De même, si votre script échoue de temps en temps, il est préférable de le corriger, pour instance en introduisant de nouvelles tentatives dans le script.

Toutefois, dans certains cas, vous souhaiterez peut-être réessayer la tâche. Un cas d’usage courant est une tâche qui télécharge un package (par exemple, NuGet, npm, etc.). Nous avons souvent observé que ces tâches sont sensibles aux défaillances réseau et aux défaillances temporaires sur les serveurs d’hébergement de package. Nous avons entendu vos commentaires indiquant qu’il serait préférable de réessayer automatiquement ces tâches défaillantes sans avoir à redémarrer l’ensemble du pipeline.

En fonction de vos commentaires, nous avons ajouté une fonctionnalité permettant de réessayer automatiquement une tâche dans un pipeline en cas d’échec. Si vous utilisez des pipelines YAML, vous pouvez définir cette entrée comme suit :

- task: <name of task>
   retryCountOnTaskFailure: <max number of retries>
   ...

Lorsque vous utilisez des pipelines de build ou de mise en production classiques, vous pouvez définir cette propriété sous les options de contrôle de la tâche.

Voici quelques points à noter lors de l’utilisation de nouvelles tentatives :

  • La tâche défaillante est retentée immédiatement.
  • Il n’existe aucune hypothèse concernant l’idempotence de la tâche. Si la tâche a des effets secondaires (par exemple, si elle a partiellement créé une ressource externe), alors elle peut échouer lors de sa deuxième exécution.
  • Il n’existe aucune information sur le nombre de nouvelles tentatives disponibles pour la tâche.
  • Un avertissement est ajouté aux journaux des tâches pour indiquer qu’elle a échoué avant d’être retentée.
  • Toutes les nouvelles tentatives d’exécution d’une tâche figurent dans l’interface utilisateur dans le cadre du même nœud de tâche.

Notes

Nécessite la version 2.194.0 ou ultérieure de l’agent. Non pris en charge pour les tâches sans agent.

Consommer des entrées d’une autre tâche dans un élément décoratif

Nous avons récemment ajouté une fonctionnalité permettant d’injecter automatiquement une tâche dans un pipeline avant une autre tâche cible dans ce pipeline. Nous améliorons maintenant cette fonctionnalité en vous permettant de personnaliser cette tâche injectée à l’aide des paramètres d’entrée de la tâche cible. La syntaxe d’écriture d’un élément décoratif est la suivante :

{
    "contributions": [
        {
            "id": <my-required-task>,
            "type": "ms.azure-pipelines.pipeline-decorator",
            "targets": [
                "ms.azure-pipelines-agent-job.pre-task-tasks",
                "ms.azure-pipelines-agent-job.post-task-tasks"
            ],
            "properties": {
                "template": "my-decorator.yml",
                "targettask": <target-task-id>,
                "targettaskinputs": ["<name of input>"]
            }
        }
    ],
    ...
}

Cette fonctionnalité fonctionne uniquement lorsque vous utilisez pre-task-tasks ou post-task-tasks comme cible pour l’injection et que vous spécifiez dans targettask la section propriétés de la contribution. Vous pouvez ensuite ajouter une propriété supplémentaire appelée targettaskinputs et spécifier une liste de noms de paramètres d’entrée acceptés par la tâche cible. Ces entrées sont désormais mises à la disposition de la tâche injectée.

Un cas d’usage courant qui peut être accompli par un tel scénario est le suivant. Supposons que vous souhaitiez injecter une tâche qui journalise automatiquement le nom de l’artefact publié par une build. Le nom de l’artefact est une entrée de la PublishBuildArtifacts tâche. Votre tâche injectée peut désormais obtenir le même paramètre d’entrée et l’utiliser pour la journalisation.

Améliorations apportées à l’historique d’utilisation des connexions de service

Lorsqu’un pipeline utilise une connexion de service, cette utilisation est enregistrée dans l’historique de la connexion. Les administrateurs de la connexion de service peuvent consulter l’historique d’utilisation en accédant aux paramètres du projet et en sélectionnant la connexion de service appropriée. Certains problèmes liés à l’historique d’utilisation des connexions de service ont été résolus avec cette mise à jour. Les correctifs sont les suivants :

  • Lorsqu’une connexion de service est utilisée dans un travail de déploiement (au lieu d’un travail normal), cette utilisation n’était pas journalisée.
  • Si vous avez utilisé plusieurs connexions de service dans plusieurs étapes d’un pipeline, toutes les connexions de service affichent un enregistrement dans leur historique d’utilisation, même si certaines étapes ont été ignorées.

La spécification de l’agent par défaut pour les pipelines classiques est désormais Windows-2019

Dans les dernières notes de publication, nous avons annoncé une planification de dépréciation pour vs2017-win2016 les images hébergées. En prévision de cela, nous modifions maintenant la spécification de l’agent par défaut lors de la création de pipelines dans les pipelines classiques en windows-2019.

Spécification de l’agent

Rapports

Améliorations apportées à la copie du tableau de bord

Nous sommes heureux d’annoncer la préversion publique de la phase 2 du tableau de bord de copie ! Les requêtes et la configuration sont désormais reportées avec l’opération de copie. Merci pour votre patience, car il a fallu un peu plus de temps que prévu pour résoudre certains problèmes.

L’aperçu est activé par défaut avec l’indicateur de fonctionnalité Copier l’expérience de tableau de bord (sous Fonctionnalités de préversion).

Pour copier un tableau de bord, accédez d’abord au tableau de bord que vous souhaitez copier. Ensuite, cliquez sur le menu pour afficher Copier le tableau de bord , puis cliquez dessus.

Copier le tableau de bord

Ensuite, fournissez le nom et la description du nouveau tableau de bord, puis sélectionnez le type de tableau de bord Équipe ou Projet. Lorsque vous sélectionnez un tableau de bord d’équipe, le nouveau projet et l’équipe sont sélectionnés dans les zones de liste déroulante respectives. Pour un tableau de bord Project, seul le projet est requis.

Nouveau tableau de bord

Vous serez dirigé vers le tableau de bord nouvellement créé après avoir cliqué sur le bouton Créer . Les widgets et la disposition restent les mêmes.

En arrière-plan, un dossier portant le nom du nouveau tableau de bord est créé dans Requêtes partagées. Toutes les requêtes du nouveau tableau de bord sont copiées dans ce dossier. Les noms de requête restent les mêmes. Les widgets avec une configuration d’équipe sont mis à jour avec la nouvelle équipe. Les widgets avec une configuration d’équipe copiée d’un tableau de bord d’équipe vers un tableau de bord project conservent la configuration d’origine.

Filtrer sur les valeurs Null dans le widget de graphique burndown

Vous pouvez désormais filtrer sur une valeur Null lors de l’utilisation des critères de champ dans le widget de graphique burndown. Ce comportement est désormais cohérent avec une requête utilisant les mêmes critères de champ.

Configuration des critères de champ

É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édez à 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,

Aaron Hallberg