Traçabilité bidirectionnelle entre les mises en production et les problèmes Jira - Mise à jour sprint 154

  • Article

Dans la mise à jour Sprint 154 d’Azure DevOps, nous publions l’application Azure Pipelines pour Jira sur la Place de marché Atlassian. L’intégration ajoute des liens vers les problèmes Jira en tant qu’éléments de travail déployés avec les versions et vous permet d’afficher les détails du déploiement directement dans les problèmes Jira.

Nous avons également apporté des améliorations pour faciliter la recherche et le suivi des éléments de travail. La zone de recherche prend désormais en charge la recherche instantanée d’éléments de travail et la liste des éléments de travail récents. En outre, Wiki vous permet désormais de créer des documents en direct en vous permettant de créer et de suivre des éléments de travail à l’aide du contenu wiki.

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 Pipelines :

Azure Test Plans :

Azure Repos :

Azure Artifacts :

Wiki :

Général

Disponibilité générale d’Azure DevOps CLI

En février, nous avons introduit l’extension Azure DevOps pour Azure CLI. L’extension vous permet d’interagir avec Azure DevOps à partir de la ligne de commande. Nous avons collecté vos commentaires qui nous ont aidés à améliorer l’extension et à ajouter d’autres commandes. Nous sommes maintenant heureux d’annoncer que l’extension est en disponibilité générale.

Pour en savoir plus sur Azure DevOps CLI, consultez la documentation ici.

Azure Boards

Rechargement dynamique de l’élément de travail

Auparavant, lors de la mise à jour d’un élément de travail et qu’un deuxième membre de l’équipe apportait des modifications au même élément de travail, le deuxième utilisateur perdait ses modifications. Maintenant, tant que vous modifiez tous les deux des champs différents, vous verrez des mises à jour actives des modifications apportées à l’élément de travail.

Rechargement dynamique de l’élément de travail.

Gérer les chemins d’itération et de zone à partir de la ligne de commande

Vous pouvez maintenant gérer les chemins d’itération et de zone à partir de la ligne de commande à l’aide des az boards iteration commandes et az boards area . Par exemple, vous pouvez configurer et gérer les chemins d’itération et de zone de manière interactive à partir de l’interface CLI, ou automatiser l’ensemble de l’installation à l’aide d’un script. Pour plus d’informations sur les commandes et la syntaxe, consultez la documentation ici.

Colonne parente de l’élément de travail en tant qu’option de colonne

Vous avez maintenant la possibilité de voir le parent de chaque élément de travail dans votre backlog de produit ou backlog de sprint. Pour activer cette fonctionnalité, accédez à Options de colonne dans le backlog souhaité, puis ajoutez la colonne Parent .

Ajoutez une colonne parente en tant que colonne à un backlog.

Recherche instantanée d’éléments de travail

Nous vous avons permis de trouver facilement des éléments de travail, des tableaux, des backlogs et des sprints récemment visités. Vous pouvez maintenant accéder aux éléments de travail récemment visités en cliquant sur la zone de recherche dans Azure Boards.

Conseil

Vous pouvez appeler la zone de recherche en tapant le raccourci clavier « / ».

Accédez aux éléments de travail récemment affichés et aux éléments de tableau à partir de la recherche.

Rechercher un élément de travail au fur et à mesure de la frappe

Vous pouvez maintenant afficher les résultats de la recherche d’élément de travail à mesure que vous tapez dans la zone de recherche. Cela vous aidera à accéder rapidement à l’élément de travail de votre choix.

Affichez les résultats de la recherche à mesure que vous tapez.

En outre, vous pouvez accéder au code et aux résultats de la recherche wiki sans avoir à changer d’onglet en atterrissant sur la recherche d’éléments de travail, puis en modifiant les onglets pour afficher les résultats de la recherche de wiki ou de package de code.

Accédez au code et aux résultats de recherche wiki à partir de Azure Boards.

Modifier le processus utilisé par un projet

