Facturation basée sur l’attribution d’utilisateurs, niveau d’accès par défaut et facturation quotidienne - Mise à jour sprint 158

  • Article

Dans la mise à jour Sprint 158 d’Azure DevOps, nous avons ajouté la facturation basée sur l’attribution d’utilisateurs. Avec cette fonctionnalité, le nombre de licences Basic ou Basic + Test Plan change à mesure que vous ajoutez ou supprimez des utilisateurs. Cela signifie que vous ne payez que les licences que vous utilisez. Nous avons également ajouté un nouveau paramètre qui vous permet de choisir si vous souhaitez que les nouveaux utilisateurs ajoutés à votre organisation obtiennent un accès de base complet ou un accès limité/gratuit aux parties prenantes.

De plus, nous sommes passés de la facturation mensuelle à la facturation quotidienne. Cela signifie que si vous accordez à un utilisateur un accès payant pendant quelques semaines, voire quelques jours, vous payez uniquement la période où l’accès payant lui a été attribué, et non le mois complet.

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

Azure Test Plans :

Création de rapports :

Wiki :

Général

Facturation basée sur les attributions d’utilisateurs et niveau d’accès par défaut

Facturation basée sur l’attribution d’utilisateurs

Avec cette mise à jour, nous avons ajouté la facturation basée sur l’attribution d’utilisateurs. Au lieu d’avoir à augmenter ou à diminuer le nombre de licences de plan de base ou de base + test payantes que votre organisation a disponibles pour attribuer, maintenant que cela se produit automatiquement lorsque vous ajoutez ou supprimez des utilisateurs, ou modifiez leur niveau d’accès. Cela signifie que vous ne payez jamais plus de licences que vous utilisez, ce qui facilite considérablement l’automatisation de votre attribution de niveau d’accès. Par exemple, vous avez pu configurer des règles de groupe pour contrôler automatiquement le niveau d’accès affecté aux nouveaux utilisateurs qui rejoignent votre équipe. Toutefois, dans le passé, elles ne fonctionnaient que si vous aviez des licences supplémentaires que vous payiez pour ce qui n’était pas encore affecté à quelqu’un et si vous avez expiré, la règle de groupe a échoué. Ce type d’erreurs ne se produit plus tant que l’abonnement Azure que vous utilisez pour la facturation reste actif.

Niveau d’accès par défaut pour les nouveaux utilisateurs

Nous avons également ajouté un nouveau paramètre qui vous permet de choisir si vous souhaitez que les nouveaux utilisateurs ajoutés à votre organisation obtiennent un accès de base complet ou un accès limité/gratuit aux parties prenantes. Dans le passé, les nouveaux utilisateurs ont obtenu basic s’il y avait des licences de base non attribuées disponibles, mais les parties prenantes s’il n’y en avait pas. Toutes les organisations commencent par leur niveau d’accès par défaut défini sur les parties prenantes. Il n’y aura donc pas de frais inattendus pour les nouveaux utilisateurs. Si votre organisation a généralement conservé des licences non attribuées supplémentaires, les nouveaux utilisateurs ajoutés aux projets ont un accès de base complet, veillez à modifier votre niveau d’accès par défaut sur Basic.

Default access level for new users.

Facturation quotidienne

Dans le cadre de la modification de la facturation basée sur les affectations, nous avons également passé de la facturation mensuelle à la facturation quotidienne. Maintenant, si vous donnez à un utilisateur un accès payant pendant quelques semaines ou même quelques jours, vous payez uniquement pour le temps qu’ils ont reçu l’accès payant, plutôt qu’un mois complet. Au fur et à mesure que nous passons de la facturation mensuelle à la facturation quotidienne, votre prochaine facture Azure sera probablement inférieure à celle précédemment. Le mois suivant sera de retour à la normale une fois qu’il a un mois complet de frais quotidiens cumulés.

Nouvelle interface utilisateur pour gérer les autorisations d’organisation et de projet

La gestion des autorisations de l’organisation et du projet a été améliorée. À présent, les nouveaux membres du groupe apparaissent dans la liste, car ils sont ajoutés sans nécessiter d’actualisation de page forcée. Dirigez-vous vers vos organisations Paramètres et jetez un coup d’œil.

