Partager via

Nouveaux rapports Analytics et application Azure Boards pour Slack - Mise à jour sprint 155

  • Article

Dans la mise à jour Azure DevOps Sprint 155, nous introduisons de nouveaux rapports Azure Boards qui vous permettent de suivre plus facilement les métriques importantes de l’équipe. Les nouveaux rapports figurent sous l’onglet Analytics dans les hubs Boards, Backlog et Sprint. Ces rapports sont entièrement interactifs et vous pouvez les adapter à vos besoins.

Par ailleurs, nous sommes heureux d’annoncer la nouvelle application Azure Boards pour Slack. L’application vous permet de superviser l’activité des éléments de travail et de créer des éléments de travail à partir de votre canal Slack.

Pour plus d’informations, consultez la liste des fonctionnalités ci-dessous.

Nouveautés d’Azure DevOps

Fonctionnalités

Général :

Azure Boards :

Azure Repos :

Azure Artifacts :

Azure Pipelines :

Pipelines YAML à plusieurs phases

  Machines virtuelles hébergées

Kubernetes

Test

  Expériences Azure

Intégrations

Général

Inviter des collaborateurs GitHub dans Azure DevOps

Vous pouvez maintenant inviter des collaborateurs de GitHub à Azure DevOps lorsque vous êtes connecté avec votre identité GitHub. Vous pouvez rechercher et inviter d’autres utilisateurs GitHub à partir de la page d’accueil du projet et de la page Utilisateurs dans les paramètres de l’organisation.

Invite GitHub collaborators into Azure DevOps.

Cette fonctionnalité doit être activée pour les organisations existantes via un paramètre sous Stratégies dans les paramètres de l’organisation. Toutefois, elle est activée par défaut pour les organisations créées par une identité GitHub.

Enable for existing organizations.

Remarque

Cette fonctionnalité n’est pas disponible pour les utilisateurs non GitHub, même si la stratégie est activée.

Pour en savoir plus sur l’invitation de membres de l’équipe, consultez la documentation ici. Si vous rencontrez des problèmes de connexion à Azure DevOps à l’aide de GitHub, consultez la résolution des problèmes liés à l’authentification et à l’invitation des utilisateurs GitHub.

Azure Boards

Obtenir des insights sur l’état d’intégrité de votre équipe avec trois nouveaux rapports Azure Boards

Vous ne pouvez pas corriger ce que vous ne pouvez pas voir. Par conséquent, vous souhaitez garder un œil étroit sur l’état et l’intégrité de leurs processus de travail. Avec ces rapports, nous vous rendons plus faciles à suivre les métriques importantes avec un effort minimal dans Azure Boards.

Les trois nouveaux rapports interactifs sont : Burndown, Cumulative Flow Diagram (CFD) et Velocity. Vous pouvez voir les rapports dans le nouvel onglet Analytique.

Les métriques telles que le sprint burndown, le flux de travail et la vélocité de l’équipe vous donnent la visibilité sur la progression de votre équipe et vous aident à répondre aux questions telles que :

  • Combien de travail avons-nous laissé dans ce sprint ? Sommes-nous en voie de le terminer ?
  • Quelle étape du processus de développement prend la plus longue ? Pouvons-nous faire quelque chose à ce sujet ?
  • En fonction des itérations précédentes, combien de travail devons-nous planifier pour le sprint suivant ?

Remarque

Les graphiques précédemment affichés dans les en-têtes ont été remplacés par ces rapports améliorés.

Les nouveaux rapports sont entièrement interactifs et vous permettent de les ajuster à vos besoins. Vous trouverez les nouveaux rapports sous l’onglet Analytique dans chaque hub.

  • Le graphique de burndown se trouve sous le hub Sprints .

    Analytics tab in Sprint hub.

  • Les rapports CFD et Vélocité sont accessibles à partir de l’onglet Analytique sous Tableaux et Backlogs en cliquant sur le carte approprié.

    CFD and velocity reports in boards.