Vos outils doivent changer comme le fait votre équipe. Vous pouvez maintenant passer de n’importe quel modèle de processus prête à l’emploi à tout autre processus prête à l’emploi. Par exemple, vous pouvez changer votre projet de l’utilisation d’Agile à Scrum, ou de Base à Agile. Vous trouverez une documentation détaillée complète ici.

Modifier le processus utilisé par un projet.

Masquer les champs personnalisés de la disposition

Vous pouvez désormais masquer les champs personnalisés de la disposition du formulaire lors de la personnalisation de votre processus. Le champ sera toujours disponible à partir des requêtes et des API REST. Cela s’avère pratique pour le suivi des champs supplémentaires lors de l’intégration à d’autres systèmes.

Masquer un champ personnalisé d’une disposition d’élément de travail.

Azure Pipelines

Application Azure Pipelines pour Jira

Nous sommes ravis d’annoncer la disponibilité de l’application Azure Pipeline pour Jira. L’intégration permet une liaison bidirectionnelle entre les versions dans Azure Pipelines et les problèmes dans le cloud logiciel Jira. Il simplifie la génération des notes de publication en suivant les problèmes Jira mentionnés dans les validations GitHub déployées avec les versions.

Application Azure Pipelines pour Jira.

En outre, il affiche des informations de build et de mise en production à partir d’Azure Pipelines et les affiche dans le panneau de développement des problèmes. Cela a permis de suivre comment et quand un problème est remis, et fournit un cycle de développement serré, de la création du problème aux déploiements suivis dans Jira.

Informations de build et de mise en production suivies dans Jira.

Améliorations apportées à l’application Azure Pipelines pour Slack

En février, nous avons publié l’application Azure Pipelines pour Slack afin de vous aider à surveiller vos pipelines. Avec cette mise à jour, nous avons amélioré l’application. Utilise @mention dans le canal Slack lorsqu’une notification d’échec de build que vous avez déclenchée est envoyée. En outre, il vous avertit lorsque vous êtes un approbateur sur une notification d’approbation de déploiement de mise en production en attente.

En outre, vous pouvez maintenant coller un lien vers une build ou une mise en production dans l’application Azure Pipelines et obtenir un aperçu complet du pipeline. Cela ajoute du contexte au lien et facilite la navigation vers Azure DevOps.

Par exemple, le collage d’un lien vers une build affiche les détails de la build et de la status actuelle.

Déploiement d’URL (aperçus de liens) dans l’application Azure Pipelines pour Slack.

Pour plus d’informations sur cette mise à jour, consultez le billet de blog contenant l’annonce complète ici.

Pool hébergé unique

Notes

Il s’agit d’un changement à venir que nous souhaitons communiquer à l’avance.

Avoir plusieurs pools hébergés peut parfois être déroutant. Vous n’obtenez pas une image précise de l’endroit où l’accès concurrentiel est consommé. Par exemple, si vous avez 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 est en attente sur un pool hébergé spécifique (par exemple, VS2017 hébergé) avec tous les agents inactifs, vous pouvez penser que le service Azure Pipelines est interrompu sans vous rendre compte que l’accès concurrentiel est éventuellement consommé dans d’autres pools hébergés (par exemple, Ubuntu 1604 hébergé).

Nous allons mettre à jour nos expériences de gestion des pools d’agents pour inclure un nouveau pool d’agents hébergés unifié appelé Azure Pipelines. Cela remplacera bientôt les autres pools hébergés que vous avez : Hosted, Hosted VS2017, Hosted Ubuntu 1604, Hosted Windows 2019 par VS2019, Hosted macOS et Hosted macOS High Sierra.

Une fois cette fonctionnalité déployée, 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 à 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é.

Mise à jour de l’interface du pool d’agents dans les paramètres de organization

Auparavant, nous avons modifié la page de gestion des pools d’agents dans les paramètres du projet pour inclure une nouvelle interface utilisateur. Avec cette mise à jour, nous mettons à jour l’interface des pools d’agents sous les paramètres organization. Cette nouvelle interface vous aidera avec une fonctionnalité à venir qui inclura la consolidation pour les pools hébergés et la possibilité de suivre la consommation des travaux simultanés.

