Créer un tableau de bord sans équipe - Sprint 162 Update

Dans la mise à jour Sprint 162 d’Azure DevOps, nous sommes ravis d’annoncer que vous pouvez créer un tableau de bord sans l’associer à une équipe. Le tableau de bord sera visible par tous les membres du projet et vous pouvez décider qui peut le modifier/le gérer.

En outre, nous avons ajouté la miniature du sprint burndown. Vous pouvez maintenant le configurer pour qu’il soit gravé en fonction des récits, des points d’histoire ou du nombre de tâches.

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

Fonctionnalités

Azure Repos :

• Nouvelles pages d’accueil de conversion de plateforme web
• Prise en charge de la langue Kotlin

Azure Pipelines :

• Mise à jour de l’interface utilisateur des pipelines en plusieurs étapes
• L’option VSTest TestResultsDirectory est disponible dans l’interface utilisateur de la tâche
• Utiliser étend mot clé dans les pipelines
• Prise en charge de Markdown dans les messages d’erreur de test automatisé
• Collecter les métadonnées automatiques et spécifiées par l’utilisateur à partir du pipeline
• interface utilisateur des connexions Mises à jour au service
• Déploiements de machines virtuelles avec des environnements
• Ignorer des étapes dans un pipeline YAML

Création de rapports :

• Miniature de burndown de sprint inline
• Créer un tableau de bord sans équipe

Azure Repos

Nouvelles pages d’accueil de conversion de plateforme web

Nous avons mis à jour l’expérience utilisateur des pages d’accueil Repos pour la rendre moderne, rapide et adaptée aux mobiles. Voici deux exemples de pages qui ont été mises à jour. Nous continuerons à mettre à jour d’autres pages dans les mises à jour ultérieures.

Expérience web :

Expérience mobile :

Prise en charge de la langue Kotlin

Nous sommes heureux d’annoncer que nous prenons désormais en charge la mise en surbrillance du langage Kotlin dans l’éditeur de fichiers. La mise en surbrillance améliore la lisibilité de votre fichier texte Kotlin et vous aide à rechercher rapidement les erreurs. Nous avons hiérarchisé cette fonctionnalité en fonction d’une suggestion du Developer Community.

Azure Pipelines

Mise à jour de l’interface utilisateur des pipelines en plusieurs étapes

Une version mise à jour de l’interface utilisateur des pipelines à plusieurs étapes est désormais disponible par défaut. L’expérience de pipelines en plusieurs étapes apporte des améliorations et une facilité d’utilisation à l’interface utilisateur du portail du pipeline. Vous pouvez afficher et gérer vos pipelines en choisissant Pipelines dans le menu de gauche. En outre, vous pouvez explorer et afficher les détails du pipeline, les détails de l’exécution, l’analytique de pipeline, les détails du travail, les journaux, etc.

Pour en savoir plus sur l’expérience utilisateur des pipelines à plusieurs étapes, consultez la documentation ici.

L’option VSTest TestResultsDirectory est disponible dans l’interface utilisateur de la tâche

La tâche VSTest stocke les résultats des tests et les fichiers associés dans le $(Agent.TempDirectory)\TestResults dossier . Nous avons ajouté une option à l’interface utilisateur de la tâche pour vous permettre de configurer un autre dossier pour stocker les résultats des tests. Désormais, toutes les tâches suivantes qui ont besoin des fichiers dans un emplacement particulier peuvent les utiliser.

Utiliser étend mot clé dans les pipelines

Actuellement, les pipelines peuvent être pris en compte dans des modèles, ce qui favorise la réutilisation et réduit le réutilisable. La structure globale du pipeline était toujours définie par le fichier YAML racine. Avec cette mise à jour, nous avons ajouté une façon plus structurée d’utiliser des modèles de pipeline. Un fichier YAML racine peut désormais utiliser la mot clé étend pour indiquer que la structure de pipeline main se trouve dans un autre fichier. Cela vous permet de contrôler les segments qui peuvent être étendus ou modifiés et les segments qui sont fixes. Nous avons également amélioré les paramètres de pipeline avec des types de données pour clarifier les hooks que vous pouvez fournir.

