Gérer la facturation organization dans Azure DevOps - Sprint 150 Update

Dans la mise à jour Sprint 150 d’Azure DevOps, nous avons ajouté la possibilité de gérer la facturation de vos organization dans notre portail.

Dans le nouvel onglet facturation, vous pouvez choisir l’abonnement Azure que vous utilisez pour la facturation et payer pour d’autres utilisateurs. Vous n’avez plus besoin d’accéder à la Place de marché Visual Studio ou au Portail Azure pour gérer la facturation.

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

Fonctionnalités

Général :

• Disponibilité générale du thème sombre
• Gérer la facturation de vos organization à partir d’Azure DevOps

Azure Boards :

• Travail de requête basé sur des groupes Azure Active Directory
• Partager le tableau de votre équipe à l’aide d’un badge
• Requête pour le travail relatif au début de la journée, de la semaine, du mois ou de l’année
• Exporter les résultats de la requête dans un fichier CSV

Azure Repos :

• Nouveaux types de fusion pour effectuer des demandes de tirage

Azure Pipelines :

• Tâche de manifeste Kubernetes
• Mises à niveau vers la tâche Docker
• Programme d'installation de l'outil Kubectl
• Azure Container Registry dans la connexion au service du Registre Docker
• Prise en charge de cgroup sur un pool Ubuntu hébergé
• Exécuter une seule fois l’agent
• Prise en charge de Visual Studio 2019 (VS2019) dans la tâche de test Visual Studio
• Mise à jour de l’interface utilisateur du pool d’agents
• Assistant de tâches pour modifier des fichiers YAML
• Mises à jour d’images de pipelines hébergés
• Améliorations apportées à l’intégration de ServiceNow
• Prise en charge de Azure PowerShell module Az
• Améliorations apportées à l’autorisation des ressources
• Stratégies de rétention simplifiées pour les pipelines de build
• Artefacts de pipeline extraits automatiquement en version
• Mises à jour du rapport de couverture du code Cobertura

Création de rapports :

• Générer des rapports d’échec et de durée
• Disponibilité générale d’Analytics

Wiki :

• Notifications sur les pages wiki

Administration :

• Gérer la facturation de vos organization à partir d’Azure DevOps

Général

Disponibilité générale du thème sombre

En octobre dernier, nous avons publié la préversion publique du thème sombre dans le cadre de la nouvelle navigation. Après plusieurs mois en préversion, à l’écoute des commentaires et au réglage de l’expérience, nous sommes ravis d’annoncer la disponibilité générale du thème sombre.

Gérer la facturation de vos organization à partir d’Azure DevOps

Nous sommes heureux d’annoncer que vous pouvez désormais gérer la facturation de votre organization à partir du portail Azure DevOps. Les administrateurs n’ont plus besoin de configurer la facturation via le Portail Azure. Pour gérer les paramètres de facturation, accédez à paramètres de votre organisation et sélectionnez Facturation.

Vous trouverez ci-dessous la liste des paramètres que vous pouvez gérer à partir de l’onglet Facturation .

1. Vous pouvez choisir un abonnement Azure à utiliser pour la facturation.

   

2. Vous pouvez modifier l’abonnement Azure que votre organization utilise pour la facturation en sélectionnant un autre abonnement. Auparavant, vous deviez supprimer la facturation, puis racheter soigneusement le même niveau pour chacune de vos ressources payantes (utilisateurs de base, utilisateurs de gestion des packages, pipelines hébergés MS, etc.). Ce processus était fastidieux et sujet à l’erreur. Vous pouvez maintenant modifier l’abonnement Azure que votre organization utilise pour la facturation en sélectionnant un autre abonnement et en cliquant sur Enregistrer.

   

3. Il n’est plus nécessaire d’accéder à la Place de marché Visual Studio pour gérer la configuration de la facturation. Nous avons ajouté la possibilité de payer d’autres utilisateurs de base, de Test Manager et de gestion des packages (Azure Artifacts). Vous pouvez augmenter ou diminuer le nombre d’utilisateurs que votre organization paie à partir du nouvel onglet Facturation.

   