Avec les nouveaux rapports, vous avez plus de contrôle et d’informations sur votre équipe. Voici quelques exemples :

  • Les rapports Sprint Burndown et Vélocité peuvent être définis pour utiliser le nombre d’éléments de travail ou la somme du travail restant.
  • Vous pouvez ajuster la période d’avancement du sprint sans affecter les dates du projet. Par conséquent, si votre équipe passe généralement le premier jour de chaque planification de sprint, vous pouvez maintenant faire correspondre le graphique pour refléter cela.
  • Le graphique Burndown présente désormais un filigrane affichant les week-ends.
  • Le rapport CFD vous permet de supprimer des colonnes de tableau telles que La conception pour obtenir plus de focus sur le flux sur lequel les équipes ont le contrôle.

Voici un exemple de rapport DE LA CFS montrant le flux des 30 derniers jours du backlog Stories.

Example of the CFD report.

Le graphique de vélocité peut maintenant être suivi pour tous les niveaux de backlog. Par exemple, vous pouvez maintenant ajouter des fonctionnalités et des épopées, tandis que avant le graphique précédent, seuls les exigences sont prises en charge. Voici un exemple de rapport de vélocité pour les 6 dernières itérations du backlog Fonctionnalités.

Example of a velocity report.

Application Azure Boards pour Slack

Nous sommes heureux d’annoncer la nouvelle application Azure Boards pour Slack. Avec cette application, vous pouvez surveiller l’activité des éléments de travail et créer des éléments de travail à partir de votre canal Slack.

L’application vous permet de configurer et de gérer des abonnements aux événements, notamment la création et les mises à jour des éléments de travail, et d’obtenir des notifications pour ces événements dans votre canal Slack. Les conversations dans le canal Slack peuvent être utilisées pour créer des éléments de travail. Vous recevrez également des notifications personnelles lorsque des éléments de travail sont attribués à vous. En outre, les aperçus des URL d’élément de travail vous permettent de lancer des discussions.

Azure Boards app for Slack.

Pour installer l’application Azure Boards, cliquez ici.

Personnaliser les colonnes du tableau des tâches

Nous sommes heureux d’annoncer que nous avons ajouté une option pour vous permettre de personnaliser les colonnes dans le tableau des tâches. Vous pouvez maintenant ajouter, supprimer, renommer et réorganiser les colonnes.

Pour configurer les colonnes de votre tableau des tâches, accédez aux options de colonne.

Customizing columns on the taskboard.

Cette fonctionnalité a été hiérarchisée en fonction d’une suggestion de la Communauté des développeurs.

Afficher ou masquer les éléments de travail enfants terminés dans le backlog

Plusieurs fois, lors de l’affinement du backlog, vous ne souhaitez voir que les éléments qui n’ont pas été terminés. À présent, vous avez la possibilité d’afficher ou de masquer les éléments enfants terminés sur le backlog.

Si le bouton bascule est activé, vous verrez tous les éléments enfants dans un état terminé. Lorsque le bouton bascule est désactivé, tous les éléments enfants dans un état terminé sont masqués dans le backlog.

Show or hide child items on the backlog.

Vous pouvez désormais accéder facilement à vos tableaux récemment visités, backlogs, requêtes et sprints à partir de la zone de recherche en activant la zone de recherche dans Azure Boards.

Activate the instant search box.

En outre, vous pouvez rechercher les tableaux, les backlogs, les requêtes et les sprints sur votre projet en tapant le nom du tableau dans la zone de recherche. Maintenant, les tableaux qui comptent le plus pour vous n’êtes qu’un clic.

Search for a board name.

Affichage des catégories les plus récentes lors de la catégorisation d’un élément de travail

Lors de l’étiquetage d’un élément de travail, l’option de saisie semi-automatique affiche désormais jusqu’à cinq de vos balises les plus récemment utilisées. Cela facilite l’ajout des informations appropriées à vos éléments de travail.

Most recent used tags displayed when tagging a work item.

Azure Repos

Amélioration des options de filtrage de la recherche de code