Pour plus d’informations sur la fonctionnalité à venir, consultez la note de publication sur le pool hébergé unique.

Contrôler les variables qui peuvent être remplacées au moment de la file d’attente

Actuellement, vous pouvez utiliser l’interface utilisateur ou l’API REST pour mettre à jour les valeurs de n’importe quelle variable avant de commencer une nouvelle exécution. Bien que l’auteur du pipeline puisse marquer certaines variables comme _settable at queue time_, le système n’a pas appliqué cela, ni empêché la définition d’autres variables. En d’autres termes, le paramètre a été utilisé uniquement pour demander des entrées supplémentaires lors du démarrage d’une nouvelle exécution.

Nous avons ajouté un nouveau paramètre organization qui applique le _settable at queue time_ paramètre . Cela vous permet de contrôler les variables qui peuvent être modifiées lors du démarrage d’une nouvelle exécution. À l’avenir, vous ne pouvez pas modifier une variable qui n’est pas marquée par l’auteur comme _settable at queue time_.

Notes

Ce paramètre est désactivé par défaut dans les organisations existantes, mais il est activé par défaut lorsque vous créez un organization Azure DevOps.

Prise en charge des pièces jointes de test volumineuses

La tâche publier les résultats des tests dans Azure Pipelines vous permet de publier les résultats des tests lorsque des tests sont exécutés pour fournir une expérience de création de rapports et d’analytique de test complète. Jusqu’à présent, il y avait une limite de 100 Mo pour les pièces jointes de test à la fois pour la série de tests et les résultats des tests. Cela a limité le chargement de fichiers volumineux comme les vidages sur incident ou les vidéos. Avec cette mise à jour, nous avons ajouté la prise en charge des pièces jointes de test volumineuses, ce qui vous permet d’avoir toutes les données disponibles pour résoudre les échecs de vos tests.

Déploiements dans le pipeline YAML

Un travail de déploiement est un type spécial de travail utilisé pour déployer votre application dans un environnement. Avec cette mise à jour, nous avons ajouté la prise en charge des références d’étape dans un travail de déploiement. Par exemple, vous pouvez définir un ensemble d’étapes dans un fichier et y faire référence dans un travail de déploiement.

Nous avons également ajouté la prise en charge de propriétés supplémentaires au travail de déploiement. Par exemple, voici quelques propriétés d’un travail de déploiement que vous pouvez désormais définir:

  • timeoutInMinutes : durée d’exécution du travail avant l’annulation automatique
  • cancelTimeoutInMinutes : le temps nécessaire à l’exécution toujours même en cas d’annulation de tâches avant de les terminer
  • condition : exécuter le travail de manière conditionnelle
  • variables : les valeurs codées en dur peuvent être ajoutées directement, ou des groupes de variables , un groupe de variables soutenu par un coffre de clés Azure peut être référencé ou vous pouvez faire référence à un ensemble de variables définies dans un fichier.
  • continueOnError : si les travaux futurs doivent s’exécuter même en cas d’échec de ce travail de déploiement ; la valeur par défaut est « false »

Pour plus d’informations sur les travaux de déploiement et la syntaxe complète permettant de spécifier un travail de déploiement, consultez Tâche de déploiement.

Optimisation de l’intégration

Optimizely est une plateforme puissante de test A/B et d’indicateur de fonctionnalités pour les équipes de produits. L’intégration d’Azure Pipelines à la plateforme d’expérimentation Optimizely permet aux équipes produit de tester, d’apprendre et de déployer à un rythme accéléré, tout en profitant de tous les avantages DevOps d’Azure Pipelines.

L’extension Optimizely pour Azure DevOps ajoute des étapes d’expérimentation et de déploiement d’indicateur de fonctionnalité aux pipelines de build et de mise en production, afin que vous puissiez itérer, déployer des fonctionnalités et les restaurer en continu à l’aide d’Azure Pipelines.

En savoir plus sur l’extension Azure DevOps Optimizely ici.

Optimiser l’expérience

Ajouter une version GitHub en tant que source d’artefact