Cet exemple montre comment fournir des hooks simples que l’auteur du pipeline peut utiliser. Le modèle exécute toujours une build, exécute éventuellement des étapes supplémentaires fournies par le pipeline, puis exécute une étape de test facultative.

# azure-pipelines.yml
extends:
  template: build-template.yml
  parameters:
    runTests: true
    postBuildSteps:
    - script: echo This step runs after the build!
    - script: echo This step does too!

# build-template.yml
parameters:
- name: runTests
  type: boolean
  default: false
- name: postBuildSteps
  type: stepList
  default: []
steps:
- task: MSBuild@1   # this task always runs
- ${{ if eq(parameters.runTests, true) }}:
  - task: VSTest@2  # this task is injected only when runTests is true
- ${{ each step in parameters.postBuildSteps }}:
  - ${{ step }}

Prise en charge de Markdown dans les messages d’erreur de test automatisé

Nous avons ajouté la prise en charge markdown aux messages d’erreur pour les tests automatisés. Vous pouvez désormais facilement mettre en forme des messages d’erreur pour la série de tests et les résultats des tests afin d’améliorer la lisibilité et de faciliter l’expérience de dépannage des échecs de test dans Azure Pipelines. La syntaxe Markdown prise en charge est disponible ici.

Collecter les métadonnées automatiques et spécifiées par l’utilisateur à partir du pipeline

Vous pouvez maintenant activer la collecte automatique et spécifiée par l’utilisateur de métadonnées à partir de tâches de pipeline. Vous pouvez utiliser des métadonnées pour appliquer une stratégie d’artefact à un environnement à l’aide de l’case activée d’évaluation de l’artefact.

interface utilisateur des connexions Mises à jour au service

Nous avons travaillé sur une expérience utilisateur mise à jour pour gérer vos connexions de service. Ces mises à jour rendent l’expérience de connexion de service moderne et cohérente avec la direction d’Azure DevOps. Nous avons introduit la nouvelle interface utilisateur pour les connexions de service en tant que fonctionnalité en préversion plus tôt cette année. Merci à tous ceux qui ont essayé la nouvelle expérience et nous ont fait part de leurs précieux commentaires.

En plus de l’actualisation de l’expérience utilisateur, nous avons également ajouté deux fonctionnalités essentielles pour l’utilisation des connexions de service dans les pipelines YAML : les autorisations de pipeline, les approbations et les vérifications.

La nouvelle expérience utilisateur sera activée par défaut avec cette mise à jour. Vous aurez toujours la possibilité de refuser la préversion.

Notes

Nous prévoyons d’introduire le partage entre projets des connexions de service en tant que nouvelle fonctionnalité. Vous trouverez plus d’informations sur l’expérience de partage et les rôles de sécurité ici.

Déploiements de machines virtuelles avec des environnements

L’une des fonctionnalités les plus demandées dans les environnements était les déploiements de machines virtuelles. Avec cette mise à jour, nous activons la ressource Machine virtuelle dans les environnements. Vous pouvez désormais orchestrer des déploiements sur plusieurs machines et effectuer des mises à jour propagées à l’aide de pipelines YAML. Vous pouvez également installer l’agent directement sur chacun de vos serveurs cibles et piloter le déploiement propagé sur ces serveurs. En outre, vous pouvez utiliser le catalogue de tâches complet sur vos ordinateurs cibles.

Un déploiement propagé remplace les instances de la version précédente d’une application par des instances de la nouvelle version de l’application sur un ensemble de machines (groupe propagé) dans chaque itération.

Par exemple, ci-dessous, les mises à jour de déploiement propagées jusqu’à cinq cibles dans chaque itération. maxParallel détermine le nombre de cibles pouvant être déployées en parallèle. La sélection prend en compte le nombre de cibles qui doivent rester disponibles à tout moment, à l’exception des cibles sur lesquelles sont déployées. Il est également utilisé pour déterminer les conditions de réussite et d’échec lors d’un déploiement.

jobs:
- deployment:
  displayName: web
  environment:
    name: musicCarnivalProd
    resourceType: VirtualMachine
  strategy:                 
    rolling:
      maxParallel: 5 #for percentages, mention as x%
      preDeploy:
        steps:
        - script: echo initialize, cleanup, backup, install certs...
      deploy:              
        steps:                                     
        - script: echo deploy ...      
      routeTraffic:
        steps:
        - script: echo routing traffic...   
      postRouteTraffic:
        steps:          
        - script: echo health check post routing traffic...  
      on:
        failure:
          steps:
          - script: echo restore from backup ..     
        success:
          steps:
          - script: echo notify passed...