Auparavant, la recherche de code prenait en charge 39 filtres de recherche de code tels que les commentaires : et def :. Les données suggèrent qu’il y avait de nombreux filtres qui n’étaient pas utilisés, par conséquent, nous supprimons quelques filtres et fusionnant d’autres. Avec cette mise à jour, nous avons réduit le nombre de filtres à 19. Cela vous aidera à rendre les requêtes de recherche de code plus efficaces et à réduire l’encombrement dans l’interface.

Code search filter options.

Par exemple, maintenant func : mappe à la méthode :, c’est-à-dire si vous recherchez func :Account Administration, les résultats sont mappés à la méthode :Account Administration. De même , macrodef : et macroref : sont mappés à macro :. D’autre part, les filtres tels que union : et org : ont été déconseillés en raison d’un manque d’utilisation.

Métriques de couverture de code et stratégie de branche pour les demandes de tirage

Vous pouvez maintenant voir les métriques de couverture du code pour les modifications dans la vue de demande de tirage (pull request). Cela garantit que vous avez correctement testé vos modifications via des tests automatisés. L’état de la couverture s’affiche sous forme de commentaire dans la vue d’ensemble de la demande de tirage. Vous pouvez afficher les détails des informations de couverture pour chaque ligne de code modifiée dans l’affichage de différences de fichier.

Code coverage metrics and branch policy for pull requests

View details of coverage information for every code line that is changed.

En outre, les propriétaires de référentiels peuvent désormais définir des stratégies de couverture du code et empêcher la fusion de modifications volumineuses et non testées dans une branche. Les seuils de couverture souhaités peuvent être définis dans un azurepipelines-coverage.yml fichier de paramètres case activée à la racine du dépôt et de la stratégie de couverture peuvent être définis à l’aide de la configuration existante d’une stratégie de branche pour des fonctionnalités de services supplémentaires dans Azure Repos.

Define coverage thresholds.

Filtrer les notifications de commentaires dans les demandes de tirage

Les commentaires dans les demandes de tirage peuvent souvent générer beaucoup de bruit en raison de notifications. Nous avons ajouté un abonnement personnalisé qui vous permet de filtrer les notifications de commentaires auxquelles vous vous abonnez par âge de commentaire, commenter, commentaire, commentaire supprimé, utilisateurs mentionnés, auteur de demande de tirage, branche cible et participants de thread. Vous pouvez créer ces abonnements de notification en cliquant sur l’icône de l’utilisateur dans le coin supérieur droit et en accédant aux paramètres utilisateur.

Filter comment notifications from pull requests.

Filter comment notifications in User settings.

Crochets de service pour les commentaires des demandes de tirage

Vous pouvez maintenant créer des hooks de service pour les commentaires dans une demande de tirage en fonction du référentiel et de la branche cible.

Service hooks for pull request comments.

Azure Artifacts

Partager vos packages publiquement avec des flux publics (préversion)

Vous pouvez maintenant créer et stocker vos packages dans des flux publics. Les packages stockés dans des flux publics sont disponibles pour tous sur Internet sans authentification, qu’ils soient ou non dans votre organisation, ou même connectés à une organisation Azure DevOps. Apprenez-en davantage sur les flux publics dans notre documentation sur les flux ou accédez directement à notre tutoriel pour partager des packages publiquement.

Share your packages with public feeds.

Azure Pipelines

kustomize et kompose en tant qu’options de bake dans la tâche KubernetesManifest

Kustomize (partie de Kubernetes sig-cli) vous permet de personnaliser des fichiers YAML bruts sans modèle à plusieurs fins et de laisser l’original YAML intact. Une option pour kustomize a été ajoutée sous l’action bake de la tâche KubernetesManifest afin que tout dossier contenant des fichiers kustomization.yaml puisse être utilisé pour générer les fichiers manifestes utilisés dans l’action de déploiement de la tâche KubernetesManifest.

steps:
- task: KubernetesManifest@0
  name: bake
  displayName: Bake K8s manifests from Helm chart
  inputs:
    action: bake
    renderType: kustomize
    kustomizationPath: folderContainingKustomizationFile

- task: KubernetesManifest@0
  displayName: Deploy K8s manifests
  inputs:
    kubernetesServiceConnection: k8sSC1
    manifests: $(bake.manifestsBundle)