Azure Boards

Travail de requête basé sur des groupes Azure Active Directory

Avec l’adoption accrue d’Azure Active Directory et la prévalence de l’utilisation de groupes pour gérer la sécurité, les équipes cherchent de plus en plus des moyens de tirer parti de ces groupes dans Azure Boards. Désormais, en plus d’interroger des éléments de travail qui ont été affectés ou modifiés par des personnes spécifiques à l’aide des opérateurs Dans le groupe ou Non dans le groupe , vous pouvez également utiliser des groupes Azure Active Directory directement.

Pour plus d’informations, consultez la documentation relative aux opérateurs de requête .

Partager le tableau de votre équipe à l’aide d’un badge

Le FICHIER README du dépôt est souvent la maison vers laquelle votre équipe de projet se tourne pour obtenir des informations sur la façon de contribuer et d’utiliser votre solution. À présent, comme vous le pouvez avec une status de build ou de déploiement dans Azure Pipelines, vous pouvez ajouter à votre fichier README un badge pour le tableau de votre équipe dans Azure Boards. Vous pouvez configurer le badge pour afficher uniquement les colonnes en cours ou toutes les colonnes, et même rendre le badge visible publiquement si votre projet est open source.

Si votre FICHIER README est basé sur Markdown, vous pouvez simplement copier l’exemple Markdown à partir de la page des paramètres du badge status et le coller dans votre fichier.

Requête pour le travail relatif au début de la journée, de la semaine, du mois ou de l’année

Bien que les équipes se concentrent souvent sur le travail dans le contexte de ce qui sera à venir ou sur la base d’itérations de sprint, il est souvent intéressant de regarder le travail en arrière à travers le prisme du calendrier pour signaler tout le travail qui s’est produit le mois dernier ou au cours du premier trimestre de l’année. Vous pouvez maintenant utiliser le nouvel ensemble de macros @StartOf suivants, ainsi que n’importe quel champ basé sur la date, pour effectuer une requête en fonction du début du jour, de la semaine, du mois ou de l’année :

• @StartOfYear
• @StartOfMonth
• @StartOfWeek
• @StartOfDay

Chacune de ces macros accepte également une nouvelle chaîne de modificateur qui vous permet de déplacer les données par différentes unités de date. Par exemple, vous pouvez écrire une requête pour rechercher tous les éléments de travail terminés au cours du premier trimestre de cette année en interrogeant sur Date >de changement d’état = @StartOfYear et Date <de changement d’état = @StartOfYear(“+3M”). Pour plus d’informations, consultez la documentation sur les macros de requête .

Exporter les résultats de la requête dans un fichier CSV

Vous pouvez maintenant exporter les résultats de la requête directement dans un fichier de format CSV à partir du web.

Azure Repos

Nouveaux types de fusion pour effectuer des demandes de tirage

Vous disposez maintenant d’autres options lors de la fusion des modifications d’une demande de tirage vers la branche cible. Nous avons ajouté la prise en charge de deux de nos fonctionnalités les plus demandées sur le Developer Community : fusion rapide et fusion semi-linéaire (également appelée « Rebase et fusion »).

Vous voyez maintenant ces nouvelles options disponibles dans la boîte de dialogue Demande de tirage complète :

La page d’administration de stratégie mise à jour permet aux administrateurs de contrôler les stratégies de fusion autorisées sur une branche ou un dossier de branches.

Notes

Les stratégies existantes sont toujours appliquées. Par exemple, si votre branche a actuellement une stratégie « squashing fusion uniquement » en place, vous devrez modifier cette stratégie afin d’utiliser les nouvelles stratégies de fusion.

Il existe quelques situations dans lesquelles le rebasage pendant l’achèvement de la demande de tirage n’est pas possible :