Notes

Avec cette mise à jour, tous les artefacts disponibles à partir du pipeline actuel et des ressources de pipeline associées sont téléchargés uniquement dans deploy le hook de cycle de vie. Toutefois, vous pouvez choisir de télécharger en spécifiant la tâche Télécharger l’artefact de pipeline. Il existe quelques lacunes connues dans cette fonctionnalité. Par exemple, lorsque vous retentez un index, elle va réexécuter le déploiement sur toutes les machines virtuelles, pas seulement sur les cibles ayant échoué. Nous nous efforçons de combler ces lacunes dans les futures mises à jour.

Ignorer des étapes dans un pipeline YAML

Lorsque vous démarrez une exécution manuelle, vous pouvez parfois ignorer quelques étapes dans votre pipeline. Par instance, si vous ne souhaitez pas déployer en production ou si vous souhaitez ignorer le déploiement dans quelques environnements en production. Vous pouvez maintenant effectuer cette opération avec vos pipelines YAML.

Le panneau de pipeline d’exécution mis à jour présente la liste des étapes du fichier YAML, et vous avez la possibilité d’ignorer une ou plusieurs de ces étapes. Vous devez faire preuve de prudence lorsque vous ignorez les étapes. Par instance, si votre première étape produit certains artefacts nécessaires pour les étapes suivantes, vous ne devez pas ignorer la première étape. Le panneau d’exécution présente un avertissement générique chaque fois que vous ignorez des étapes qui ont des dépendances en aval. Il vous appartient de déterminer si ces dépendances sont de véritables dépendances d’artefact ou si elles sont simplement présentes pour le séquencement des déploiements.

Ignorer une étape équivaut à rewiringer les dépendances entre les étapes. Toutes les dépendances immédiates en aval de la phase ignorée dépendent du amont parent de la phase ignorée. Si l’exécution échoue et si vous tentez de réexécuter une étape ayant échoué, cette tentative aura également le même comportement d’évitement. Pour modifier les étapes ignorées, vous devez démarrer une nouvelle exécution.

Rapports

Miniature de burndown de sprint inline

Le Sprint Burndown est de retour ! Il y a quelques sprints, nous avons supprimé le burndown de sprint en contexte des en-têtes Sprint Burndown et Taskboard. En fonction de vos commentaires, nous avons amélioré et réintroduit la miniature du sprint burndown.

Cliquez sur la miniature pour afficher immédiatement une version plus grande du graphique avec une option permettant d’afficher le rapport complet sous l’onglet Analytics. Toutes les modifications apportées au rapport complet seront reflétées dans le graphique affiché dans l’en-tête. Vous pouvez donc maintenant le configurer pour qu’il soit brûlé en fonction des récits, des points d’histoire ou du nombre de tâches, plutôt que de la seule quantité de travail restante.

Créer un tableau de bord sans équipe

Vous pouvez maintenant créer un tableau de bord sans l’associer à une équipe. Lors de la création d’un tableau de bord, sélectionnez le type Tableau de bord du projet .

Un tableau de bord de projet est semblable à un tableau de bord d’équipe, sauf qu’il n’est pas associé à une équipe et que vous pouvez décider qui peut modifier/gérer le tableau de bord. Tout comme un tableau de bord d’équipe, il est visible par tout le monde dans le projet.

Tous les widgets Azure DevOps qui nécessitent un contexte d’équipe ont été mis à jour pour vous permettre de sélectionner une équipe dans leur configuration. Vous pouvez ajouter ces widgets aux tableaux de bord de projet et sélectionner l’équipe spécifique de votre choix.

Notes

Pour les widgets personnalisés ou tiers, un tableau de bord de projet transmet le contexte de l’équipe par défaut à ces widgets. Si vous avez un widget personnalisé qui s’appuie sur le contexte d’équipe, vous devez mettre à jour la configuration pour vous permettre de sélectionner une équipe.

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

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

Merci,

Jeff Beehler