kompose transforme un fichier Docker Compose en ressource Kubernetes.

steps:
- task: KubernetesManifest@0
  name: bake
  displayName: Bake K8s manifests from Helm chart
  inputs:
    action: bake
    renderType: kompose
    dockerComposeFile: docker-compose.yaml

- task: KubernetesManifest@0
  displayName: Deploy K8s manifests
  inputs:
    kubernetesServiceConnection: k8sSC1
    manifests: $(bake.manifestsBundle)

Prise en charge des informations d’identification d’administrateur de cluster dans une tâche HelmDeploy

Auparavant, la tâche HelmDeploy utilisait les informations d’identification de l’utilisateur du cluster pour les déploiements. Cela a entraîné des invites de connexion interactives et des pipelines défaillants pour un cluster RBAC basé sur Azure Active Directory. Pour résoudre ce problème, nous avons ajouté une case activée box qui vous permet d’utiliser des informations d’identification d’administrateur de cluster au lieu d’informations d’identification d’utilisateur de cluster.

Package and deploy Helm charts showing the use cluster admin credentials checkbox.

Gérer des variables de pipeline dans l’éditeur YAML

Nous avons mis à jour l’expérience de gestion des variables de pipeline dans l’éditeur YAML. Vous n’avez plus besoin d’accéder à l’éditeur classique pour ajouter ou mettre à jour des variables dans vos pipelines YAML.

Manage pipeline variables in YAML editor.

Nouvelles variables prédéfinies dans le pipeline YAML

Les variables vous permettent d’entrer éléments de données clés dans différentes parties de votre pipeline. Avec cette mise à jour, nous avons ajouté quelques variables prédéfinies à un travail de déploiement. Ces variables sont automatiquement définies par le système, délimitées au travail de déploiement spécifique et sont en lecture seule.

  • Environment.Id : ID de l’environnement.
  • Environment.Name : nom de l’environnement ciblé par le travail de déploiement.
  • Environment.ResourceId : ID de la ressource dans l’environnement ciblé par le travail de déploiement.
  • Environment.ResourceName : nom de la ressource dans l’environnement ciblé par le travail de déploiement.

Actuellement, vous pouvez lier automatiquement des éléments de travail avec des builds classiques. Toutefois, cela n’était pas possible avec les pipelines YAML. Avec cette mise à jour, nous avons résolu cet écart. Lorsque vous exécutez un pipeline avec succès à l’aide de code à partir d’une branche spécifiée, Azure Pipelines associe automatiquement l’exécution à tous les éléments de travail (qui sont déduits par le biais des validations dans ce code). Lorsque vous ouvrez l’élément de travail, vous pouvez voir les exécutions dans lesquelles le code de cet élément de travail a été généré. Pour configurer cela, utilisez le panneau paramètres d’un pipeline.

Annuler une phase dans une exécution de pipeline YAML à plusieurs phases

Lors de l’exécution d’un pipeline YAML à plusieurs étapes, vous pouvez maintenant annuler l’exécution d’une étape pendant qu’elle est en cours. Cela est utile si vous savez que la phase va échouer ou si vous avez une autre exécution que vous souhaitez démarrer. Cette fonctionnalité est également une condition préalable pour nous de prendre en charge la nouvelle tentative d’une étape ayant échoué à l’avenir.

Approbations dans les pipelines YAML à plusieurs phases

Nous continuons d’améliorer les pipelines YAML à plusieurs étapes, nous vous permettant maintenant d’ajouter des approbations manuelles à ces pipelines. Les propriétaires d’infrastructure peuvent protéger leurs environnements et demander des approbations manuelles avant qu’une étape dans n’importe quel pipeline ne les déploie. Avec la séparation complète des rôles entre les propriétaires d’infrastructure (environnement) et d’application (pipeline), vous allez vous assurer de vous déconnecter manuellement du déploiement dans un pipeline particulier et d’obtenir un contrôle central pour appliquer les mêmes case activée s entre tous les déploiements à l’environnement.

Approvals in multi-stage YAML pipelines.

Le pipeline s’exécute sur le développement s’arrête pour approbation au début de l’étape.