Manage organization and project permissions.

Azure Boards

Prise en charge des champs personnalisés dans les colonnes rollup

Le cumul peut maintenant être effectué sur n’importe quel champ, y compris les champs personnalisés. Lors de l’ajout d’une colonne rollup, vous pouvez toujours choisir une colonne rollup dans la liste rapide. Toutefois, si vous souhaitez effectuer un cumul sur des champs numériques qui ne font pas partie du modèle de processus out of the box, vous pouvez configurer vos propres éléments comme suit :

  1. Sur votre backlog, cliquez sur « Options de colonne ». Ensuite, dans le panneau, cliquez sur « Ajouter une colonne rollup » et configurez le cumul personnalisé.

    Rollup on custom fields.

  2. Choisissez entre la barre de progression et le total.
  3. Sélectionnez un type d’élément de travail ou un niveau Backlog (généralement les backlogs agrègent plusieurs types d’éléments de travail).
  4. Sélectionnez le type d’agrégation. Nombre d’éléments de travail ou Somme. Pour Sum, vous devez sélectionner le champ à résumer.
  5. Le bouton OK vous ramènera au volet d’options de colonne dans lequel vous pouvez réorganiser votre nouvelle colonne personnalisée.

Support for custom fields in Rollup columns.

Notez que vous ne pouvez pas modifier votre colonne personnalisée après avoir cliqué sur OK. Si vous avez besoin d’apporter une modification, supprimez la colonne personnalisée et ajoutez-en une autre comme vous le souhaitez.

Nouvelle règle pour masquer les champs d’un formulaire d’élément de travail en fonction d’une condition

Nous avons ajouté une nouvelle règle au moteur de règles hérité pour vous permettre de masquer les champs dans un formulaire d’élément de travail. Cette règle masque les champs en fonction de l’appartenance au groupe d’utilisateurs. Par exemple, si l’utilisateur appartient au groupe « propriétaire du produit », vous pouvez masquer un champ spécifique au développeur. Pour plus d’informations, consultez la documentation ici.

Paramètres de notification d’élément de travail personnalisés

Rester à jour sur les éléments de travail pertinents pour vous ou votre équipe est incroyablement important. Il aide les équipes à collaborer et à suivre les projets et à s’assurer que toutes les parties appropriées sont impliquées. Toutefois, différentes parties prenantes ont différents niveaux d’investissement dans différents efforts, et nous pensons que cela devrait être reflété dans votre capacité à suivre l’état d’un élément de travail.

Auparavant, si vous souhaitiez suivre un élément de travail et recevoir des notifications sur les modifications apportées, vous obtiendriez Notifications par e-mail pour toutes les modifications apportées à l’élément de travail. Après avoir examiné vos commentaires, nous procédons à la suite d’un élément de travail plus flexible pour toutes les parties prenantes. À présent, vous verrez un nouveau bouton de paramètres en regard du bouton Suivre dans le coin supérieur droit de l’élément de travail. Vous accédez ainsi à une fenêtre contextuelle qui vous permettra de configurer vos options de suivi.

Configure follow options.

Dans notification Paramètres, vous pouvez choisir parmi trois options de notification. Tout d’abord, vous pouvez être complètement désinscrit. Ensuite, vous pouvez être entièrement abonné, où vous recevez des notifications pour toutes les modifications d’élément de travail. Enfin, vous pouvez choisir d’être averti pour certains événements de modification des éléments de travail principaux et essentiels. Vous ne pouvez sélectionner qu’une ou les trois options. Cela permet aux membres de l’équipe de suivre les éléments de travail à un niveau supérieur et de ne pas être distrait par chaque modification unique qui est apportée. Avec cette fonctionnalité, nous allons éliminer les e-mails inutiles et vous permettre de vous concentrer sur les tâches cruciales à portée de main.

Choose Notification Settings.

Nous sommes heureux de publier un aperçu du contrôle de déploiement sur le formulaire d’élément de travail. Ce contrôle lie vos éléments de travail à une version et vous permet de suivre facilement l’emplacement où votre élément de travail a été déployé. Pour en savoir plus, consultez la documentation ici.