• Si une stratégie sur la branche cible interdit l’utilisation de stratégies de rebase, vous aurez besoin de l’autorisation « Remplacer les stratégies de branche ».
• Si la branche source de la demande de tirage comporte des stratégies, vous ne pourrez pas la rebaser. Le rebasing modifie la branche source sans passer par le processus d’approbation de stratégie.
• Si vous avez utilisé l’extension de conflit de fusion pour résoudre les conflits de fusion. Les résolutions de conflit appliquées à une fusion à trois sont rarement réussies (voire valides) lors de la rebasing de tous les commits dans une demande de tirage un par un.

Dans tous ces cas, vous avez toujours la possibilité de rebaser votre branche localement et d’effectuer un envoi push vers le serveur, ou d’squashing-fusion de vos modifications lors de la fin de la demande de tirage.

Azure Pipelines

Tâche de manifeste Kubernetes

Nous avons ajouté une nouvelle tâche à nos pipelines de mise en production pour simplifier le processus de déploiement sur des clusters Kubernetes à l’aide de fichiers manifestes. Cette tâche offre les avantages suivants par rapport à l’utilisation du binaire kubectl dans les scripts :

• Substitution d’artefact : l’action de déploiement prend comme entrée une liste d’images conteneur qui peuvent être spécifiées avec leurs balises ou synthèses. Cela est remplacé dans la version autre que le modèle des fichiers manifestes avant de l’appliquer au cluster pour garantir que la version appropriée de l’image est extraite par les nœuds du cluster.

• Stabilité du manifeste : le déploiement status est vérifié pour les objets Kubernetes déployés pour incorporer des vérifications de stabilité lors du calcul de la tâche status comme réussite/échec.

• Annotations de traçabilité : les annotations sont ajoutées aux objets Kubernetes déployés pour superposer les informations de traçabilité sur l’origine des organization, du projet, du pipeline et de l’exécution.

• Bake manifest : l’action bake de la tâche permet de créer des graphiques Helm dans des fichiers manifeste Kubernetes afin qu’ils puissent être appliqués au cluster.

• Stratégie de déploiement : le choix d’une stratégie canary avec action de déploiement entraîne la création du pourcentage souhaité de charges de travail avec suffixes -baseline et -canary afin qu’elles puissent être comparées au cours d’une tâche avant d’utiliser ManualIntervention l’action de promotion/rejet de la tâche pour finaliser la version à conserver.

steps:
- task: KubernetesManifest@0
  name: bake
  displayName: Bake K8s manifests from Helm chart
  inputs:
    action: bake
    helmChart: charts/sample
    overrides: 'image.repository:nginx'

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

Mises à niveau vers la tâche Docker

Nous avons mis à niveau la tâche Docker pour simplifier l’expérience de création de pipeline. La commande buildAndPush peut désormais être utilisée pour générer plusieurs balises pour un référentiel de conteneurs spécifique et l’envoyer à plusieurs registres de conteneurs en une seule étape. La tâche peut utiliser des connexions de service de registre Docker pour la connexion aux registres de conteneurs. Les métadonnées de traçabilité relatives au dépôt source, à la validation et à la provenance de build sont ajoutées en tant qu’étiquettes aux images générées à l’aide de cette tâche.

steps:
- task: Docker@2
  displayName: Container registry login - ACR1 service connection
  inputs:
    command: login
    containerRegistry: acr1
- task: Docker@2
  displayName: Container registry login - ACR2 service connection
  inputs:
    command: login
    containerRegistry: acr2
- task: Docker@2
  displayName: Build and push images
  inputs:
    repository: test
    tags: |
      d1
      d2

Programme d'installation de l'outil Kubectl

Nous avons ajouté une nouvelle tâche qui vous permet d’installer une version spécifique du binaire Kubectl sur les agents. Les chaînes de version les plus récentes et semver telles que « v1.14.0 » sont acceptées en tant que valeurs valides pour l’entrée Kubectl Version Spec.

Azure Container Registry dans la connexion au service Docker Registry

