Gérer la facturation de l’organisation 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 pour votre organisation au sein de 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 à Visual Studio Marketplace 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éralités:

• Disponibilité générale du thème sombre
• Gérer la facturation pour votre organisation à 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 concernant le travail lié 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 vers un fichier CSV

Azure Repos :

• Nouveaux types de fusion pour compléter les requêtes de tirage

Azure Pipelines :

• Tâche de manifeste Kubernetes
• Mises à niveau de la tâche Docker
• programme d’installation de l’outil Kubectl
• Azure Container Registry dans la connexion du service Docker Registry
• Prise en charge de cgroup sur un pool Ubuntu hébergé
• Agent à exécution unique
• 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âche pour modification des fichiers YAML
• Mises à jour de l’image de pipelines hébergés
• Améliorations apportées à l’intégration de ServiceNow
• Prise en charge du module Azure PowerShell Az
• Améliorations apportées à l’autorisation des ressources
• Stratégies de rétention simplifiées pour les pipelines de build
• Artefacts de pipeline récupérés automatiquement dans la mise en production
• Mises à jour du rapport de couverture du code Cobertura

Rapports:

• Rapports d’échec et de durée ds builds
• Disponibilité générale d’Analytics

Wiki :

• notifications sur les pages wiki

Administration:

• Gérer la facturation pour votre organisation à partir d’Azure DevOps

Généralités

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 version préliminaire, d’écoute des commentaires et d'ajustement de l’expérience, nous sommes heureux d’annoncer la disponibilité générale du thème sombre.

Gérer la facturation de votre organisation à partir d’Azure DevOps

Nous sommes heureux d’annoncer que vous pouvez désormais gérer la facturation de votre organisation à 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 à vos paramètres d’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 organisation 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 sujette à une erreur. Vous pouvez maintenant modifier l’abonnement Azure que votre organisation 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 à Visual Studio Marketplace pour gérer la configuration de la facturation. Nous avons ajouté la possibilité de payer des utilisateurs supplémentaires de base, de Gestionnaire de tests et de gestion des packages (Azure Artifacts). Vous pouvez augmenter ou diminuer le nombre d’utilisateurs que votre organisation paie à partir du nouvel onglet Facturation .

   

Azure Boards

Interrogation d’éléments basée 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 ont de plus en plus cherché des moyens de tirer parti de ces groupes dans Azure Boards. Maintenant, 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 De groupe ou Non dans le groupe , vous pouvez également utiliser directement des groupes Azure Active Directory.

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

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

Le README du référentiel est souvent la source vers laquelle votre équipe de projet se tourne pour obtenir des informations sur la manière de contribuer à votre solution et de l'utiliser. À présent, comme vous pouvez le faire avec un état de génération ou de déploiement dans Azure Pipelines, vous pouvez ajouter un badge à votre fichier README pour le tableau de votre équipe dans Azure Boards. Vous pouvez configurer le badge pour afficher uniquement les en cours colonnes 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 d’état et le coller dans votre fichier.

Rechercher du travail lié au début du jour, 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 va arriver ou en fonction des itérations de sprint, il est souvent intéressant d'examiner le travail sous l’angle du calendrier pour rendre compte de tout le travail effectué le mois dernier ou au premier trimestre de l’année. Vous pouvez maintenant utiliser le nouvel ensemble suivant de macros @StartOf ainsi que n’importe quel champ basé sur des dates pour interroger 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 unités de date différentes. Par exemple, vous pouvez écrire une requête pour rechercher tous les éléments de travail terminés au premier trimestre de cette année en interrogeant la date >de modification de l’état = @StartOfYear et la date <de modification d’état = @StartOfYear(“+3M”). Pour plus d’informations, consultez la documentation des macros de requête .

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

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

Azure Repos

Nouveaux types de fusion pour compléter les pull requests

Vous avez maintenant plus d’options lors de la fusion des modifications d’un pull request dans la branche cible. Nous avons ajouté la prise en charge de deux de nos fonctionnalités les plus demandées sur la Communauté des développeurs : Fast-Forward fusion et fusionSemi-Linear (également appelée « Rebase and Merge »).

Vous verrez maintenant ces nouvelles options disponibles dans la boîte de dialogue Terminer la pull request :

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.

Il y a quelques situations où 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 des stratégies de rebase, vous aurez besoin de la permission « Remplacer les stratégies de la branche ».
• Si la branche source du pull request a des stratégies, vous ne pourrez pas la rebaser. Le rebasage permet de modifier la branche source sans passer par le processus d'approbation de la stratégie.
• Si vous avez utilisé l'extension de conflit de fusion pour résoudre les conflits de fusion. Les résolutions de conflits appliquées à une fusion à trois sont rarement couronnées de succès (ou même valides) lorsque l'on rebase tous les commits d'une demande de tirage un par un.