Pipeline runs deploying to dev will stop for approval.

Mises à jour d’images de pipelines hébergés

Nous avons apporté des mises à jour à plusieurs des images de machine virtuelle hébergées par Azure Pipelines. Vous trouverez plus d’informations sur les dernières versions ici. Les modifications suivantes ont été ajoutées dans le cadre de cette mise à jour :

  • Pour VS2017 et VS2019 :

    • Ajout d’Azul Java 7
    • Images Docker mises en cache épinglées pour correspondre à la version du noyau hôte
    • Ajout du module Az PowerShell v2.3.2
    • Épinglé Mercurial vers v5.0.0
    • Mise à jour de Python vers les versions 2.7.16, 3.4.4, 3.5.4, 3.6.8, 3.7.4
    • Ajout de la bibliothèque de classes portables (VS 2019 uniquement)
    • Modification des chemins d’accès par défaut de Rust et des variables d’environnement

  • Pour Ubuntu 16.04 :

    • Mise à jour de Helm pour toujours extraire la dernière version (plus épinglée à la version 2.14.0)
    • Ajout de plusieurs conteneurs Docker populaires
    • Mise à jour de Python vers les versions 2.7.16, 3.4.10, 3.5.7, 3.6.9, 3.7.4
    • Modification des chemins d’accès par défaut de Rust et des variables d’environnement

  • Pour toutes les images, ajout d’une variable d’environnement ImageVersion pour la version de l’image

Pour obtenir la liste complète des outils disponibles pour une image particulière, accédez à Paramètres > Détails des pools > d’agents.

Améliorations apportées à DevOps Project pour les machines virtuelles

Dans cette mise à jour, nous avons amélioré le flux de travail de machine virtuelle DevOps Projects pour inclure les machines virtuelles qui ne sont pas conformes à la restriction de quota par emplacement. Auparavant, vous deviez choisir la machine virtuelle par nom et par offre. Vous disposez maintenant d’une vue à la demande avec plus d’informations sur les offres de machines virtuelles telles que le coût/mois, la RAM, les disques de données, etc. Cela vous permet de sélectionner plus facilement la machine virtuelle dont vous avez besoin.

Enhancements to DevOps Project for virtual machine.

Pool hébergé unique

Au cours du dernier sprint, nous avons communiqué que nous déployons un nouveau pool hébergé appelé Azure Pipelines pour remplacer tous les autres pools hébergés - Hébergé, VS2017 hébergé, Ubuntu 1604 hébergé, Windows 2019 hébergé par VS2019, Hébergé macOS et Hosted macOS High Sierra. Cette modification sera implémentée avec cette version.

L’utilisation de plusieurs pools hébergés peut être déroutante à certains moments. Vous n’obtenez pas une image précise de l’endroit où l’accès concurrentiel est consommé. Par exemple, si vous disposez d’une concurrence de 10 travaux parallèles, vous voyez 10 agents virtuels dans chacun des pools hébergés, ce qui n’est pas exact. Lorsque votre travail attend un pool hébergé spécifique (par exemple, VS2017 hébergé) avec tous les agents inactifs, vous pensez peut-être que le service Azure Pipelines est rompu sans se rendre compte que la concurrence est éventuellement consommée dans d’autres pools hébergés (par exemple, Ubuntu 1604 hébergé).

Avec cette modification, vous verrez un pool hébergé unique qui vous donnera une image précise du nombre de travaux en cours d’exécution dans ce pool. Nous prévoyons de déployer ce changement au cours des prochains sprints. Vous n’aurez pas besoin d’apporter de modifications à vos pipelines, car nous redirigerons automatiquement les travaux des anciens pools hébergés vers l’image appropriée dans le nouveau pool unifié.

Afficher les informations de pool correctes pour chaque travail

Auparavant, lorsque vous utilisiez une matrice pour développer des travaux ou une variable pour identifier un pool, nous avions des difficultés à afficher les informations de pool correctes dans les pages journaux. Avec cette mise à jour, nous avons résolu les problèmes qui entraînaient l’affichage d’informations de pool incorrectes pour certains travaux.