Vous pouvez maintenant lier vos versions GitHub en tant que source d’artefacts dans les pipelines de mise en production Azure DevOps. Cela vous permettra de consommer la version GitHub dans le cadre de vos déploiements.

Lorsque vous cliquez sur Ajouter un artefact dans la définition du pipeline de mise en production, vous trouverez le nouveau type de source De mise en production GitHub . Vous pouvez fournir la connexion de service et le dépôt GitHub pour utiliser la version GitHub. Vous pouvez également choisir une version par défaut pour la version gitHub à utiliser comme dernière version de balise spécifique ou sélectionner au moment de la création de la version. Une fois qu’une version de GitHub est liée, elle est automatiquement téléchargée et mise à disposition dans vos travaux de mise en production.

Ajoutez une version GitHub en tant que source d’artefact.

Payer des pipelines supplémentaires à partir du portail Azure DevOps

Auparavant, vous deviez accéder à la Place de marché pour payer des pipelines supplémentaires. Vous pouvez maintenant acheter des pipelines supplémentaires à partir du portail Azure DevOps. Vous pouvez augmenter ou diminuer le nombre de CI/CD hébergés par Microsoft ou auto-hébergés à partir de la facturation des paramètres > de l’organisation.

Pour en savoir plus, consultez la documentation sur l’achat de CI/CD ici.

Approuver des mises en production directement à partir du hub Des mises en production

L’action en cas d’approbations en attente a été facilitée. Jusqu’à présent, il était possible d’approuver une version à partir de la page de détails de la version. Nous vous permetons maintenant d’approuver des mises en production directement à partir du hub Mises en production.

Approuvez les mises en production directement à partir du hub des mises en production.

Nous avons ajouté un lien vers l’affichage des ressources des environnements Kubernetes afin que vous puissiez accéder au panneau Azure pour le cluster correspondant. Cela s’applique aux environnements mappés à des espaces de noms dans Azure Kubernetes Service clusters.

Azure Kubernetes Service lien cluster dans la vue de ressources Kubernetes des environnements.

Filtres de dossiers de mise en production dans les abonnements de notification

Les dossiers permettent d’organiser les pipelines pour faciliter la détectabilité et le contrôle de sécurité. Souvent, vous pouvez configurer des Notifications par e-mail personnalisées pour tous les pipelines de mise en production, qui sont représentés par tous les pipelines sous un dossier. Auparavant, vous deviez configurer plusieurs abonnements ou avoir une requête complexe dans les abonnements pour obtenir des e-mails ciblés. Avec cette mise à jour, vous pouvez maintenant ajouter une clause de dossier de mise en production aux événements de déploiement terminés et d’approbation en attente , et simplifier les abonnements.

Filtres de dossiers de mise en production dans les abonnements de notification.

Déployer des référentiels Git externes sur Azure Kubernetes Services (AKS)

Auparavant, nous prenions en charge Azure Repos et GitHub en tant qu’emplacements de code dans le centre de déploiement AKS. Avec cette mise à jour, nous ajoutons la prise en charge des dépôts Git externes afin que vous puissiez déployer votre code à partir de n’importe quel dépôt Git public ou privé sur AKS.

Déployez sur AKS à partir de vos dépôts Git externes.

Prise en charge des dépôts Bitbucket dans les projets DevOps

Nous avons ajouté la prise en charge des dépôts Bitbucket aux projets DevOps. Vous pouvez maintenant bénéficier de l’expérience OAuth et d’une liste remplie de référentiels et de branches à sélectionner lors du déploiement sur les ressources Azure.

Dépôts Bitbucket dans des projets DevOps.

Sélectionner un fichier Dockerfile dans le centre de déploiement pour les conteneurs AKS et WebApp

Vous pouvez maintenant sélectionner un fichier Dockerfile dans le centre de déploiement pour LES conteneurs AKS et WebApp. Cela s’avère utile lorsque vous souhaitez gérer différentes versions de Dockerfile ou avoir plusieurs applications dans le même dépôt. Avec cela, vous serez en mesure de sélectionner l’application/fichier DockerFile spécifique que vous souhaitez envoyer (push).