Vous pouvez maintenant créer une connexion de service de registre Docker à partir de la page des paramètres de votre projet. Pour créer la connexion, choisissez un registre de conteneurs Azure dans l’un des abonnements associés à votre identité Azure Active Directory (Azure AD). Toutes les tâches nécessitant des connexions de service à des registres de conteneurs, telles que Docker@2 et KubernetesManifest@0 , prennent en charge une méthode unique de spécification d’une connexion.

Prise en charge de cgroup sur un pool Ubuntu hébergé

Sur Linux, lorsque l’utilisation de la mémoire devient trop élevée, le noyau met fin à certains processus pour protéger le reste. Si le processus de l’agent Azure Pipelines est sélectionné pour l’arrêt, votre exécution de pipeline échoue avec un message d’erreur indiquant la perte de communication avec l’agent. Sur le pool Ubuntu hébergé par Microsoft, nous avons réduit les risques que l’agent soit arrêté en exécutant des étapes à l’intérieur d’un cgroup personnalisé. Bien que votre pipeline puisse toujours échouer si vous dépassez la mémoire disponible, le processus de l’agent est plus susceptible de survivre et de signaler l’échec correctement. Si vous exécutez un agent Linux privé, nous avons publié les paramètres que nous utilisons afin que vous puissiez envisager une configuration similaire.

Exécuter une seule fois l’agent

Si vous utilisez une infrastructure telle que Azure Container Instances pour exécuter des agents privés élastiques, vous souhaitez souvent que chaque agent n’accepte qu’un seul travail avant de partir. Jusqu’à présent, cela n’était pas facile, car vous deviez mettre fin à l’agent (entraînant peut-être un échec à signaler) ou accepter le risque qu’un agent reçoive un autre travail avant de pouvoir l’arrêter. Avec cette mise à jour, nous avons ajouté l’indicateur --once à la configuration de l’agent. Lorsque vous configurez l’agent de cette façon, il n’accepte qu’un seul travail, puis s’arrête.

Prise en charge de Visual Studio 2019 (VS2019) dans la tâche de test Visual Studio

Nous avons ajouté la prise en charge de VS2019 à la tâche de test Visual Studio dans les pipelines. Pour exécuter des tests à l’aide de la plateforme de test pour VS2019, sélectionnez les options Dernière ou Visual Studio 2019 dans la liste déroulante Version de la plateforme de test.

Mise à jour de l’interface utilisateur du pool d’agents

La page de gestion des pools d’agents dans les paramètres du projet a été mise à jour avec une nouvelle interface utilisateur. Vous pouvez maintenant facilement voir tous les travaux qui s’exécutent dans un pool. En outre, vous pouvez découvrir pourquoi un travail n’est pas en cours d’exécution.

Assistant de tâches pour modifier des fichiers YAML

Nous continuons de recevoir de nombreux commentaires pour faciliter la modification des fichiers YAML pour les pipelines. Dans les mises à jour précédentes, nous avons ajouté la prise en charge d’intellisense. Nous ajoutons maintenant une assistant de tâche à l’éditeur YAML. Avec cela, vous aurez la même expérience familière pour l’ajout d’une nouvelle tâche à un fichier YAML que dans l’éditeur classique. Cette nouvelle assistant prend en charge la plupart des types d’entrée de tâches courants, tels que les listes de choix et les connexions de service. Pour utiliser la nouvelle assistant de tâche, sélectionnez Modifier sur un pipeline YAML, puis sélectionnez le assistant tâche.

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

Nous sommes heureux d’annoncer les mises à jour du pool macOS hébergé vers OS X Mojave (10.4), qui incluront également la prise en charge de Xcode 10.2. Si vos pipelines basés sur un concepteur utilisent le pool macOS hébergé , vos pipelines seront automatiquement mis à niveau vers Mojave. Si vous souhaitez rester sur OS X High Sierra (10.3), remplacez le pool sur lequel vos builds s’exécutent par hébergé macOS High Sierra.