Link work items to deployments.

Azure Repos

Utiliser l’authentification basée sur le compte de service pour se connecter à AKS

Auparavant, lors de la configuration d’Azure Pipelines à partir du Centre de déploiement AKS, nous avons utilisé une Connecter ion Azure Resource Manager. Cette connexion avait accès à l’ensemble du cluster et pas seulement à l’espace de noms pour lequel le pipeline a été configuré. Avec cette mise à jour, nos pipelines utilisent l’authentification basée sur un compte de service pour se connecter au cluster afin qu’il ait uniquement accès à l’espace de noms associé au pipeline.

Afficher un aperçu des fichiers Markdown dans la demande de tirage côte à côte

Vous pouvez maintenant voir un aperçu de l’apparence d’un fichier Markdown à l’aide du nouveau bouton Aperçu . En outre, vous pouvez voir le contenu complet d’un fichier à partir de la différence côte à côte en sélectionnant le bouton Affichage .

Preview Markdown files in pull request Side-by-side diff.

Expiration de la stratégie de build pour les builds manuels

Les stratégies appliquent les standards de qualité du code et de gestion des modifications de votre équipe. Auparavant, vous pouvez définir des stratégies d’expiration de build pour les builds automatisées. Vous pouvez maintenant définir des stratégies d’expiration de build sur vos builds manuelles.

Build policy expiration for manual builds.

Ajouter une stratégie pour bloquer les validations en fonction de l’e-mail de l’auteur de la validation

Administration istrators peuvent maintenant définir une stratégie Push pour empêcher les validations d’être envoyées à un référentiel pour lequel l’e-mail de l’auteur de validation ne correspond pas au modèle fourni.

Add a policy to block commits based on the commit author email.

Cette fonctionnalité a été hiérarchisée en fonction d’une suggestion de la Communauté des développeurs pour offrir une expérience similaire. Nous continuerons à ouvrir le ticket et à encourager les utilisateurs à nous dire quels autres types de stratégies push vous souhaitez voir.

Azure Pipelines

Réessayer les étapes ayant échoué

Remarque

Pour essayer cette fonctionnalité, vous devez activer les pipelines multi-étapes de fonctionnalité en préversion.

L’une des fonctionnalités les plus demandées dans les pipelines à plusieurs étapes est la possibilité de réessayer une étape ayant échoué sans avoir à commencer à partir du début. Avec cette mise à jour, nous ajoutons une grande partie de cette fonctionnalité.

Vous pouvez maintenant réessayer une étape de pipeline en cas d’échec de l’exécution. Tous les travaux ayant échoué lors de la première tentative et ceux qui dépendent transitivement de ces travaux ayant échoué sont tous re-tentés.

Cela peut vous aider à gagner du temps de plusieurs façons. Par exemple, lorsque vous exécutez plusieurs travaux dans une phase, vous souhaiterez peut-être que chaque étape exécute des tests sur une autre plateforme. Si les tests sur une plateforme échouent alors que d’autres réussissent, vous pouvez gagner du temps en ne réexécutant pas les travaux qui ont réussi. Dans un autre exemple, une phase de déploiement peut avoir échoué en raison d’une connexion réseau flaky. Une nouvelle tentative de cette étape vous aidera à gagner du temps en n’ayant pas à produire une autre build.

Il existe quelques lacunes connues dans cette fonctionnalité. Par exemple, vous ne pouvez pas réessayer une étape que vous annulez explicitement. Nous travaillons à combler ces lacunes dans les prochaines mises à jour.

Amélioration des approbations dans les pipelines YAML

Remarque

Vous devez disposer de pipelines à plusieurs étapes et de nouvelles fonctionnalités d’évaluation de la connexion de service activées pour essayer cette fonctionnalité.