Support au sein du produit pour la gestion des tests non fiables

Les tests flaky peuvent affecter la productivité des développeurs, car les échecs de test peuvent ne pas être liés aux modifications sous test. Ils peuvent également avoir un impact sur la qualité du code expédié. C’est pourquoi nous avons ajouté la prise en charge in-product pour la gestion des tests flaky. Cette fonctionnalité prend en charge le cycle de vie de bout en bout avec la détection, la création de rapports et la résolution. La gestion des tests non fiables prend en charge la détection système et personnalisée.

La détection du système est disponible via la fonctionnalité de réexécution des tâches VSTest. Un test non fiable est un test qui fournit des résultats différents, tels que réussir ou échouer, même en l’absence de modifications dans le code source ou l’environnement d’exécution. Toutes les autres exécutions de test pour la même branche sont également marquées comme flaky jusqu’à ce qu’elles soient résolues et non marquées. Vous pouvez également brancher votre mécanisme de détection personnalisé à l’aide de nos API. Une fois qu’un test est identifié comme flassant, vous pouvez obtenir les détails dans le rapport de test dans le pipeline. Vous pouvez ensuite décider si les tests flaky ont un impact sur votre défaillance du pipeline. Par défaut, les informations de test flaky sont disponibles sous forme de métadonnées supplémentaires.

In-product support for flaky test management.

Voici un exemple de rapport avec le résumé du test.

Example of a report with the test summary.

Pour plus d’informations sur la gestion des tests flaky, consultez la documentation ici.

Améliorations apportées au Centre de déploiement pour WebApp dans le Portail Azure

Nous avons amélioré le Centre de déploiement pour WebApp dans le Portail Azure avec prise en charge des pipelines avec plusieurs artefacts. À présent, si un artefact non principal d’Azure Pipelines est déployé sur l’application web, vous obtenez des détails pertinents à partir du Portail Azure. Vous disposez également d’un lien profond vers le dépôt déployé pour accéder directement au dépôt à partir du Portail Azure. Le dépôt peut être hébergé dans Azure Repos ou dans GitHub.

Déclencheurs CI pour les nouvelles branches

Il s’agit d’une demande longue en attente pour ne pas déclencher les builds CI lorsqu’une nouvelle branche est créée et quand cette branche n’a pas de modifications. Penchez-vous sur les exemples suivants :

  • Vous utilisez l’interface web pour créer une branche basée sur une branche existante. Cela déclenche immédiatement une nouvelle build CI si votre filtre de branche correspond au nom de la nouvelle branche. Cela est indésirable, car le contenu de la nouvelle branche est identique par rapport à la branche existante.
  • Vous disposez d’un référentiel avec deux dossiers : l’application et la documentation. Vous configurez un filtre de chemin pour que CI corresponde à « app ». En d’autres termes, vous ne souhaitez pas créer de build si une modification a été envoyée à la documentation. Vous créez une branche localement, apportez des modifications à la documentation, puis envoyez cette branche au serveur. Nous avons utilisé pour déclencher une nouvelle build CI. Cela n’est pas indésirable, car vous avez explicitement demandé de ne pas rechercher de modifications dans le dossier docs. Toutefois, en raison de la façon dont nous avons géré un nouvel événement de branche, il semblerait qu’une modification ait également été apportée au dossier de l’application.

Maintenant, nous avons un meilleur moyen de gérer ci pour les nouvelles branches afin de résoudre ces problèmes. Lorsque vous publiez une nouvelle branche, nous recherchons explicitement de nouvelles validations dans cette branche et case activée s’ils correspondent aux filtres de chemin d’accès.

Intégration de Terraform à Azure Pipelines

Terraform est un outil open source pour le développement, la modification et l’efficacité de l’infrastructure de gestion des versions. Terraform codifie les API dans des fichiers de configuration déclaratifs, ce qui vous permet de définir et de provisionner une infrastructure à l’aide d’un langage de configuration de haut niveau. Vous pouvez utiliser l’extension Terraform pour créer des ressources dans tous les principaux fournisseurs d’infrastructure : Azure, Amazon Web Services (AWS) et Google Cloud Platform (GCP).