Si vous utilisez YAML, les nouvelles étiquettes vmImage que vous pouvez utiliser sont les suivantes :

• Étiquette d’image qui pointe toujours vers la dernière version de macOS, actuellement 10.4

vmImage: 'macOS-latest'

• Cette étiquette d’image cible spécifiquement mac OS 10.4 si vous souhaitez être sûr que votre pipeline s’exécute sur Mojave

vmImage: 'macOS-10.4'

• Étiquette d’image qui ciblera spécifiquement mac OS 10.3 si vous souhaitez être sûr que votre pipeline s’exécute sur High Sierra

vmImage: 'macOS-10.3'

Nous avons également apporté des mises à jour à l’image Windows Server 2019 pour vos pipelines Azure hébergés. Vous trouverez les dernières versions ici. Cette mise à jour inclut les nouvelles versions de VS2019 Preview, Docker, PowerShell Core, Node.js, npm et d’autres.

Pour plus d’informations sur ce qui est contenu dans nos images de machine virtuelle macOS hébergées et pour en savoir plus sur les outils disponibles sur nos images, consultez notre référentiel Génération d’images sur GitHub.

Améliorations apportées à l’intégration de ServiceNow

En décembre dernier, nous avons publié l’intégration de ServiceNow Change Management avec les pipelines de mise en production. Une fonctionnalité clé pour la collaboration inter-équipes qui a permis à chaque équipe d’utiliser le service de son choix et d’avoir une livraison efficace de bout en bout. Avec cette mise à jour, nous avons amélioré l’intégration pour prendre en charge tous les types de modifications (normales, standard et d’urgence). En outre, vous pouvez maintenant spécifier la porte utilisée pour créer une demande de modification à l’aide d’un modèle existant, conformément au processus ITSM suivi dans votre organization. Enfin, vous pouvez également contrôler les mises en production en fonction des demandes de modification existantes. Cela vous permet d’adopter CD, sans avoir à modifier le processus recommandé par vos équipes informatiques.

Prise en charge de Azure PowerShell module Az

Azure PowerShell fournit un ensemble d’applets de commande que vous pouvez utiliser pour gérer les ressources Azure à partir de la ligne de commande. En décembre dernier, le module Az Azure PowerShell est devenu disponible et est désormais le module prévu pour la gestion de vos ressources Azure.

Auparavant, nous ne prenions pas en charge le module Azure PowerShell Az dans nos agents hébergés. Avec la nouvelle Azure PowerShell tâche version 4.* dans les pipelines de build et de mise en production, nous avons ajouté la prise en charge du nouveau module Az pour toutes les plateformes. Azure PowerShell tâche version 3.* continue de prendre en charge le module AzureRM. Toutefois, pour suivre les derniers services et fonctionnalités Azure, nous vous recommandons de basculer vers la Azure PowerShell tâche version 4.* dès que possible.

Le module Az dispose d’un mode de compatibilité pour vous aider à utiliser des scripts existants pendant que vous les mettez à jour pour utiliser la nouvelle syntaxe. Pour activer la compatibilité pour le module Az, utilisez la Enable-AzureRmAlias commande . Les alias vous permettent d’utiliser les anciens noms d’applet de commande avec le module Az. Vous pouvez obtenir plus d’informations sur la migration du module Azure RM vers le module Az Azure PowerShell ici.

Notes

Vous devez installer le module Az sur votre ordinateur d’agent si vous utilisez des agents privés.

Pour plus d’informations sur le module Az Azure PowerShell, consultez la documentation ici.

Améliorations apportées à l’autorisation des ressources

Nous devions assurer la sécurité des ressources protégées (par exemple, les connexions de service, les groupes de variables, les pools d’agents, les fichiers sécurisés) lorsqu’elles sont référencées dans un fichier YAML. En même temps, nous voulions faciliter la configuration et l’utilisation de pipelines qui utilisent ces types de ressources pour les scénarios de non-production. Auparavant, nous avons ajouté un paramètre pour marquer une ressource comme « autorisée à être utilisée dans tous les pipelines ».