Nous continuons à améliorer les pipelines YAML à plusieurs étapes. Avec cette mise à jour, nous avons activé la configuration des approbations sur les connexions de service et les pools d’agents. Pour les approbations, nous suivons la séparation des rôles entre les propriétaires d’infrastructure et les développeurs. En configurant des approbations sur vos ressources telles que les environnements, les connexions de service et les pools d’agents, vous serez assuré que toutes les exécutions de pipeline qui utilisent des ressources nécessitent d’abord l’approbation.

L’expérience est similaire à la configuration des approbations pour les environnements. Lorsqu’une approbation est en attente sur une ressource référencée à une étape, l’exécution du pipeline attend que le pipeline soit approuvé manuellement.

Enhancements to approvals in YAML pipelines.

Prise en charge des tests de structure de conteneur dans Azure Pipelines

L’utilisation des conteneurs dans les applications augmente et donc la nécessité de tests et de validations robustes. Azure Pipelines prend désormais en charge les tests de structure de conteneur. Cette infrastructure offre un moyen pratique et puissant de vérifier le contenu et la structure de vos conteneurs.

Vous pouvez valider la structure d’une image en fonction de quatre catégories de tests qui peuvent être exécutés ensemble : tests de commande, tests d’existence de fichiers, tests de contenu de fichier et tests de métadonnées. Vous pouvez utiliser les résultats dans le pipeline pour prendre des décisions go/no go. Les données de test sont disponibles dans l’exécution du pipeline avec un message d’erreur pour vous aider à mieux résoudre les échecs.

Entrer les détails du fichier de configuration et de l’image

Container structure testing support in Azure Pipeline.

Données de test et résumé

Test data and summary.

Gestion et résolution des bugs instables

En juillet, nous avons introduit la gestion des tests flaky pour prendre en charge le cycle de vie de bout en bout avec la détection, la création de rapports et la résolution. Pour l’améliorer encore, nous ajoutons la gestion et la résolution des bogues de test flaky.

Lors de l’examen du test flaky, vous pouvez créer un bogue à l’aide de l’action Bogue qui peut ensuite être affectée à un développeur pour approfondir l’examen de la cause racine du test flaky. Le rapport de bogue inclut des informations sur le pipeline, comme le message d’erreur, la trace de pile et d’autres informations associées au test.

Lorsqu’un rapport de bogue est résolu ou fermé, nous démarrons automatiquement le test comme étant défectueux.

Amélioration de l’application Azure Pipelines pour Slack et Microsoft Teams

Pipelines YAML multi-phases

Remarque

Pour essayer cette fonctionnalité, vous devez activer les pipelines multi-étapes de fonctionnalité en préversion.

L’application Azure Pipelines pour Slack et Microsoft Teams prend désormais en charge les pipelines YAML à plusieurs étapes pour CI et CD. Avec cette amélioration, vous recevrez une notification sur différents événements liés aux pipelines YAML.

Enhancements to Azure Pipelines app for Slack and Microsoft Teams.

Événements pris en charge pour les pipelines YAML à plusieurs étapes

  • État d’exécution modifié
  • État de l’étape d’exécution modifié
  • Étape d’exécution en attente d’approbation
  • Approbation de l’étape d’exécution terminée

Events supported for multi-stage YAML pipelines.

Extensions de déploiement et de messagerie d’URL

Nous avons ajouté une extension de messagerie pour l’application Azure Pipelines pour Microsoft Teams. Vous pouvez maintenant rechercher des pipelines et partager des détails pertinents sur le pipeline en tant que carte dans le canal. Le déploiement d’URL vous permet de lancer des discussions autour des pipelines et d’avoir des conversations significatives et contextuelles.

URL unfurling and messaging extensions.

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

Nous avons mis à jour plusieurs images de machine virtuelle hébergées par Azure Pipelines. Voici quelques-uns des points forts de cette mise à jour :

  • Ajout de Go 1.13 à Ubuntu 16.04, Ubuntu 18.04, VS2017 et VS2019. Go 1.12 reste la valeur par défaut.
  • Ajout du SDK Android et des outils de génération 29 à Ubuntu 16.04, Ubuntu 18.04, VS2017 et VS2019.
  • Ajout du module Az 2.6.0 à VS2017 et VS2019.
  • Correction de différents bogues.

Vous trouverez plus d’informations sur les dernières versions ici.