Dans tous ces cas, vous avez toujours la possibilité de rebaser votre branche localement et de la pousser sur le serveur, ou de fusionner vos changements au moment de compléter la requête.

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 fichier binaire kubectl dans les scripts :

• Substitution d'artefacts - L'action de déploiement prend en entrée une liste d'images de conteneurs qui peuvent être spécifiées avec leurs balises ou digests. Cela est remplacé dans la version non-modèle des fichiers manifestes avant de l’appliquer au cluster pour vous assurer que la version appropriée de l’image est extraite par les nœuds du cluster.

• Stabilité du manifeste - L'état du déroulement du déploiement est vérifié pour que les objets Kubernetes déployés intègrent des contrôles de stabilité lors de la détermination de l'état de la tâche en tant que réussite/échec.

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

• Bake manifest - L'action bake de la tâche permet de baking les cartes Helm dans les fichiers manifestes Kubernetes afin qu'ils puissent être appliqués au cluster.

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

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 à jour de 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 les connexions de service de Registre Docker pour la connexion aux registres de conteneurs. Les métadonnées de traçabilité concernant le référentiel source, le commit et la provenance de la construction sont ajoutées en tant qu'étiquettes aux images construites à 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 caractères de la version la plus récente et semver, telles que « v1.14.0 », sont acceptées comme valeurs valides pour l'entrée Kubectl Version Spec.

Registre de conteneurs Azure dans la connexion au service de registre Docker

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 tels que Docker@2 et KubernetesManifest@0 prennent en charge une seule façon de spécifier une connexion.

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

Sur Linux, lorsque l’utilisation de la mémoire est 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 du pipeline échouera avec un message d’erreur indiquant une perte de communication avec l’agent. Sur le pool Ubuntu hébergé par Microsoft, nous avons réduit les chances que l’agent soit arrêté en exécutant des étapes à l’intérieur d’un groupe cgroup personnalisé. Bien que votre pipeline puisse toujours échouer si vous dépassez la mémoire disponible, le processus de l'agent a plus de chances de survivre et de signaler correctement l'échec. Si vous exécutez un agent Linux privé, nous avons publié les paramètres que nous utilisons afin de pouvoir envisager une configuration similaire.

Agent à exécution unique

Si vous utilisez une infrastructure telle qu’Azure Container Instances pour exécuter des agents privés élastiques, vous souhaitez souvent que chaque agent accepte un seul travail avant de partir. Jusqu’à présent, cela n’était pas facile, car vous deviez mettre fin à l’agent (peut-être à l’origine d’un échec) ou accepter le risque qu’un agent puisse recevoir un autre travail avant de pouvoir l’arrêter. Avec cette mise à jour, nous avons ajouté le --once flag à 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 lui-même.

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 Visual Studio Test dans les pipelines. Pour exécuter des tests à l’aide de la plateforme de test pour VS2019, sélectionnez les options les plus récentes ou Visual Studio 2019 dans la liste déroulante des versions 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 voir facilement tous les travaux en cours d’exécution dans un pool. En outre, vous pouvez apprendre pourquoi un travail n’est pas en cours d’exécution.

Assistant de tâches pour éditer les fichiers YAML

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

Mises à jour de l’image 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 conçus par le concepteur utilisent le pool macOS hébergé, vos pipelines seront automatiquement mis à jour vers Mojave. Si vous souhaitez rester sur OS X High Sierra (10.3), modifiez le pool sur lequel vos builds s’exécutent sur Hosted 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 voulez garantir que votre pipeline s'exécute correctement sur macOS Mojave.

vmImage: 'macOS-10.4'

• Étiquette d’image qui cible 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. Les dernières versions sont disponibles ici. Cette mise à jour inclut de nouvelles versions de vs2019 Preview, Docker, PowerShell Core, Node.js, npm et autres.