Avec cette mise à jour, nous vous permet de résoudre plus facilement un problème d’autorisation de ressource même si vous n’avez pas marqué une ressource en tant que telle. Dans la nouvelle expérience, lorsqu’une build échoue en raison d’une erreur d’autorisation de ressource, vous voyez une option permettant d’autoriser explicitement l’utilisation de ces ressources dans le pipeline, puis de continuer. Les membres de l’équipe disposant d’autorisations pour autoriser les ressources pourront effectuer cette action directement à partir d’une build ayant échoué.

Stratégies de rétention simplifiées pour les pipelines de build

Nous avons simplifié le modèle de rétention pour tous les pipelines de build, y compris les builds YAML. Il existe un nouveau paramètre au niveau du projet qui vous permet de contrôler combien de jours vous souhaitez conserver les builds de chaque pipeline et combien de jours vous souhaitez conserver les artefacts de chaque build. Si vous avez utilisé l’éditeur classique pour créer votre pipeline de build, les anciens paramètres de rétention continueront d’être respectés, mais les pipelines plus récents utiliseront les nouveaux paramètres. Vous pouvez gérer la rétention dans la page des paramètres des pipelines des paramètres du projet.

Artefacts de pipeline extraits automatiquement en version

Auparavant, si le pipeline de build lié à une version avait publié des artefacts à l’aide de la tâche Publier l’artefact de pipeline , les artefacts n’étaient pas automatiquement extraits en version. Au lieu de cela, vous deviez ajouter explicitement une tâche Télécharger l’artefact de pipeline dans le pipeline de mise en production pour télécharger les artefacts.

Désormais, tous les artefacts de pipeline publiés par le pipeline de build sont automatiquement téléchargés et mis à votre disposition dans la version. Vous pouvez également personnaliser le téléchargement de votre artefact de pipeline à partir des propriétés de phase du pipeline de mise en production.

Mises à jour du rapport de couverture du code Cobertura

Auparavant, lorsque vous exécutiez des tests dans le pipeline et que vous publiiez les résultats de la couverture du code sur Azure DevOps, il était nécessaire de spécifier à la fois le résumé XML et un fichier de rapport HTML. En outre, les styles des rapports HTML ont été supprimés avant d’être rendus dans l’onglet Couverture du code. Cette suppression du style était nécessaire du point de vue de la sécurité, car des fichiers HTML arbitraires pouvaient être chargés.

Avec cette mise à jour, nous avons résolu ces limitations pour les rapports de couverture Cobertura. Lors de la publication de rapports de couverture du code, vous n’avez plus besoin de spécifier des fichiers HTML. Les rapports sont générés automatiquement et sont rendus avec un style approprié dans l’onglet Couverture du code. Cette fonctionnalité utilise l’outil de open source ReportGenerator.

Rapports

Générer des rapports d’échec et de durée

Il est important d’avoir des métriques et des insights pour améliorer en permanence le débit et la stabilité de votre pipeline. Comme première étape vers l’analytique de pipeline, nous avons ajouté deux rapports pour vous fournir des métriques et des insights sur vos pipelines.

1. Le rapport d’échec affiche le taux de réussite de build et la tendance des échecs. En outre, il affiche également la tendance des échecs des tâches pour fournir des informations sur la tâche qui contribue au nombre maximal d’échecs.

   

2. Le rapport de durée aura la durée du pipeline avec sa tendance.

   

Disponibilité générale d’Analytics

Nous sommes heureux d’annoncer que les fonctionnalités d’analyse suivantes seront incluses dans Azure DevOps sans frais supplémentaires.