Pour en savoir plus sur l’extension Terraform, consultez la documentation ici.

Terraform integration with Azure Pipelines.

Intégration à Google Analytics

L’infrastructure d’expériences Google Analytics vous permet de tester presque toutes les modifications ou variantes d’un site web ou d’une application pour mesurer son impact sur un objectif spécifique. Par exemple, vous pouvez avoir des activités que vous souhaitez que vos utilisateurs se terminent (par exemple, effectuer un achat, s’inscrire à un bulletin d’informations) et/ou des métriques que vous souhaitez améliorer (par exemple, chiffre d’affaires, durée de session, taux de rebond). Ces activités vous permettent d’identifier les modifications qui méritent d’être implémentées en fonction de l’impact direct qu’elles ont sur les performances de votre fonctionnalité.

L’extension d’expériences Google Analytics pour Azure DevOps ajoute des étapes d’expérimentation aux pipelines de génération et de mise en production. Vous pouvez donc itérer, apprendre et déployer à un rythme accéléré en gérant les expériences en continu tout en obtenant tous les avantages DevOps d’Azure Pipelines.

Vous pouvez télécharger l’extension d’expériences Google Analytics à partir de la Place de marché.

Integration with Google Analytics.

Mise en cache de pipeline (préversion publique)

La mise en cache du pipeline vous permet d’enregistrer les résultats d’une opération de longue durée, comme une restauration de package ou une compilation de dépendances, et de le restaurer lors de l’exécution suivante d’un pipeline. Cela peut entraîner des builds plus rapides.

Pour plus d’informations, consultez le billet de blog avec l’annonce complète ici.

Groupe de variables Pipeline et commandes de gestion des variables

Il peut être difficile de porter des pipelines YAML d’un projet à un autre, car vous devez configurer manuellement les variables de pipeline et les groupes de variables. Toutefois, avec les commandes de gestion des variables et du groupe de variables de pipeline, vous pouvez maintenant créer un script pour configurer et gérer des variables de pipeline et des groupes de variables qui peuvent à leur tour être contrôlés par la version, ce qui vous permet de partager facilement les instructions permettant de déplacer et de configurer des pipelines d’un projet à un autre.

Exécution d’un pipeline pour une branche PR

Lors de la création d’une demande de tirage, il peut être difficile de valider si les modifications peuvent interrompre l’exécution du pipeline sur la branche cible. Toutefois, avec la possibilité de déclencher une exécution de pipeline ou de mettre en file d’attente une build pour une branche pr, vous pouvez maintenant valider et visualiser les modifications en cours d’exécution sur le pipeline cible. Pour plus d’informations, reportez-vous à az pipelines run and az pipelines build queue command command.

Ignorer la première exécution du pipeline

Lors de la création de pipelines, vous souhaitez parfois créer et valider un fichier YAML et ne pas déclencher l’exécution du pipeline, car cela peut entraîner une exécution défectueuse en raison de diverses raisons : l’infrastructure n’est pas prête ou n’a pas besoin de créer et de mettre à jour des groupes de variables/variables, etc. Avec Azure DevOps CLI, vous pouvez désormais ignorer la première exécution automatisée du pipeline lors de la création d’un pipeline en incluant le paramètre --skip-first-run. Pour plus d’informations, reportez-vous à az pipeline create command documentation .

Amélioration de la commande de point de terminaison de service

Les commandes CLI de point de terminaison de service prises en charge uniquement par azure rm et github service endpoint configurent et gérent. Toutefois, avec cette version, les commandes de point de terminaison de service vous permettent de créer n’importe quel point de terminaison de service en fournissant la configuration via le fichier et fournit des commandes optimisées : az devops service-endpoint github et az devops service-endpoint azurerm, qui fournissent une prise en charge de première classe pour créer des points de terminaison de service de ces types. Pour plus d’informations, reportez-vous à la documentation de la commande.

É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 commentaires pour signaler un problème ou fournir une suggestion.

Make a suggestion

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

Merci,

Sam Guckenheimer