Remarque

Nous allons supprimer Ruby 2.3 de toutes les images dans une prochaine mise à jour depuis qu’elle a atteint la fin de vie le 31 mars 2019.

Tâche du programme d’installation de Open Policy Agent

Open Policy Agent est un moteur de stratégie à usage général code source ouvert qui permet l’application unifiée et prenant en compte les stratégies contextuelles. Nous avons ajouté la tâche d’installation de l’agent Open Policy. Il est particulièrement utile pour l’application de la stratégie dans le pipeline en ce qui concerne l’infrastructure en tant que fournisseurs de code.

Par exemple, Open Policy Agent peut évaluer les fichiers de stratégie Rego et les plans Terraform dans le pipeline.

task: OpenPolicyAgentInstaller@0
    inputs:
          opaVersion: '0.13.5'

Éléments décoratifs de pipeline pour les pipelines de mise en production

Les décorateurs de pipeline permettent d’ajouter des étapes au début et à la fin de chaque travail. Cela diffère de l’ajout d’étapes à une seule définition, car elle s’applique à tous les pipelines d’une organisation.

Nous avons pris en charge les décorateurs pour les builds et les pipelines YAML, avec les clients qui les utilisent pour contrôler de manière centralisée les étapes de leurs travaux. Nous étendons maintenant la prise en charge des pipelines de mise en production. Vous pouvez créer des extensions pour ajouter des étapes ciblant le nouveau point de contribution et elles seront ajoutées à tous les travaux d’agent dans les pipelines de mise en production.

Azure Test Plans

Nouvelle page Test Plans

La plupart des fonctionnalités de planification, de création, d’exécution et de suivi sont désormais disponibles dans la nouvelle page Plans de test. Par conséquent, nous l’activons pour tous les utilisateurs des plans de test afin qu’ils puissent nous fournir des commentaires. Les quelques fonctionnalités restantes nécessitent que nous atteignions la parité avec la page Plans de test précédents sera activée dans les prochains sprints. Si nécessaire, les utilisateurs peuvent désactiver la page Plans de test dans le menu Fonctionnalités d’aperçu. En savoir plus ici.

Reporting

Burndown de sprint inline à l’aide de story points

Votre Sprint Burndown peut maintenant être brûlé par Stories. Cela répond à vos commentaires de la Communauté des développeurs.

Dans le hub Sprint, sélectionnez l’onglet Analytique. Configurez ensuite votre rapport comme suit :

  1. Sélectionner le backlog Des récits
  2. Sélectionner le burndown sur Sum of Story Points

Inline sprint burndown using story points.

Wiki

URL de page Wiki courtes et lisibles

Vous n’avez plus besoin d’utiliser une URL multiligne pour partager des liens de page wiki. Nous tirons parti des ID de page dans l’URL pour supprimer les paramètres, ce qui rend l’URL plus courte et plus facile à lire.

La nouvelle structure d’URL se présente comme suit :

https://dev.azure.com/{accountName}/{projectName}/_wiki/wikis/{wikiName}/{pageId}/{readableWiki PageName}

Voici un exemple de la nouvelle URL d’une page De bienvenue dans Le Wiki Azure DevOps :

https://dev.azure.com/microsoft/ AzureDevOps/_wiki/wikis/AzureDevOps.wiki/1/Welcome-to-Azure-DevOps-Wiki

Cela a été hiérarchisé en fonction de ce ticket de suggestion de fonctionnalité de la Communauté des développeurs.

Prise en charge du diagramme Mermaid dans le wiki

Nous avons ajouté la prise en charge de l’insertion de diagrammes de sirènes dans des pages wiki. Vous pouvez désormais créer, modifier et gérer des graphiques de flux, des diagrammes de séquences dans vos documents de conception et ajouter des graphiques de Gantt dans vos documents de planification dans Azure DevOps Wiki.

Mermaid diagram support in wiki.

Cela a été hiérarchisé en fonction de ce ticket de suggestion de fonctionnalité de la Communauté des développeurs. Pour plus d’informations sur les diagrammes mermaid, 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é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,

Ravi Shanker