Pour plus d’informations sur les éléments contenus dans nos images de machines virtuelles macOS hébergées et en savoir plus sur les outils disponibles sur nos images, visitez 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 entre équipes qui a permis à chaque équipe d’utiliser un 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 (normal, 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 organisation. Enfin, vous pouvez également restreindre les mises en production en fonction des demandes de modification existantes. Cela vous permet d’adopter le CD, sans avoir à modifier le processus recommandé par vos équipes informatiques.

Prise en charge du module Azure PowerShell 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 Azure PowerShell Az est devenu disponible et est maintenant le module destiné à la gestion de vos ressources Azure.

Auparavant, nous n’avons pas pris en charge le module Azure PowerShell Az dans nos agents hébergés. Avec la nouvelle tâche Azure PowerShell 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. La tâche Azure PowerShell version 3.* continuera de prendre en charge le module AzureRM. Toutefois, pour suivre les derniers services et fonctionnalités Azure, nous vous recommandons de passer à la tâche Azure PowerShell version 4.* dès que possible.

Le module Az a 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 commande Enable-AzureRmAlias. 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 Azure PowerShell Az ici.

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

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

Nous avions besoin de fournir une sécurité pour les 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 hors 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 rendons plus facile pour résoudre un problème d’autorisation de ressource même si vous n’avez pas marqué une ressource comme telle. Dans la nouvelle expérience, lorsqu’une build échoue en raison d’une erreur d’autorisation de ressource, vous verrez une option permettant d’autoriser explicitement l’utilisation de ces ressources dans le pipeline, puis de continuer. Les membres de l’équipe disposant des autorisations nécessaires 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 construction

Nous avons simplifié le modèle de rétention pour tous les pipelines de construction, y compris les constructions YAML. Il existe un nouveau paramètre au niveau du projet qui vous permet de contrôler le nombre de jours pendant lesquels vous souhaitez conserver les builds de chaque pipeline et le nombre de jours pendant lesquels 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 utilisent les nouveaux paramètres. Vous pouvez gérer la rétention sous la page paramètres des pipelines des paramètres du projet.

Artefacts de pipeline récupérés automatiquement dans la mise en production

Auparavant, si le pipeline de build lié à une version avait publié des artefacts à l’aide de la tâche Publish Pipeline Artifact , les artefacts n’étaient pas récupérés automatiquement dans la version. Au lieu de cela, vous avez dû ajouter explicitement une tâche « Télécharger l'artefact pipeline » dans le pipeline de diffusion pour télécharger les artefacts.

Désormais, tous les artefacts du pipeline publiés par le pipeline de construction 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 diffusion.

Mises à jour du rapport de couverture du code Cobertura

Auparavant, lorsque vous avez exécuté des tests dans le pipeline et publié des résultats de couverture du code dans Azure DevOps, il était nécessaire de spécifier le résumé XML et un fichier de rapport HTML. En outre, les styles dans les rapports HTML ont été supprimés avant qu’ils ne soient rendus dans l’onglet couverture du code. Cette suppression de 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 de 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 open source ReportGenerator.

Rapports

Rapports d’échec et de durée ds builds

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. Lors de la première étape pour vous fournir des analyses de pipeline, nous avons ajouté deux rapports pour vous donner des métriques et des insights sur vos pipelines.

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

   

2. Le rapport sur la durée de vie des pipelines indiquera la durée de vie des pipelines et son évolution.

   

Disponibilité générale d’Analytics

Nous sommes heureux d’annoncer que les fonctionnalités d’analytique 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.

     

   • Durée du cycle et délai de livraison pour visualiser la manière dont le travail progresse 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.

     

   • Velocity suit la manière dont une équipe produit de la valeur au cours de 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 premier rapport de test défaillant pour obtenir des informations sur les principaux tests défaillants dans votre pipeline afin d’améliorer la fiabilité du pipeline et de réduire la dette des tests.

   

Nous continuerons également à offrir l’intégration de Power BI via des vues d’analytique 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 avant et n’avez pas besoin de suivre les étapes supplémentaires. Cela signifie que nous allons rendre obsolète l'extension Analytics marketplace 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 principal des tests échoués

• Intégration de Power BI

• Point de terminaison OData

• Azure DevOps Analytics

Wiki

Notifications sur les pages wiki

Jusqu’à présent, vous n’avez pas eu de 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é priorisée sur la base de ce ticket de suggestion. Pour en savoir plus, consultez notre documentation ici.

Administration

Gérer la facturation de votre organisation à partir d’Azure DevOps

Nous sommes heureux d’annoncer que vous pouvez désormais gérer la facturation de votre organisation à 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 à vos paramètres d’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 organisation 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 sujette à une erreur. Vous pouvez maintenant modifier l’abonnement Azure que votre organisation 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 à Visual Studio Marketplace pour gérer la configuration de la facturation. Nous avons ajouté la possibilité de payer des utilisateurs supplémentaires de base, de Gestionnaire de tests et de gestion des packages (Azure Artifacts). Vous pouvez augmenter ou diminuer le nombre d’utilisateurs que votre organisation paie à partir du nouvel onglet Facturation .

   

Étapes suivantes

Passez à Azure DevOps et jetez un coup d’œil.

Comment fournir des commentaires

Nous aimerions entendre ce que vous pensez de ces fonctionnalités. Utilisez le menu 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