sélectionnez un fichier Dockerfile dans le centre de déploiement pour LES conteneurs AKS et WebApp.

Azure Test Plans

Aperçu public de la page Nouveau plan de test

Une nouvelle page Test Plans (Test Plans*) est disponible en préversion publique pour toutes les organisations Azure DevOps. La nouvelle page fournit des vues simplifiées pour vous aider à vous concentrer sur la tâche à accomplir : planification des tests, création ou exécution. Il est également sans encombrement et cohérent avec le reste de l’offre Azure DevOps.

Page Nouveau plan de test.

La nouvelle page peut être active à partir des fonctionnalités en préversion, comme indiqué ci-dessous.

Activer la nouvelle page Test Plans.

La page Test Plans* disposera de la plupart des fonctionnalités de la page existante, en plus des nouvelles fonctionnalités telles que les plans de test de copie et de clonage. Nous continuerons à ajouter des fonctionnalités de planification et de création de tests toutes les 3 semaines.

Nouvelles fonctionnalités de page Test Plans.

Pour en savoir plus sur la nouvelle page, consultez la documentation ici.

Azure Repos

Audit des événements Azure Repos

Nous avons ajouté des événements pour Repos qui peuvent être consommés via l’onglet d’audit Azure DevOps dans les paramètres de organization. Vous pouvez maintenant afficher les événements des stratégies lorsqu’elles sont créées, supprimées, modifiées ou contournées. En outre, vous pouvez afficher les événements pour les dépôts lorsqu’ils sont créés (y compris par duplication ou annulation de la suppression), renommés, supprimés de manière réversible, détruits ou lorsque le branche par défaut modifié.

Audit des événements Azure Repos.

Azure Artifacts

Améliorations apportées au temps de chargement de la page de flux

Nous sommes ravis d’annoncer que nous avons amélioré le temps de chargement de la page de flux. En moyenne, les temps de chargement des pages de flux ont diminué de 10 %. Les flux les plus importants ont connu la plus grande amélioration, le temps de chargement de la page de flux au 99e centile (temps de chargement dans les 99 % les plus élevés de tous les flux) a diminué de 75 %.

Wiki

Édition enrichie pour les pages wiki de code

Auparavant, lors de la modification d’une page wiki de code, vous étiez redirigé vers le hub Azure Repos pour modification. Actuellement, le hub référentiel n’est pas optimisé pour la modification markdown.

Vous pouvez maintenant modifier une page wiki de codes dans l’éditeur côte à côte à l’intérieur du wiki. Cela vous permet d’utiliser la barre d’outils Markdown enrichie pour créer votre contenu, ce qui rend l’expérience d’édition identique à celle du wiki du projet. Vous pouvez toujours choisir de modifier dans les dépôts en sélectionnant l’option Modifier dans les dépôts dans le menu contextuel.

Modification enrichie pour le wiki de code dans Wiki Hub.

Créer et incorporer des éléments de travail à partir d’une page wiki

À mesure que nous avons écouté vos commentaires, nous avons entendu que vous utilisiez wiki pour capturer des documents de brainstorming, des documents de planification, des idées sur des fonctionnalités, des documents de spécifications, des minutes de réunion. Vous pouvez désormais facilement créer des fonctionnalités et des récits utilisateur directement à partir d’un document de planification sans quitter la page wiki.

Pour créer un élément de travail, sélectionnez le texte dans la page wiki dans laquelle vous souhaitez incorporer l’élément de travail, puis sélectionnez Nouvel élément de travail. Cela vous fait gagner du temps, car vous n’avez pas à créer d’abord l’élément de travail, à accéder à modifier, puis à trouver l’élément de travail à incorporer. Cela réduit également le changement de contexte, car vous ne sortez pas de l’étendue wiki.

Créez et incorporez des éléments de travail à partir du contenu wiki.

Pour en savoir plus sur la création et l’incorporation d’un élément de travail à partir du wiki, consultez notre documentation ici.

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

Faire une suggestion

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

Merci,

Biju Venugopal