1. Les widgets Analytics sont des modules configurables qui affichent des données sur un tableau de bord et vous aident à surveiller la progression de votre travail. Les widgets inclus sont les suivants :

   • Les graphiques Burndown et Burnup surveillent la progression d’un ensemble de travaux délimités sur une période donnée.

     

   • Temps de cycle et délai pour visualiser la façon dont le travail passe dans le cycle de développement de votre équipe

     

   • Le diagramme de flux cumulé (CFD) suit les éléments de travail à mesure qu’ils progressent dans différents états.

     

   • Suivi de la façon dont une équipe fournit de la valeur sur plusieurs sprints.

     

   • Tendance des résultats des tests pour surveiller les tendances des tests, détecter les modèles d’échec et de durée des tests sur un ou plusieurs pipelines.

     

2. Dans le produit, nous incluons le rapport de test le plus échec pour obtenir des informations sur les tests les plus défaillants dans votre pipeline afin d’améliorer la fiabilité du pipeline et de réduire la dette de test.

   

Nous continuerons également à offrir l’intégration de Power BI via des vues analytiques et un accès direct à notre point de terminaison OData en préversion pour tous les clients Azure DevOps Services.

Si vous utilisez l’extension De la Place de marché Analytics, vous pouvez continuer à utiliser Analytics comme vous l’avez fait auparavant et n’avez pas besoin de suivre d’étapes supplémentaires. Cela signifie que nous allons déprécier l’extension de la Place de marché Analytics pour les clients hébergés.

L’offre Azure DevOps Analytics est l’avenir de la création de rapports et nous continuerons à investir dans de nouvelles fonctionnalités pilotées par Analytics. Vous trouverez plus d’informations sur Analytics dans les liens ci-dessous.

• Documentation de vue d’ensemble d’Analytics

• Widgets d’analytique

• Rapport de test ayant échoué le plus

• Intégration de Power BI

• Point de terminaison OData

• Azure DevOps Analytics

Wiki

Notifications sur les pages wiki

Jusqu’à présent, vous ne disposiez pas d’un moyen de savoir quand le contenu d’une page wiki a été modifié. Vous pouvez maintenant suivre les pages wiki pour recevoir une notification par e-mail lorsque la page est modifiée, supprimée ou renommée. Pour suivre les modifications apportées à un wiki, sélectionnez le bouton Suivre dans la page wiki.

Cette fonctionnalité a été hiérarchisée en fonction de ce ticket de suggestion. Pour en savoir plus, consultez notre documentation ici.

Administration

Gérer la facturation de vos organization à partir d’Azure DevOps

Nous sommes heureux d’annoncer que vous pouvez désormais gérer la facturation de votre organization à partir du portail Azure DevOps. Les administrateurs n’ont plus besoin de configurer la facturation via le Portail Azure. Pour gérer les paramètres de facturation, accédez à paramètres de votre organisation et sélectionnez Facturation.

Vous trouverez ci-dessous la liste des paramètres que vous pouvez gérer à partir de l’onglet Facturation .

1. Vous pouvez choisir un abonnement Azure à utiliser pour la facturation.

   

2. Vous pouvez modifier l’abonnement Azure que votre organization utilise pour la facturation en sélectionnant un autre abonnement. Auparavant, vous deviez supprimer la facturation, puis racheter soigneusement le même niveau pour chacune de vos ressources payantes (utilisateurs de base, utilisateurs de gestion des packages, pipelines hébergés MS, etc.). Ce processus était fastidieux et sujet à l’erreur. Vous pouvez maintenant modifier l’abonnement Azure que votre organization utilise pour la facturation en sélectionnant un autre abonnement et en cliquant sur Enregistrer.

   

3. Il n’est plus nécessaire d’accéder à la Place de marché Visual Studio pour gérer la configuration de la facturation. Nous avons ajouté la possibilité de payer d’autres utilisateurs de base, de Test Manager et de gestion des packages (Azure Artifacts). Vous pouvez augmenter ou diminuer le nombre d’utilisateurs que votre organization paie à partir du nouvel onglet Facturation.

   

É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 de commentaires 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,

Jeremy Epling