notes de publication de Azure DevOps Server 2019

Community | de développement Configuration système requise | Termes du contrat de licence | Blog DevOps | Hachages SHA-1

Dans cet article, vous trouverez des informations sur la version la plus récente de Azure DevOps Server.

pour en savoir plus sur l’installation ou la mise à niveau d’un déploiement de Azure DevOps Server, consultez Azure DevOps Server configuration requise. pour télécharger Azure DevOps produits, visitez la page téléchargements Azure DevOps Server.

la mise à niveau directe vers Azure DevOps Server 2020 est prise en charge à partir de Azure DevOps Server 2019 ou Team Foundation Server 2015 ou version ultérieure. si votre déploiement de tfs est sur tfs 2010 ou une version antérieure, vous devez effectuer certaines étapes intermédiaires avant la mise à niveau vers Azure DevOps Server 2019. pour plus d’informations, consultez installer et configurer Azure DevOps localement.


Date de publication de Azure DevOps Server 2019.0.1 Patch 11:10 août 2021

nous avons publié un correctif pour Azure DevOps Server 2019.0.1 qui résout les problèmes suivants.

  • Erreur de correction de l’interface utilisateur de la définition de Build.

Azure DevOps Server 2019.0.1 Patch 10 Release Date : 13 avril 2021

nous avons publié un correctif pour Azure DevOps Server 2019.0.1 qui résout les problèmes suivants.

Pour appliquer le correctif 10, vous devez installer la AzureResourceGroupDeploymentV2 tâche.

Installation des tâches AzureResourceGroupDeploymentV2

Notes

toutes les étapes mentionnées ci-dessous doivent être effectuées sur un ordinateur Windows

Installer

  1. Extrayez le package AzureResourceGroupDeploymentV2.zip dans un nouveau dossier sur votre ordinateur. Par exemple : AzureResourceGroupDeploymentV2.

  2. Téléchargez et installez Node.js 14.15.1 et NPM (inclus dans le téléchargement Node.js) en fonction de votre ordinateur.

  3. Ouvrez une invite de commandes en mode administrateur et exécutez la commande suivante pour installer TFX-CLI.

npm install -g tfx-cli
  1. Créez un jeton d’accès personnel avec des privilèges d' accès complets et copiez-le. Ce jeton d’accès personnel sera utilisé lors de l’exécution de la commande TFX login .

  2. Exécutez la commande suivante à partir de l’invite de commandes. Lorsque vous y êtes invité, entrez l’URL du service et le jeton d’accès personnel.

~$ tfx login
Copyright Microsoft Corporation

> Service URL: {url}
> Personal access token: xxxxxxxxxxxx
Logged in successfully

  1. Exécutez la commande suivante pour télécharger la tâche sur le serveur. Utilisez le chemin d’accès du fichier .zip extrait de l’étape 1.
  ~$ tfx build tasks upload --task-path *<Path of the extracted package>*

Azure DevOps Server Date de publication de 2019.0.1 Patch 9:8 décembre 2020

nous avons publié un correctif pour Azure DevOps Server 2019.0.1 qui résout les problèmes suivants. Consultez le billet de blog pour plus d’informations.

  • CVE-2020-1325: Azure DevOps Server vulnérabilité d’usurpation d’identité
  • CVE-2020-17135: Azure DevOps Server vulnérabilité d’usurpation d’identité
  • CVE-2020-17145: Azure DevOps Server et Team Foundation Server vulnérabilité d’usurpation d’identité
  • Résoudre le problème avec TFVC ne traitant pas tous les résultats

Important

Veuillez lire les instructions fournies ci-dessous avant d’installer ce correctif.

Installation générale des correctifs

si vous avez Azure DevOps Server 2019.0.1, vous devez installer Azure DevOps Server Patch 9 2019.0.1.

Vérification de l’installation

  • Option 1: exécuter devops2019.0.1patch9.exe CheckInstall , devops2019.0.1patch9.exe est le fichier téléchargé à partir du lien ci-dessus. La sortie de la commande indique que le correctif a été installé ou qu’il n’est pas installé.

  • Option 2: Vérifiez la version du fichier suivant : [INSTALL_DIR]\Azure DevOps Server 2019\Application Tier\Web Services\bin\Microsoft.VisualStudio.Services.Feed.Server.dll . Azure DevOps Server 2019 est installé sur c:\Program Files\Azure DevOps Server 2019 par défaut. après l’installation de Azure DevOps Server 2019.0.1 Patch 9, la version sera 17.143.30723.4.

Installation des tâches AzurePowerShellV4

Notes

toutes les étapes mentionnées ci-dessous doivent être effectuées sur un ordinateur Windows

Prérequis

  1. installez Azure PowerShell Az module Azure PowerShell sur votre ordinateur d’agent privé.

  2. Créez un pipeline avec la tâche AzurePowerShellV4 . Vous ne verrez qu’une erreur de type échec dans la tâche.

Installer

  1. Extrayez le package AzurePowerShellV4.zip dans un dossier nommé AzurePowerShellV4.

  2. Téléchargez et installez Node.js 14.15.1 et NPM (inclus dans le téléchargement Node.js) en fonction de votre ordinateur.

  3. Ouvrez une invite de commandes en mode administrateur et exécutez la commande suivante pour installer TFX-CLI.

npm install -g tfx-cli
  1. Créez un jeton d’accès personnel avec des privilèges d' accès complets et copiez-le. Ce jeton d’accès personnel sera utilisé lors de l’exécution de la commande TFX login .

  2. Exécutez la commande suivante à partir de l’invite de commandes. Lorsque vous y êtes invité, entrez l’URL du service et le jeton d’accès personnel.

~$ tfx login
Copyright Microsoft Corporation

> Service URL: {url}
> Personal access token: xxxxxxxxxxxx
Logged in successfully

  1. Exécutez la commande suivante pour télécharger la tâche sur le serveur. Le chemin d’accès du package extrait sera D:\Tasks (1) \AzurePowerShellv4.
  ~$ tfx build tasks upload --task-path *<Path of the extracted package>*

Azure DevOps Server la Date de publication de 2019.0.1 Patch 8:8 septembre 2020

nous avons publié un correctif de sécurité pour Azure DevOps Server 2019.0.1 qui résout les problèmes suivants. Consultez le billet de blog pour plus d’informations.

  • DTS 1713492-comportement inattendu lors de l’ajout de groupes AD aux autorisations de sécurité.

Date de publication de Azure DevOps Server 2019.0.1 Patch 7:14 juillet 2020

nous avons publié un correctif de sécurité pour Azure DevOps Server 2019.0.1 qui résout les problèmes suivants. Consultez le billet de blog pour plus d’informations.

  • CVE-2020-1326: vulnérabilité de script entre sites
  • Le pipeline de build affiche une connexion incorrecte pour les utilisateurs non autorisés lors de la sélection d’une autre source git.
  • Correction de l’erreur lors de la modification de l’héritage à activé ou désactivé dans la définition de build XAML.

Azure DevOps Server la Date de publication de 2019.0.1 Patch 6:10 juin 2020

nous avons publié un correctif de sécurité pour Azure DevOps Server 2019.0.1 qui résout les problèmes suivants. Consultez le billet de blog pour plus d’informations.

  • CVE-2020-1327: assurez-vous que Azure DevOps Server nettoie les entrées utilisateur
  • Ajout de la prise en charge de SHA2 dans SSH sur Azure DevOps

Azure DevOps Server Date de publication de 2019.0.1 Patch 5:10 mars 2020

nous avons publié un correctif de sécurité pour Azure DevOps Server 2019.0.1 qui résout les problèmes suivants. Consultez le billet de blog pour plus d’informations.

Azure DevOps Server Date de publication de 2019.0.1 Patch 3:10 septembre 2019

Nous avons publié un correctif de sécurité pour Azure DevOps Server 2019.0.1 qui corrige les bogues suivants. Consultez le billet de blog pour plus d’informations.

  • CVE-2019-1305  : Vulnérabilité aux scripts de site à site (XSS) dans les dépôts
  • CVE-2019-1306  : Vulnérabilité d’exécution de code à distance dans le Wiki

Azure DevOps Server Date de publication de 2019.0.1 Patch 2:13 août 2019

Nous avons publié un correctif de sécurité pour Azure DevOps Server 2019.0.1 qui corrige le bogue suivant. Consultez le billet de blog pour plus d’informations.

  • Nous avons ajouté des informations aux connexions de service pour préciser qu’elles sont autorisées pour tous les pipelines par défaut.

Azure DevOps Server Date de publication de 2019.0.1 Patch 1:9 juillet 2019

Nous avons publié un correctif de sécurité pour Azure DevOps Server 2019.0.1 qui corrige les bogues suivants. Consultez le billet de blog pour plus d’informations.

  • CVE-2019-1072  : Vulnérabilité de l’exécution de code à distance dans le suivi des éléments de travail
  • CVE-2019-1076  : Vulnérabilité de script intersite (XSS) dans les demandes de tirage (pull requests)

Azure DevOps Server Date de publication de 2019.0.1:21 mai, 2019

Azure DevOps Server 2019.0.1 est un cumul de correctifs de bogues. il comprend tous les correctifs des correctifs Azure DevOps Server 2019 précédemment publiés. vous pouvez installer directement Azure DevOps Server 2019.0.1 ou effectuer une mise à niveau à partir de Azure DevOps Server 2019 ou Team Foundation Server 2012 ou version ultérieure.

Notes

l’outil de Migration de données sera disponible pour Azure DevOps Server 2019.0.1 environ trois semaines après cette version. Pour consulter la liste des versions actuellement prises en charge pour l’importation, cliquez ici.

Cette version inclut les corrections des bugs suivants :

Azure Boards

  • « Les critères de champ pour ce plan comportent une erreur. » lors de la configuration d’un plan. Signalé par le biais du Community développeur.
  • apiwitcontroller. ExecuteQuery lève une exception lorsqu’une requête a la même colonne plusieurs fois.
  • Dans le modèle d’objet client utilisant l’étendue OAuth vso.work_full, WorkItemServer. DownloadFile () échoue.
  • La copie d’une image incorporée à partir d’un champ d’élément de travail vers un autre champ d’élément de travail d’un autre projet peut créer une image endommagée.

Azure Repos

  • « TF401019 : GitRepositoryNotFoundException ».

Azure Pipelines

  • L' onglet analyse des tests contient une étoile (*) qui indique la version préliminaire, même si cette fonctionnalité n’est pas en préversion.
  • Sous l’onglet mises en production, l’action de gestion de la sécurité est désormais présentée à tous les utilisateurs, qu’ils soient autorisés ou non à modifier les autorisations.
  • Dans les pages d’accueil des versions, l’action démarrer le brouillon de la version préliminaire était la création d’une nouvelle version, mais elle commence à présent la version brouillon.

Azure Test Plans

  • Le filtre de 1 heure sur les CompletedDate TestRuns et TestResults est trop précis.
  • Dans le type d’élément de travail cas de test , le type, « cas de test », ne doit pas être localisé.
  • Les cas de test ne sont pas affichés dans MTM ou dans un navigateur.
  • « Étape de validation : vous n’êtes pas autorisé à déclencher des mises en production sur le pipeline de mise en production associé » lors de l’exécution de tests automatisés à partir d’un plan de test. Signalé par le biais du Community développeur.
  • À l’aide de l' API supprimer un cas de test, les cas de test peuvent être supprimés d’autres projets. Signalé par le biais du Community développeur.
  • Le fait de cliquer sur un lien d’élément de travail dans Test Runner ouvre l’URL de l’élément de travail à l’intérieur de test Runner au lieu du navigateur par défaut.
  • L’état du cas de test n’est pas mis à jour pour les utilisateurs qui se déconnectent de test Runner.
  • Le nom d’utilisateur et l’adresse de messagerie ne sont pas affichés dans la liste déroulante utilisateur dans Test Runner.

Azure Artifacts

  • Les déplacements vers le haut et vers le haut ne sont pas localisés dans les en amont.

Analytics

  • Les rapports d’analyse peuvent afficher des données incomplètes, car le modèle est marqué comme « prêt » avant d’être réellement terminé.
  • Les widgets vélocité, avancement et burnup affichent différents travaux planifiés pour les utilisateurs de fuseaux horaires différents.
  • Un blocage peut être placé sur l’ingestion des données analytiques pendant la maintenance, ce qui peut entraîner des rapports obsolètes.

Général

  • Les éléments de navigation gauche sont conservés sur IE lorsque l’espace est insuffisant.

Administration

  • Journalisation supplémentaire ajoutée à la mise à niveau du regroupement pour aider à déboguer les problèmes.
  • Lorsque TfsConfig offlineDetach échoue, le message d’erreur n’est pas actionnable.
  • Le service TfsJobAgent se bloque.
  • L’extension de recherche n’est pas installée une fois la configuration terminée.
  • La console Administration cesse de répondre lorsque la base de la configuration est endommagée.
  • Les raccordements de service peuvent ne pas traiter correctement les notifications.
  • L’indexation de Code Search ne démarre pas après la configuration de la recherche.
  • Il existe des chaînes non localisées dans les résultats des pages de recherche.

Cette version comprend la mise à jour suivante :

prise en charge de Visual Studio 2019 (VS2019) dans Visual Studio tâche de Test

nous avons ajouté la prise en charge de Visual Studio 2019 à la tâche de Test Visual Studio dans les pipelines. pour exécuter des tests à l’aide de la plateforme de test pour Visual Studio 2019, sélectionnez les options les plus récentes ou Visual Studio 2019 dans la liste déroulante version de la plateforme de test.

capture d’écran de la section des options d’exécution montrant la liste déroulante version de la plateforme de Test sélectionnée avec l’option Visual Studio 2019 la plus récente sélectionnée.


Date de publication de Azure DevOps Server 2019 Patch 2:14 mai, 2019

nous avons publié un correctif de sécurité pour Azure DevOps Server 2019 qui résout les bogues suivants. Consultez le billet de blog pour plus d’informations.

  • CVE-2019-0872  : Vulnérabilité liée aux scripts intersites (XSS) dans Test Plans
  • CVE-2019-0971  : Vulnérabilité sur la divulgation d’informations dans l’API Repos
  • CVE-2019-0979  : Vulnérabilité liée aux scripts intersites (XSS) dans le hub Utilisateur

Azure DevOps Server 2019 correctif 1 Date de publication : 9 avril 2019

nous avons publié un correctif de sécurité pour Azure DevOps Server 2019 qui résout les bogues suivants. Consultez le billet de blog pour plus d’informations.

  • CVE-2019-0857: usurpation de vulnérabilité dans le wiki
  • CVE-2019-0866  : Vulnérabilité liée à l’exécution de code à distance dans Pipelines
  • CVE-2019-0867  : Vulnérabilité liée aux scripts intersites (XSS) dans Pipelines
  • CVE-2019-0868  : Vulnérabilité liée aux scripts intersites (XSS) dans Pipelines
  • CVE-2019-0869: vulnérabilité d’injection HTML dans pipelines
  • CVE-2019-0870  : Vulnérabilité liée aux scripts intersites (XSS) dans Pipelines
  • CVE-2019-0871  : Vulnérabilité liée aux scripts intersites (XSS) dans Pipelines
  • CVE-2019-0874: vulnérabilité de script entre sites (XSS) dans pipelines
  • CVE-2019-0875: vulnérabilité d’élévation de privilèges dans Boards

Azure DevOps Server 2019 Date de publication : 5 mars, 2019

Notes

l’outil de Migration de données sera disponible pour Azure DevOps Server 2019 environ trois semaines après cette version. Pour consulter la liste des versions actuellement prises en charge pour l’importation, cliquez ici.


Date de publication RC2:22 janvier, 2019

résumé des nouveautés de Azure DevOps Server 2019 RC2

Nous avons ajouté les fonctionnalités suivantes à RC2 :


Date de publication de la version RC1:19 novembre 2018

résumé des nouveautés de Azure DevOps Server 2019 RC1

Azure DevOps Server 2019 introduit une nouvelle expérience de navigation et de nombreuses nouvelles fonctionnalités. Voici les principales :

Vous pouvez également accéder à des sections individuelles pour voir les nouvelles fonctionnalités :


Général

Annonce de Azure DevOps Server

le 10 septembre, nous avons annoncé Azure DevOps comme évolution des Visual Studio Team Services et des Team Foundation Server. Azure DevOps Server 2019 est notre première version locale avec cette nouvelle réputation. Vous trouverez plus d’informations dans notre billet de blog.

Nouvelle expérience de navigation

Nous introduisons une nouvelle navigation pour moderniser l’expérience utilisateur. cette nouvelle navigation s’est déployée dans le service Azure DevOps et est désormais disponible dans Azure DevOps Server 2019. Pour plus d’informations, consultez notre blog .

Nouveau point de navigation

modifications apportées à Artifacts et Release Management le gestionnaire de licences du pipeline de déploiement

en fonction des commentaires des utilisateurs, nous apportons deux modifications clés à nos licences avec Azure DevOps Server 2019. Tout d’abord, les clients n’ont plus besoin d’acheter l’extension d’artefact pour utiliser Artifacts. une utilisation de licence Artifacts sera désormais incluse dans la licence de base. Tous les utilisateurs qui disposent d’une licence de base peuvent désormais utiliser Artifacts. deuxièmement, les clients n’auront plus besoin d’acheter Release Management Pipelines de déploiement. tout comme les Pipelines de Build, Release Management Pipelines de déploiement sont désormais inclus avec Azure DevOps Server 2019.

Prise en charge de Azure SQL Database

afin de simplifier l’exécution de Azure DevOps 2019 dans Azure, nous avons activé la prise en charge de Azure SQL Database (usage général S3 et versions ultérieures). Cela vous permettra de tirer parti des fonctionnalités de sauvegarde étendues et des options de mise à l’échelle pour répondre à vos besoins tout en réduisant la charge administrative liée à l’exécution du service. Notez que votre machine virtuelle hôte doit se trouver dans la même région Azure que votre base de données afin de réduire la latence. Pour plus d’informations, consultez la documentation .

Élément de travail & test modèle objet client API SOAP dans les futures versions

Azure DevOps Server 2019 continue à prendre en charge l’API SOAP de suivi des éléments de travail et le modèle d’objet client. Toutefois, elle est marquée comme dépréciée dans les futures versions de Azure DevOps Server. Vous trouverez plus d’informations dans notre documentation.

Héritage de processus sur les nouvelles collections

L’héritage des processus est désormais disponible sur les nouvelles collections. Les utilisateurs devront prendre une décision totalité sur le modèle de processus lors de la création d’une nouvelle collection. Consultez notre documentation sur le modèle d’héritage et la façon dont il est différent de XML.

Héritage de processus

Nous comprenons l’importance de la recherche et revenons à la zone de recherche étendue sur l’en-tête du produit. En outre, vous pouvez maintenant appeler la zone de recherche en cliquant simplement sur/sur n’importe quelle page de service dans Azure DevOps. Cette fonctionnalité a été hiérarchisée en fonction de la voix utilisateursuivante.

Voici la zone de recherche par défaut :

Zone de recherche par défaut

Une fois que vous avez tapé un « / », la zone de recherche étendue s’affiche :

Zone de recherche étendue

Menu volant mon travail

Une nouvelle fonctionnalité que nous sommes ravis d’introduire est le menu volant mon travail . Nous avons reçu des commentaires qui, lorsque vous êtes dans une partie du produit et que vous souhaitez obtenir des informations d’une autre partie, vous ne souhaitez pas perdre votre contexte. Grâce à cette nouvelle fonctionnalité, vous pouvez accéder à ce lanceur à partir de n’importe quel endroit du produit. il vous donne un aperçu rapide des informations cruciales, notamment vos éléments de travail, les demandes de tirage (pull requests) et tous les favoris. grâce à ce nouveau lanceur, si vous êtes en cours d' Repos dans votre code, mais que vous souhaitez ensuite vérifier rapidement l’élément de travail sur lequel vous devez travailler, vous pouvez simplement cliquer sur le menu volant pour voir les éléments de travail qui vous sont assignés et sélectionner l’élément suivant.

Ci-dessous, vous pouvez voir le menu volant mon travail représentant les éléments de travail qui me sont assignés :

Menu volant mon travail

Ici, vous pouvez voir le deuxième tableau croisé dynamique qui affiche les PRs qui me sont assignées. Dans le menu volant, vous disposez également d’un accès en un clic pour afficher plus de demandes de tirage :

PR mon travail

Ici, vous pouvez voir le dernier pivot, qui est tout ce que vous avez préféré. Cela comprend les équipes, les tableaux de bord, les tableaux, les journaux des travaux en souffrance, les requêtes et les référentiels favoris :

Favoris du menu volant mon travail

Boards

Teams qui utilisent GitHub Enterprise pour le code et qui souhaitent des fonctionnalités de gestion de projet enrichies peuvent désormais intégrer leurs référentiels à Azure Boards. en connectant GitHub et Azure Boards, vous pouvez obtenir toutes les fonctionnalités telles que les journaux des travaux en souffrance, les tableaux, les outils de planification de sprint, les différents types d’éléments de travail et un flux de travail qui s’intègre aux flux de travail de développement dans GitHub.

Il est facile de lier des validations et des requêtes de tirage à des éléments de travail. Mentionnez l’élément de travail à l’aide de la syntaxe suivante :

AB#{work item ID}

mentionnez un élément de travail dans le message de validation, le titre de la demande de tirage ou la description de la demande de tirage, et Azure Boards créera un lien vers cet artefact. Par exemple, considérez un message de validation de la façon suivante :

Adds support for deleting connections. Fixes AB#20.

cela va créer un lien à partir de l’élément de travail #20 à la validation dans GitHub, qui apparaîtra dans la section de développement de l’élément de travail.

capture d’écran de Azure DevOps avec la section de développement appelée out.

Si les mots « Fix », « correctifs » ou « corrigés » précèdent la mention d’élément de travail (comme indiqué ci-dessus), l’élément de travail est déplacé vers l’état terminé lorsque la validation est fusionnée dans la branche par défaut.

les Teams qui utilisent Azure Pipelines pour générer le code dans GitHub voient également les éléments de travail liés à leurs validations GitHub dans le résumé de la build.

Nouveau hub d’éléments de travail

Le hub d’éléments de travail est notre nouveau hub qui servira de page d’hébergement de vos éléments de travail ! Ici, vous avez de nombreux affichages de liste différents de vos éléments de travail dont la portée est limitée. Vous pouvez l' afficher pour obtenir rapidement un aperçu de tout le travail qui vous est assigné ou récemment mis à jour , qui affiche tous les éléments de travail de votre projet qui ont été mis à jour récemment. Vous pouvez consulter toutes les options de votre liste ci-dessous :

Hub d’éléments de travail

Si vous souhaitez limiter encore davantage vos listes, vous pouvez filtrer sur le type, sur assigné à, sur l’État, la zone, les balises et le mot clé. Une fois que vous disposez de votre vue de liste souhaitée, vous pouvez trier les éléments de travail en cliquant simplement sur l’en-tête de la colonne. Si une colonne est trop étroite pour afficher le contenu complet de la colonne, vous pouvez facilement redimensionner la colonne dans la zone d’en-tête. Ces expériences peuvent être consultées ci-dessous :

Liste des hubs d’éléments de travail

nouveaux hubs de Boards, de journaux des travaux en souffrance et de sprints

Le Hub des journaux des travaux en souffrance a été divisé en trois hubs distincts pour améliorer l’expérience utilisateur. Bien que puissant, l’ancien Hub de journaux des travaux en souffrance était à l’origine d’un trop grand nombre de fonctionnalités. Cela rend souvent difficile la recherche de la fonctionnalité ou des fonctionnalités que les utilisateurs recherchaient. Pour résoudre ce problème, nous avons divisé le Hub des journaux des travaux en souffrance en :

  • Le concentrateur des journaux des travaux en souffrance est désormais à l’emplacement des journaux des travaux en souffrance d’un projet. Un backlog est une liste hiérarchisée de travaux pour l’équipe. Les journaux des travaux en souffrance fournissent des outils de planification tels que la hiérarchie des éléments de travail, les prévisions et l’expérience de planification des sprints.
  • le nouveau hub Boards est associé à tous les Boards de Kanban pour un projet. Boards sont utilisés pour communiquer l’état et le flow. Les cartes (éléments de travail) se déplacent de gauche à droite dans le tableau par le biais de colonnes définies par l’équipe.
  • Le nouveau hub de sprints est la page d’hébergement des fonctionnalités utilisées pour planifier et exécuter un incrément de travail. Chaque sprint contient un backlog des sprints, un groupe de tâches et une vue pour gérer et définir la capacité de l’équipe.

hub Boards

Nouveau hub de requêtes

Le nouveau hub de requêtes simplifie la plupart des fonctionnalités de requêtes existantes de l’ancien Hub avec une apparence plus moderne, et fournit de nouvelles fonctionnalités qui facilitent l’accès aux requêtes qui sont importantes pour vous. Voici quelques-unes des principales nouveautés de cette expérience :

  • Pages de répertoires avec les informations de dernière modification par et la capacité à rechercher des requêtes
  • Breadcrumb avec URL uniques pour les dossiers afin de marquer des groupes importants de requêtes
  • Accès rapide à vos requêtes favorites à partir de la page résultats

pour plus d’informations sur ces mises à jour passionnantes, consultez notre blog DevOps.

Déplacer des éléments de travail vers un autre projet et modifier un type d’élément de travail

Vous pouvez maintenant modifier le type d’élément de travail ou déplacer les éléments de travail vers un autre projet dans une collection de projets. Ces fonctionnalités requièrent que l’entrepôt de données soit désactivé. Lorsque l’entrepôt de données est désactivé, vous pouvez utiliser le service d’analyse pour répondre à vos besoins en matière de création de rapports. Pour en savoir plus sur la désactivation de l’entrepôt de données, consultez désactiver l’entrepôt de données et le cube.

Fonctionnalités de planification de Sprint

Les nouvelles fonctionnalités de planification de Sprint permettent d’accélérer et d’améliorer l’expérience de planification des sprints.

  • Créez votre prochain sprint ou abonnez-vous à une planification de Sprint existante directement à partir du Hub sprints .
  • Utilisez le nouveau volet de planification dans votre journal des travaux en souffrance pour glisser-déplacer des éléments de travail dans des sprints futurs. Le volet planification comprend les dates des sprints, le nombre d’éléments de travail et les efforts planifiés.
  • Ajoutez des spécifications en haut du panneau des tâches ou utilisez création rapide pour ajouter au début, au bas ou à la ligne de votre choix dans le backlog de vos sprints.
  • Utilisez des filtres pour assigner, type d’élément de travail, État et balises pour adapter les vues à vos besoins.

Planification de sprint

Nouvelles pages de répertoire

tous les nouveaux hubs, y compris les journaux des travaux en souffrance, les Boards et les sprints, disposent désormais de nouvelles pages de répertoires organisées avec les sections suivantes :

  • Continuer là où vous vous étiez arrêté Cette nouvelle section vous fournit un lien rapide direct jusqu’au dernier (tableau | Backlog | Sprint) sur lequel vous étiez.
  • Favoris Tous vos tableaux favoris, sprints et journaux des travaux en souffrance dans toutes les équipes.
  • Mes Toutes les cartes, les journaux des travaux en souffrance et les sprints pour les équipes auxquelles vous appartenez.
  • Tout Liste complète de toutes vos cartes, journaux des travaux en souffrance et sprints.

Pages de répertoire

Nouveau menu options d’affichage

les nouveaux hubs, y compris les journaux des travaux en souffrance, les Boards et les sprints, disposent d’un nouveau menu affichage Options . Il s’agit d’une nouvelle page d’hébergement pour toutes les actions permettant de personnaliser la disposition et le contenu de la page. Utilisez les options d’affichage pour activer des affichages supplémentaires, tels que l’affichage de la hiérarchie dans les journaux des travaux en souffrance ou la modification de l’option regrouper par sur un tableau de tâches, pour activer le panneau latéral pour le mappage et la planification des sprints, ou pour explorer les graphiques des détails du travail.

Options d’affichage

en savoir plus sur ces mises à jour passionnantes, le nouveau volet de profil d’équipe et les favoris sur notre blog DevOps.

Les annotations de carte incluent les bogues et les types d’éléments de travail personnalisés

Les annotations de carte sont appréciées pour leur affichage et leur interaction intuitives. Auparavant, les annotations de carte étaient limitées aux types de niveaux de backlog par défaut et ne prenaient pas en charge les bogues ou les types personnalisés. Avec la nouvelle version, nous avons supprimé la restriction sur les types d’éléments de travail et ajouté la possibilité d’afficher des bogues et n’importe quel type d’élément de travail personnalisé en tant qu’annotation de carte.

Les paramètres de tableau pour les annotations de carte ont été développés pour inclure tous les types d’éléments de travail disponibles pour ce niveau de Backlog.

Paramètres d’annotation

Lorsque les annotations pour l’élément de travail sont activées, les nombres pour ce type d’élément de travail sont inclus dans la carte sous la forme d’une liste de vérification distincte.

Élément de travail de l’annotation

La création rapide de types d’éléments de travail activés est également disponible via le menu contextuel carte.

Création rapide d’une annotation

Déplacer le travail à l’aide des zones et itérations suggérées

Il peut être courant de travailler dans la même zone ou itération et de parcourir les hiérarchies à plusieurs reprises lors du déplacement des éléments de travail. Les contrôles de chemin de zone et d' itération incluent désormais une liste de valeurs récemment utilisées comme suggestions, ce qui vous permet d’accéder rapidement à la définition et au déplacement.

Liste déroulante de la zone

En outre, les dates d' itération sont incluses à droite du nom afin que vous puissiez juger rapidement quand un élément de travail doit être remis.

Liste déroulante des itérations

Interroger le travail dans la planification des itérations avec +/- @CurrentIteration

La @CurrentIteration macro qui permet à votre équipe de suivre le travail en fonction de votre planification d’itération prend désormais en charge l’offset d’entier. Gardez facilement les onglets du travail qui n’ont pas été fermés avec @CurrentIteration -1, ou examinez le travail prévu pour les itérations futures avec @CurrentIteration + 1. pour plus d’informations, consultez le @CurrentIteration billet sur le Blog de Microsoft DevOps. Cette fonctionnalité a été hiérarchisée en fonction de ce qui est actuellement la #12 suggestion la plus élevée avec 456 votes.

Clarifier les planifications d’itérations de requêtes avec le @CurrentIteration paramètre Team

si vous avez utilisé la @CurrentIteration macro dans des requêtes dans le passé, vous avez peut-être remarqué que les résultats peuvent varier si le contexte de l’équipe change dans Teams avec des planifications d’itération différentes. Désormais, lorsque vous créez ou modifiez une requête avec la @CurrentIteration macro, vous devez également sélectionner l’équipe avec la planification d’itération qui s’applique à la requête. Avec le paramètre Team, vous pouvez utiliser la @CurrentIteration macro dans la même requête, mais entre les équipes. Par exemple, il peut s’agir d’une requête pour des éléments de travail dans deux projets d’équipe différents utilisant des noms d’itérations différents et même des planifications. Cela signifie qu’il n’est plus nécessaire de mettre à jour les requêtes à mesure que les sprints changent ! pour plus d’informations, consultez le @CurrentIteration billet sur le Blog de Microsoft DevOps. Cette fonctionnalité a été rendue prioritaire à la suite d’une suggestion.

Paramètre d’équipe

Interroger le travail dans les chemins de zone d’une équipe à l’aide de la nouvelle @TeamAreas macro

dans les paramètres d’une équipe, vous pouvez associer un ou plusieurs chemins de zone, ce qui vous permet de cibler les journaux des travaux en souffrance, les Boards, les Plans et même les tableaux de bord pour le travail de cette équipe. Si vous souhaitez écrire une requête pour une équipe, vous deviez répertorier les chemins de zone spécifiques pour cette équipe dans les clauses de requête. À présent, une nouvelle @TeamAreas macro est à votre disposition pour vous permettre de référencer facilement les chemins de zone appartenant à l’équipe spécifiée.

macro des zones d’équipe dans l’éditeur de requête

Rechercher les champs de texte enrichi vides

Recherchez des éléments de travail qui ont un champ de texte enrichi vide, tel que Description, à l’aide de l’opérateur de requête IsEmpty .

Rechercher facilement des éléments de travail existants dans les expériences de liaison et de mention

Lorsque vous souhaitez lier deux éléments de travail existants ensemble, vous pouvez désormais facilement trouver l’élément qui vous intéresse à l’aide de notre nouveau contrôle de recherche d’élément de travail. Le sélecteur de requête a été remplacé par des suggestions Inline basées sur les éléments de travail récemment consultés, ainsi qu’un point d’entrée pour rechercher un élément de travail spécifique par ID ou par titre.

Liaison d’éléments de travail

Auparavant, il était impossible d’ouvrir un élément de travail à partir de la page des résultats de la recherche si le volet Aperçu de l’élément de travail était désactivé. Cela complique la recherche dans les résultats de votre recherche. Vous pouvez maintenant cliquer sur le titre de l’élément de travail pour ouvrir les éléments de travail dans une fenêtre modale. Cette fonctionnalité a été hiérarchisée de UserVoice.

Repos

Sélecteur de branche amélioré

la plupart des expériences dans Azure Repos vous obligent à sélectionner un référentiel, puis une branche dans ce référentiel. Pour améliorer cette expérience pour les organisations avec un grand nombre de branches, nous déployons un nouveau sélecteur de branche. Le sélecteur vous permet désormais de sélectionner vos branches favorites ou de rechercher rapidement une branche.

Sélecteur de branche

Recevoir des notifications lorsque les stratégies de demande de tirage sont ignorées

Pour les équipes qui utilisent des requêtes de tirage (PRs) et des stratégies de branche, il peut arriver que les utilisateurs aient besoin de remplacer et de contourner ces stratégies, par exemple lors du déploiement d’un correctif sur un problème de production en milieu de nuit. Il est logique de faire confiance aux développeurs pour qu’ils fassent la bonne chose et qu’ils utilisent la fonctionnalité de remplacement avec modération. En même temps, les équipes ont besoin d’un moyen de vérifier que ces remplacements de stratégie sont utilisés dans les bonnes situations. Pour prendre cela en charge, nous avons ajouté un nouveau filtre de notification pour permettre aux utilisateurs et aux équipes de recevoir des alertes par courrier électronique chaque fois qu’une stratégie est contournée. Commencez par le modèle création ou mise à jour d’une demande de tirage , puis sélectionnez contournement de la stratégie dans la liste des filtres. Les stratégies Select ont été contournées en tant que valeur et vous êtes averti à chaque fois qu’une demande de tirage est terminée, et les stratégies sont ignorées.

Notification de contournement de la stratégie

Autoriser le contournement des stratégies de branche sans abandonner la protection Push

Il existe de nombreux scénarios dans lesquels vous avez souvent besoin de contourner une stratégie de branche, en restaurant une modification qui a provoqué un arrêt de la génération, en appliquant un correctif au milieu de la nuit, etc. Nous avons précédemment proposé une autorisation (« dispenser de l’application de la stratégie ») pour aider les équipes à gérer les utilisateurs qui ont reçu la possibilité de contourner les stratégies de branche lors de l’exécution d’une requête de tirage. Toutefois, cette autorisation a également accordé la possibilité de transmettre directement à la branche, en ignorant entièrement le processus PR.

Pour améliorer cette expérience, nous avons divisé l’ancienne autorisation pour offrir un meilleur contrôle aux équipes qui accordent des autorisations de contournement. Il existe deux nouvelles autorisations pour remplacer l’ancienne :

  1. Contourner les stratégies lors de l’exécution des requêtes de tirage. Les utilisateurs disposant de cette autorisation peuvent utiliser l’expérience de « remplacement » pour les demandes de tirage (pull requests).
  2. Contourner les stratégies lors de la Poussée. Les utilisateurs disposant de cette autorisation peuvent effectuer une transmission de type push directement aux branches qui ont des stratégies requises configurées.

En accordant la première autorisation et en refusant la seconde, un utilisateur sera en mesure d’utiliser l’option de contournement, si nécessaire, mais aura toujours la protection d’un push accidentel vers une branche avec des stratégies.

Notes

Cette modification n’introduit aucun changement de comportement. Les utilisateurs qui étaient auparavant autorisés à « exempter de l’application de la stratégie » seront autorisés à accéder aux deux nouvelles autorisations. ils seront donc en mesure de remplacer la saisie semi-automatique sur PRs et de les transmettre directement aux branches avec des stratégies.

Pour plus d’informations, consultez la documentation sur les autorisations Set Branch .

Décrire rapidement les requêtes de tirage à l’aide de messages de validation

L’écriture de messages de validation descriptifs ajoute de la valeur à l’historique de n’importe quel dépôt git. Pour encourager les messages de validation de qualité, les nouvelles requêtes de tirage (PR) qui ont plusieurs validations requièrent que les contributeurs entrent un titre manuellement.

Les descriptions des demandes de tirage continueront à être vides par défaut, mais une nouvelle fonctionnalité facilitera l’incorporation des messages de validation des validations de demandes de tirage dans la description de la demande de tirage. Pour ajouter les messages de validation, cliquez simplement sur Ajouter des messages de validation pour ajouter les messages de validation à la fin du texte de description de la demande de tirage.

Créer des requêtes de tirage sans équipe par défaut en tant que réviseur

Lors du premier lancement de l’expérience de requête de tirage (PR), nous avons pensé qu’il serait judicieux d’attribuer toutes les requêtes de requête au contexte d’équipe que vous aviez sélectionné lors de la création de la demande de tirage. Ce comportement a été un point de frustration, car de nombreux utilisateurs n’ont pas remarqué la connexion entre le contexte de l’équipe et l’attribution de la demande de tirage. En fait, il s’agit de l’une de nos principales suggestions UserVoice.

Dans le cadre des nouvelles modifications de navigation, nous avons pris la possibilité de modifier cette association par défaut avec les équipes. Vous remarquerez deux modifications :

  1. Lors de la création d’un PR, aucun réviseur n’est ajouté par défaut. La liste des réviseurs dispose d’une fonctionnalité pour faciliter l’ajout de personnes et de groupes qui ont été ajoutés à PRs récemment. La stratégie des réviseurs requis peut également aider les équipes qui souhaitent s’assurer que des réviseurs spécifiques sont ajoutés pour examiner leur code.
  2. Le Hub requêtes de tirage a une nouvelle section personnalisable. Par défaut, cette section affiche le paramètre PRs « assigned to My Teams », qui fournit des fonctionnalités équivalentes comme l’ancienne section. Toutefois, si vous appartenez à plusieurs équipes, cette section affiche la valeur de PRs affectée à l’une de vos équipes. La section est également personnalisable. il vous suffit de cliquer sur l’action « personnaliser cette vue » près de l’en-tête de la section.

Normaliser les descriptions des requêtes de tirage à l’aide de modèles

L’écriture de bonnes descriptions de demandes de tirage est un excellent moyen d’aider les réviseurs à savoir ce qui se passe lors de l’examen du code. Ils sont également un excellent moyen d’effectuer le suivi des opérations à effectuer pour chaque modification, telles que le test, l’ajout de tests unitaires et la mise à jour de la documentation. Un grand nombre d’entre vous ont demandé d’ajouter des modèles de demande de tirage pour faciliter l’écriture de descriptions intéressantes pour les équipes, et nous avons maintenant ajouté cette fonctionnalité.

Outre la prise en charge d’un modèle de description de PR par défaut, les équipes peuvent ajouter plusieurs modèles, qui vous sont présentés dans un menu de la page créer des demandes de tirage. Cliquez simplement sur le bouton Ajouter un modèle pour choisir un modèle dans le référentiel afin de l’ajouter à la description de la demande de tirage.

Ajouter un modèle pour PR

Les modèles spécifiques à la branche sont également pris en charge si vous souhaitez appliquer un modèle différent pour une demande de tirage dans une branche spécifique, ou un dossier de branches. Par exemple, si vous souhaitez avoir un modèle spécifique à toutes les branches qui commencent par « Hotfix/ », vous pouvez ajouter un modèle qui sera utilisé pour toutes les demandes de tirage dans ces branches.

Pour en savoir plus sur la création et l’utilisation de modèles, consultez la documentation sur les modèles de requête de tirage .

Modifier la branche cible d’une demande de tirage (pull request)

Pour la plupart des équipes, presque toutes les requêtes de tirage ciblent la même branche, par exemple main ou develop . Toutefois, dans le cas où vous avez besoin de cibler une branche différente, il est facile d’oublier de modifier la branche cible à partir de la valeur par défaut. Avec la nouvelle fonctionnalité permettant de modifier la branche cible d’une requête de tirage active, il s’agit désormais d’une action simple. Cliquez simplement sur l’icône de crayon en regard du nom de la branche cible dans l’en-tête de requête de tirage.

Modifier la branche cible

Au-delà de la simple correction des erreurs, la fonctionnalité de modification des branches cibles permet également de « recibler » une requête de tirage lorsque la branche cible a été fusionnée ou supprimée. Imaginez un scénario dans lequel vous avez une demande de tirage ciblant une branche de fonctionnalité qui contient des fonctionnalités dont vos modifications dépendent. Vous souhaitez passer en revue vos modifications dépendantes de l’isolation par rapport à d’autres modifications de la branche de fonctionnalité. vous devez donc cibler initialement features/new-feature . Les réviseurs peuvent alors voir simplement vos modifications et conserver les commentaires appropriés.

À présent, réfléchissez à ce qui se passerait si la branche de fonctionnalités avait également un PR actif et a été fusionnée dans main avant vos modifications ? Auparavant, vous deviez abandonner vos modifications et créer un nouveau PR dans main , ou fusionner votre demande de tirage dans features/new-feature , puis créer une autre demande de tirage à partir de features/new-feature à main . Avec cette nouvelle action pour mettre à jour la branche cible, vous pouvez simplement modifier la branche cible de la demande de tirage à partir de features/new-feature en main , en conservant tout le contexte et les commentaires. La modification de la branche cible crée même une nouvelle mise à jour de la demande de tirage, ce qui facilite la consultation des différences précédentes avant la modification de la branche cible.

Mise à jour de la branche cible

Les auteurs d’extensions peuvent interroger le contexte sur le référentiel actuel

L’un des défis pour l’auteur d’une extension de contrôle de version consiste à faire en sorte que le contexte du référentiel soit affiché à l’utilisateur, tel que le nom, l’ID et l’URL. Pour vous aider, nous avons ajouté le VersionControlRepositoryService en tant que service accessible en extension. À l’aide de cela, un auteur d’extension peut demander des informations sur le contexte de référentiel git actuel dans l’interface utilisateur Web. Il possède actuellement une méthode, getCurrentGitRepository ().

  • Si un référentiel git est sélectionné, un objet GitRepository est retourné avec les données de base sur le référentiel (nom, ID et URL).
  • si un dépôt TFVC est sélectionné ou si le service est accessible en dehors des pages Azure Repos, la valeur null est retournée.

Voici un exemple d’extension qui utilise ce service.

Pipelines

Gérer des pipelines de build à l’aide de la page nouvelles builds

Nous apportons plusieurs améliorations et déployons une nouvelle version de la page Builds . Cette nouvelle version associe le répertoire de tous vos pipelines de génération et la liste des builds en cours afin que vous puissiez naviguer rapidement dans les builds de votre projet pour voir leur état. Il comprend également un aperçu des analyses de test pour le pipeline sélectionné.

Page nouvelles builds

Gérer les e-mails d’achèvement de build et de déploiement mieux en utilisant une mise en forme améliorée

Les e-mails de fin de build et de déploiement ont été mis à jour pour être plus filtrables par les règles de messagerie. Maintenant que la ligne objet inclut des informations plus pertinentes en un clin d’œil, le corps contient plus de détails et leur style est actualisé avec la dernière version.

Les éléments du nouveau format sont les suivants :

  • [Build result] [pipeline name] - [repository:branch] - [project name] - [commit]
  • [Deployment result] [pipeline name] > [release name] : [stage name]

Voici quelques exemples :

  • [Build succeeded] IdentityService.CI - MyRepo:main - MyProject - d3b90b80
  • [Deployment succeeded] New release pipeline > NotificationSpecialRelease-1 : Stage 1

suivre la nouvelle terminologie de Azure Pipelines unifiée

Tout au long des builds et des mises en production, des termes différents ont été utilisés à l’historique pour des concepts similaires. Dans d’autres cas, les significations des termes étaient vagues. Par exemple, en indiquant la différence entre un pool d’agents et une file d’attente d’agent.

la terminologie a été unifiée dans Azure Pipelines pour clarifier ses concepts. Vous voyez maintenant les termes unifiés suivants :

Terme précédent Terme unifié Signification
Agent hébergé Agent hébergé par Microsoft Agent de build/mise en sortie qui s’exécute sur une infrastructure hébergée dans le Cloud et gérée par Microsoft.
Agent privé Agent autohébergé Un agent de build/mise en sortie qui s’exécute sur un ordinateur fourni et géré par vous-même.
Pool d’agents Pool d’agents Ensemble d’ordinateurs agents de niveau organisation qui peuvent exécuter des builds ou des mises en production.
File d’attente d’agents Pool d’agents Ensemble de machines de l’agent au niveau du projet qui peuvent exécuter des builds ou des mises en production. Il est lié à un pool d’agents au niveau de l’organisation.
Définition de build Pipeline de build Ensemble d’étapes de build de bout en bout pour une application.
Build Build Instance d’un pipeline de build qui exécute ou a été exécutée.
Phase Travail Série de tâches qui s’exécutent de façon séquentielle ou en parallèle sur un agent. Un pipeline de build ou de mise en version peut contenir un travail ou un graphique de plusieurs travaux.
Définition de mise en version Pipeline de mise en production Ensemble de bout en bout des étapes de mise en œuvre d’une application à déployer à travers différentes étapes.
Libérer Libérer Instance d’un pipeline de mise en service qui exécute ou a été exécutée.
Environnement Étape Entité logique et indépendante qui représente l’emplacement où vous souhaitez déployer une version générée à partir d’un pipeline de mise en version.
Travail/pipeline simultané Travail parallèle Une tâche parallèle vous donne la possibilité d’exécuter une tâche de build ou de mise en version unique à la fois dans votre organisation. Avec davantage de tâches parallèles disponibles, vous pouvez exécuter davantage de tâches de génération et de publication en même temps.
Point de terminaison de service Connexion au service Groupe de paramètres, tels que les informations d’identification, utilisé pour se connecter à des services externes pour exécuter des tâches dans une build ou une mise en service.

Pour plus d’informations, consultez la documentation sur les concepts .

Gérer les pipelines de mise en production à l’aide de la nouvelle page mises en production

Une nouvelle expérience utilisateur entièrement repensée est disponible pour la page d’accueil de la version Release. Consultez la liste des pipelines de version que vous publiez souvent sur la gauche. Vous pouvez également rechercher vos pipelines et les rendre préférés.

Page d’accueil de la publication

Passez à la vue dossiers pour créer des dossiers pour l’organisation et la sécurité. La sécurité peut être définie au niveau d’un dossier.

Dossiers de version

Visualiser la progression de la mise en sortie

La nouvelle vue de la progression de la mise en production vous donne des mises à jour en direct de la progression du déploiement et un accès en un clic à des détails supplémentaires. La nouvelle vue visualise le pipeline de mise en production, ce qui permet de comprendre plus facilement ce qui se passe et de faire ressortir les détails et actions appropriés à différentes étapes de la version.

Affichage du pipeline de mise en sortie

Pipeline, détails de la version et environnements

La vue du pipeline affiche les artefacts de la mise en sortie et les environnements dans lesquels elles seront déployées. La zone de publication fournit des détails sur la version, tels que le déclencheur de mise en sortie, les versions d’artefact et les balises.

Les environnements sont modélisés de manière à mieux comprendre leur état, ainsi que la progression détaillée. À tout moment, vous pouvez accéder aux journaux en cliquant sur le lien d’État au sein de l’environnement.

Environnements

Pré-déploiement et après le déploiement

Si des conditions de pré-déploiement ou de prédéploiement ont été définies pour un environnement, elles sont indiquées dans l’environnement avec la présence des approbations et des portes. La progression des approbations et des portes apparaît également dans l’état de l’environnement. Vous pouvez effectuer une action ou afficher plus de détails en cliquant sur l’icône de condition de l’environnement en vous débloquant du côté droit ou gauche de l’environnement.

Lancer des actions d’environnement

Validations et éléments de travail

Avec chaque nouvelle version, vous pouvez afficher la liste des validations et des éléments de travail associés pour chaque environnement séparément en cliquant sur l’environnement. Si la liste est longue, utilisez des filtres pour rechercher une validation ou un élément de travail qui vous intéresse.

Validations et éléments de travail des versions

Progression et journaux de déploiement

Les environnements affichent des mises à jour en direct pour les déploiements en cours, y compris le nombre de phases et de tâches qui sont terminées et le temps d’exécution. Cliquez sur l’état de l’environnement pour ouvrir une vue contenant les journaux, en vous concentrant sur les éléments actuellement actifs.

Vous pouvez cliquer dans les journaux pour entrer dans une vue ciblée.

Détails du journal de mise en version

Impact de la mise à niveau vers Azure DevOps Server 2019 sur les tâches : copie des fichiers de l’ordinateur Windows et powershell sur l’ordinateur cible

Les groupes de machines sous le Hub test ont été dépréciés dans TFS 2017 RTM. avec Azure DevOps Server 2019, le service groupes de machines n’est plus disponible. cela aura un impact sur les utilisateurs de la tâche « copie de fichiers de l’ordinateur Windows », version 1. * et « PowerShell sur les Machines cibles », version 1. *. Pour que vos pipelines continuent de fonctionner,

  • vous devez basculer vers la tâche « copie de fichiers de l’ordinateur Windows » version 2. * et fournir le nom de domaine complet de l’ordinateur cible au lieu de simplement le nom de l’ordinateur.
  • et basculer vers la tâche « Powershell sur l’ordinateur cible » version 2. * ou version ultérieure et fournir le nom de domaine complet du nom de l’ordinateur ou de l’ordinateur, suivi des ports Windows Remote Management (http/https). Par exemple, targetMachine : 5985 ou targetMachine : 5986

Résultats des tests et extensibilité

Les résultats de l’exécution des tests sont également exposés pour chaque environnement. Cliquer sur les résultats des tests ouvre une vue contenant les détails des tests, y compris les résultats des autres extensions qui contribuent au processus.

Résultats des tests de version

Les extensions existantes fonctionnent dans cette nouvelle vue, plus il existe de nouveaux points d’extensibilité pour permettre aux extensions de se développer pour afficher davantage d’informations pour un environnement. Pour plus d’informations, consultez la documentation sur les contributions et les extensions .

Configurer des builds à l’aide de YAML

Les pipelines de build basés sur YAML sont disponibles dans votre Azure DevOps Server. Automatisez votre pipeline d’intégration continue à l’aide d’un fichier YAML archivé dans votre référentiel. Une référence complète pour le schéma YAML est disponible ici.

Pour prendre en charge les pipelines de génération YAML de manière plus transparente, nous avons modifié le comportement par défaut pour toutes les nouvelles ressources que vous créez (par exemple, connexions de service, groupes de variables, pools d’agents et fichiers sécurisés) pour être utilisables dans tous les pipelines de ce projet. Si vous souhaitez disposer d’un contrôle plus étroit sur vos ressources, vous pouvez désactiver le modèle d’autorisation par défaut (voir la figure ci-dessous). Dans ce cas, une personne disposant des autorisations nécessaires pour utiliser la ressource doit enregistrer explicitement le pipeline dans l’éditeur Web après l’ajout d’une référence de ressource au fichier YAML.

YAML

Les produits de grande taille ont plusieurs composants qui dépendent les uns des autres. Ces composants sont souvent générés de manière indépendante. Lorsqu’un composant en amont (une bibliothèque, par exemple) change, les dépendances en aval doivent être reconstruites et revalidées. Teams généralement gérer ces dépendances manuellement.

À présent, vous pouvez déclencher une build à la fin de la réussite d’une autre Build. les Artifacts générées par une build en amont peuvent être téléchargées et utilisées dans la génération ultérieure, et vous pouvez également récupérer des données à partir de ces variables : build. TriggeredBy. BuildId, build. TriggeredBy. dotée definitionid, build. TriggeredBy. BuildDefinitionName. Pour plus d’informations, consultez la documentation sur les déclencheurs de build .

Configurer le chaînage de build

Gardez à l’esprit que dans certains cas, une seule Build à plusieurs phases peut répondre à vos besoins. Toutefois, un déclencheur d’achèvement de build est utile si vos exigences incluent des paramètres de configuration différents, des options ou une équipe différente pour détenir le processus dépendant.

Mettre à jour votre agent localement

Les tâches que vous installez à partir de la Galerie requièrent parfois une version plus récente de l’agent des pipelines. si votre Azure DevOps Server peut se connecter à internet, les versions plus récentes sont téléchargées automatiquement. Si ce n’est pas le cas, vous devez mettre à niveau manuellement chaque agent. à partir de cette version, vous pouvez configurer votre Azure DevOps Server pour rechercher les fichiers de package de l’agent sur son disque local plutôt qu’à partir d’internet. vous bénéficiez ainsi d’une flexibilité et d’un contrôle sur les versions d’agent que vous rendez disponibles, sans avoir à exposer votre Azure DevOps Server sur internet.

URL du badge du nouvel état de la Build

Les badges de build incorporés dans la page d’accueil d’un référentiel sont un moyen courant d’afficher l’intégrité du référentiel. Même si nous avions des badges de build jusqu’à présent, il y a eu quelques problèmes :

  • L’URL n’était pas intuitive
  • Le badge n’est pas spécifique à une branche
  • Il n’existait aucun moyen pour un utilisateur de cliquer sur le badge pour faire passer l’utilisateur à la build la plus récente de cette définition

Nous déployons maintenant une nouvelle API pour les badges de build qui résout ces problèmes. La nouvelle API permet aux utilisateurs de publier un État par succursale et peut faire passer les utilisateurs à la build la plus récente de la branche sélectionnée. Vous pouvez obtenir la démarque pour la nouvelle URL de badge d’État en sélectionnant l’action de menu de badge d’État dans la page nouvelles Builds.

Pour assurer la compatibilité descendante, nous continuerons à honorer également les anciennes URL de badge de génération.

Ajouter des compteurs de build personnalisés à vos builds

Les compteurs de build offrent un moyen de numéroter et d’étiqueter les builds de manière unique. Auparavant, vous pouviez utiliser la variable spéciale $ (Rev : r) pour y parvenir. Vous pouvez maintenant définir vos propres variables de compteur dans votre définition de build qui sont incrémentées automatiquement chaque fois que vous exécutez une build. Pour ce faire, utilisez l’onglet variables d’une définition. Cette nouvelle fonctionnalité vous offre davantage de puissance des manières suivantes :

  • Vous pouvez définir un compteur personnalisé et définir sa valeur de départ. Par exemple, vous pouvez démarrer votre compteur à 100. $ (Rev : r) commence toujours à 0.
  • Vous pouvez utiliser votre propre logique personnalisée pour réinitialiser un compteur. $ (Rev : r) est lié à la génération du numéro de build et est réinitialisé automatiquement à chaque fois qu’un nouveau préfixe est présent dans le numéro de Build.
  • Vous pouvez définir plusieurs compteurs par définition.
  • Vous pouvez interroger la valeur d’un compteur en dehors d’une build. Par exemple, vous pouvez compter le nombre de builds qui ont été exécutées depuis la dernière réinitialisation à l’aide d’un compteur.

Pour plus d’informations sur les compteurs de génération, consultez la documentation sur les variables définies par l’utilisateur.

Azure Policy les validations de conformité et de sécurité dans Pipelines

Nous souhaitons garantir la stabilité et la sécurité des logiciels tôt dans le processus de développement tout en réunissant le développement, la sécurité et les opérations. Pour ce faire, nous avons ajouté la prise en charge de Azure Policy.

Azure Policy permet de gérer et d’éviter des problèmes informatiques avec des définitions de stratégies qui appliquent des règles et des effets pour vos ressources. Lorsque vous utilisez Azure Policy, les ressources restent conformes à vos normes d’entreprise et contrats de niveau de service.

Pour se conformer aux instructions de conformité et de sécurité dans le cadre du processus de mise en route, nous avons amélioré notre expérience de déploiement de groupe de ressources Azure. À présent, la tâche de déploiement du groupe de ressources Azure échoue avec les erreurs associées à la stratégie en cas de violation lors du déploiement de modèles ARM.

Azure Policy

En outre, nous avons ajouté Azure Policy modèle de définition de mise en version. Cela permet aux utilisateurs de créer des stratégies Azure et de leur attribuer des ressources, des abonnements ou des groupes d’administration à partir de la définition de mise en version elle-même.

Modèle de Azure Policy

créez sur des plateformes Linux/ARM et Windows 32 bits

l' agent multiplateforme Azure Pipelines open source a toujours été pris en charge sur 64 bits (x64) Windows, macOS et Linux. avec cette version, nous introduisons deux nouvelles plateformes prises en charge : Linux/ARM et Windows/32-bit. Ces nouvelles plateformes vous permettent de créer des plateformes moins courantes, mais pas moins importantes, telles que Raspberry pi, un ordinateur Linux/ARM.

Expériences améliorées pour les tests dans Pipelines

L' onglet tests a maintenant une expérience moderne qui vous offre des informations de test riches et contextuelles pour pipelines. La nouvelle expérience fournit une vue de test en cours, une expérience de débogage de page complète, un historique de test de contexte, un rapport d’exécution de tests abandonné et un résumé de niveau d’exécution.

Nouveau hub test

Afficher l’exécution des tests en cours

Les tests, tels que les tests d’intégration et les tests fonctionnels, peuvent s’exécuter pendant une longue période. il est donc important de voir l’exécution des tests à un moment donné. Avec le Affichage des tests In-Progress, vous n’avez plus besoin d’attendre la fin de l’exécution du test pour connaître le résultat du test. Les résultats sont disponibles quasiment en temps réel à mesure qu’ils sont exécutés, ce qui vous permet de prendre des mesures plus rapidement. Vous pouvez déboguer un échec ou un abandon, signaler un bogue ou abandonner le pipeline. La fonctionnalité est actuellement disponible pour le pipeline de build et de mise en version à l’aide de la tâche de test Visual Studio dans la phase multi-agent, à l’aide de publier résultats des tests tâche ou de publier les résultats des tests à l’aide des API. À l’avenir, nous prévoyons d’étendre cette expérience pour l’exécution des tests à l’aide d’un seul agent.

La vue ci-dessous montre le In-Progress Résumé du test dans la nouvelle vue de la progression de la mise en sortie, rapportant le nombre total de tests et le nombre d’échecs de test à un moment donné.

Affichage des tests en cours

En cliquant sur le résumé de test In-Progress ci-dessus, vous pouvez afficher le résumé du test détaillé, ainsi que les informations de test ayant échoué ou abandonnées dans test plans. Le résumé de test est actualisé à intervalles réguliers avec la possibilité d’actualiser la vue détaillée à la demande, en fonction de la disponibilité de nouveaux résultats.

Résumé du test détaillé

Afficher les détails du débogage de la série de tests dans la page complète

Les messages d’erreur et les traces de la pile sont de longue durée et doivent avoir suffisamment d’espace pour afficher les détails durant le débogage. Pour bénéficier d’une expérience de débogage immersive, vous pouvez maintenant développer la vue test ou série de tests en mode page entière, tout en étant en mesure d’effectuer les opérations de contexte requises, telles que la création de bogues ou l’Association d’exigences pour le résultat de test actuel.

Débogage de page complète

Afficher l’historique des tests dans le contexte

Historiquement, les équipes doivent aller à exécuter Hub pour afficher l’historique d’un résultat de test. avec la nouvelle expérience, nous intégrons l’historique des tests dans le contexte de Test Plans onglet pour la génération et la mise en place. Les informations de l’historique des tests sont fournies de manière progressive à partir de la définition ou de l’environnement de build actuel pour le test sélectionné, puis d’autres branches et environnements pour la build et la mise en publication, respectivement.

Historique des tests dans le contexte

Afficher les tests abandonnés

L’exécution des tests peut être abandonnée en raison de plusieurs raisons, telles que le code de test incorrect, la source testée et les problèmes environnementaux. Quelle que soit la raison de l’abandon, il est important que vous diagnostiquez le comportement et identifiiez la cause racine. Vous pouvez maintenant afficher les tests et les séries de tests abandonnés, en plus des exécutions terminées dans test plans. La fonctionnalité est actuellement disponible pour le pipeline de build et de mise en version à l’aide de la tâche de test Visual Studio dans la phase multi-agent ou de la publication des résultats des tests à l’aide d’API. À l’avenir, nous prévoyons d’étendre cette expérience pour l’exécution des tests à l’aide d’un seul agent.

Afficher les tests abandonnés

Suivi des tests et prise en charge des environnements de mise en service dans l’historique des tests

Nous ajoutons la prise en charge de l’affichage de l’historique d’un test automatisé groupé par différents environnements de version dans lesquels le test est exécuté. Si vous modélisez des environnements de version comme des pipelines de mise en service ou des environnements de test, et que vous exécutez des tests sur ces environnements, vous pouvez déterminer si un test réussit dans l’environnement de développement, mais échoue dans l’environnement d’intégration. Vous pouvez déterminer si elle transmet les paramètres régionaux anglais, mais échouer dans un environnement qui a des paramètres régionaux turcs. Pour chaque environnement, vous trouverez l’état du dernier résultat de test et, si le test a échoué sur cet environnement, vous trouverez également la mise en sortie depuis laquelle le test a échoué.

Examiner les résultats de test résumés

Pendant l’exécution des tests, un test peut générer plusieurs instances de tests qui contribuent au résultat global. Voici quelques exemples : les tests qui sont réexécutés en raison de défaillances, les tests composés d’une combinaison ordonnée d’autres tests (par exemple, test ordonné) ou les tests ayant des instances différentes selon le paramètre d’entrée fourni (tests pilotés par les données). Étant donné que ces tests sont liés, ils doivent être signalés avec le résultat global dérivé en fonction des résultats des tests individuels. Avec cette mise à jour, nous introduisons une version améliorée des résultats des tests présentée sous la forme d’une hiérarchie sous l’onglet tests d’une version. Intéressons-nous à un exemple.

Précédemment, nous avons introduit la possibilité de réexécuter les tests ayant échoué dans la tâche de test vs . Toutefois, nous avons uniquement signalé la dernière tentative d’un test, ce qui limitait l’utilité de cette fonctionnalité. Nous avons maintenant étendu cette fonctionnalité pour signaler chaque instance de l’exécution du test en tant que tentative. En outre, l’API de gestion des tests prend désormais en charge la publication et l’interrogation des résultats de test hiérarchiques. Pour plus d’informations, consultez la documentation sur l' API des résultats des tests .

Résumé du test-débogage

Notes

Les métriques dans la section Résumé du test (par exemple, nombre total de tests, réussite, etc.) sont calculées à l’aide du niveau racine de la hiérarchie plutôt que de chaque itération individuelle des tests.

Afficher les analyses de test dans Pipelines

Le suivi de la qualité des tests dans le temps et l’amélioration de la documentation de test est essentiel à la maintenance d’un pipeline sain. La fonctionnalité d’analyse de test fournit une visibilité en temps quasi réel sur vos données de test pour les builds et les pipelines de mise en version. Cela permet d’améliorer l’efficacité de votre pipeline en identifiant les problèmes de qualité répétitive et à impact élevé.

Vous pouvez regrouper les résultats des tests en fonction de différents éléments, identifier des tests clés pour vos fichiers de branche ou de test, ou descendre dans la vue d’un test spécifique pour afficher des tendances et comprendre les problèmes de qualité tels que friabilité.

Afficher les analyses de test pour les Builds et les versions,aperçu ci-dessous :

Test d’analyse

Pour plus d’informations, consultez notre documentation.

Simplifier les définitions avec plusieurs tâches sans agent

Les tâches d’une phase sans agent sont orchestrées par et exécutées sur le serveur. Les phases sans agent ne nécessitent pas d’agent ou d’ordinateurs cibles. Contrairement aux phases de l’agent, une seule tâche peut être ajoutée à chaque phase sans agent dans les définitions. Cela signifiait que plusieurs phases devaient être ajoutées lorsqu’il existait plus d’une tâche sans agent dans le processus, ce qui a entraîné la mise en lots de la définition. Nous avons assouplir cette restriction, ce qui vous permet de gérer plusieurs tâches dans une phase sans agent. Les tâches de la même phase s’exécutent de manière séquentielle, comme c’est le cas pour les phases de l’agent. Pour plus d’informations, consultez la documentation sur les phases de serveur .

Exposer et déployer progressivement des phases à l’aide de portes de version

À l’aide des portes de publication, vous pouvez spécifier des critères d’intégrité d’application qui doivent être satisfaits avant qu’une version ne soit promue à l’environnement suivant. Toutes les passerelles spécifiées sont évaluées périodiquement avant ou après un déploiement, jusqu’à ce qu’elles soient toutes réussies. Quatre types de portes sont disponibles dès l’emploi et vous pouvez ajouter d’autres portails à partir de la place de marché. Vous pourrez vérifier que tous les critères nécessaires pour un déploiement ont été satisfaits. Pour plus d’informations, consultez la documentation relative aux portes de mise en production.

Panneau portes de sortie

Conserver les déploiements jusqu’à ce que les portes fonctionnent de manière cohérente

Les portes de publication activent l’évaluation automatique des critères d’intégrité avant qu’une version ne soit promue à l’environnement suivant. Par défaut, la version progresse après la réception d’un échantillon réussi pour toutes les portes. Même si une porte est irrégulière et que l’exemple de réussite reçu est le bruit, la version progresse. Pour éviter ces types de problèmes, vous pouvez maintenant configurer la version pour vérifier la cohérence de l’intégrité pendant une durée minimale avant la progression. Au moment de l’exécution, la mise en version garantira la réussite des évaluations consécutives des portes avant d’autoriser la promotion. La durée totale de l’évaluation dépend de l’intervalle de temps entre la réévaluation et il est généralement supérieur à la durée minimale configurée. Pour plus d’informations, consultez la documentation sur le contrôle de déploiement des versions à l’aide de portes .

Paramètre de conservation des portes

Déployer automatiquement sur les nouvelles cibles dans un groupe de déploiement

Auparavant, lorsque de nouvelles cibles étaient ajoutées à un groupe de déploiement, un déploiement manuel était nécessaire pour s’assurer que toutes les cibles ont la même version. Vous pouvez maintenant configurer l’environnement pour déployer automatiquement la dernière version réussie sur les nouvelles cibles. Pour plus d’informations, consultez la documentation sur les groupes de déploiement .

Groupes de déploiement

Déployer en continu des builds marquées par le traitement après génération

Les déclencheurs de déploiement continu créent une version à la fin de la génération. Toutefois, les builds sont parfois générées après traitement et la génération ne doit être libérée qu’une fois le traitement terminé. À présent, vous pouvez tirer parti des balises de build, qui seraient affectées pendant le traitement après le traitement, dans les filtres de déclenchement de la version.

déclencheur de balise de build

Définir une variable au moment de la mise en version

Dans une définition de version, vous pouvez maintenant choisir les variables que vous souhaitez définir lors de la création de la mise en sortie.

Variable de version

La valeur fournie pour la variable lors de la création de la mise en sortie est utilisée uniquement pour cette version. Cette fonctionnalité vous permet d’éviter plusieurs étapes de création de brouillon, de mettre à jour les variables dans draft et de déclencher la mise en version avec la variable.

Variable Release dans Release

Passer des variables d’environnement à des tâches

Les auteurs de tâches CI/CD peuvent définir une nouvelle propriété, showEnvironmentVariables, dans Task. JSON pour passer les variables d’environnement aux tâches. Dans ce cas, un contrôle supplémentaire est rendu sur la tâche dans l’éditeur de Build. Cela est possible pour les tâches PowerShell, cmd et bash .

Variables d’environnement Pass

Cela permet deux scénarios :

  • Une tâche requiert une variable d’environnement dont le nom de variable conserve la casse. Par exemple, dans l’exemple ci-dessus, la variable d’environnement transmise à la tâche est « foo » et non « FOO ».
  • Cela permet de transmettre des valeurs secrètes de manière sécurisée aux scripts. Il est préférable de passer les secrets comme arguments aux scripts, car le système d’exploitation de l’agent peut se connecter à l’invocation des processus, y compris leurs arguments.

Cloner des groupes de variables

Nous avons ajouté la prise en charge du clonage des groupes de variables. Chaque fois que vous souhaitez répliquer un groupe de variables et simplement mettre à jour quelques-unes des variables, vous n’avez pas besoin de suivre le processus fastidieux d’ajout de variables un par un. Vous pouvez maintenant créer rapidement une copie de votre groupe de variables, mettre à jour les valeurs de manière appropriée et l’enregistrer en tant que nouveau groupe de variables.

Cloner le groupe de variables

Notes

Les valeurs des variables secrètes ne sont pas copiées lorsque vous clonez un groupe de variables. Vous devez mettre à jour les variables chiffrées, puis enregistrer le groupe de variables clonées.

Ignorer une porte de version pour un déploiement

Les portes de publication activent l’évaluation automatique des critères d’intégrité avant qu’une version ne soit promue à l’environnement suivant. Par défaut, le pipeline de mise en version progresse uniquement lorsque toutes les portes sont saines en même temps. Dans certaines situations, par exemple lors de l’expédition d’une version ou après la vérification manuelle de l’intégrité, un approbateur peut vouloir ignorer une porte et autoriser la progression de la mise en sortie même si cette porte n’a pas encore été évaluée comme saine. La documentation sur les portes de version pour plus d’informations.

Ignorer les portes

Effectuer des tests supplémentaires à l’aide d’un déclencheur de version de requête de tirage

Vous avez pu déclencher une build basée sur une demande de tirage (pull request) et obtenir ces commentaires rapides avant une fusion pendant un certain temps. Vous pouvez maintenant configurer un déclencheur PR pour une version. L’état de la mise en version sera publié dans le référentiel de code et peut être consulté directement sur la page PR. Cela est utile si vous souhaitez effectuer des tests fonctionnels ou manuels supplémentaires dans le cadre de votre flux de travail de demande de tirage.

Déclencheur PR dans la version

Créer une connexion de service Azure avec un principal de service qui s’authentifie avec un certificat

Vous pouvez maintenant définir une connexion de service Azure avec un principal de service et un certificat pour l’authentification. Avec la connexion au service Azure prenant en charge le principal du service qui s’authentifie avec un certificat, vous pouvez maintenant déployer sur Azure Stack configuré avec AD FS. Pour créer un principal de service avec l’authentification par certificat, reportez-vous à l’article sur la création d’un principal de service qui s’authentifie avec un certificat.

Se connecter avec le principal de service

Exécuter à partir du package pris en charge dans les déploiements Azure App Service

La version de la tâche de déploiement Azure App Service (4. *) prend désormais en charge RunFromPackage (précédemment appelée RunFromZip.

App Service prend en charge un certain nombre de techniques différentes pour déployer vos fichiers, tels que MSDeploy (par exemple, WebDeploy), git, ARM et bien plus encore. Mais toutes ces techniques sont limitées. Vos fichiers sont déployés sous votre dossier Wwwroot (plus précisément d:\home\site\wwwroot) et le runtime exécute ensuite les fichiers à partir de là.

Avec l’exécution à partir du package, il n’y a plus d’étape de déploiement qui copie les fichiers individuels sur wwwroot. Au lieu de cela, il suffit de le pointer vers un fichier zip et le zip est monté sur wwwroot en tant que système de fichiers en lecture seule. Cela a plusieurs avantages :

  • Réduction des risques de verrouillage lors de la copie de fichiers
  • Déploiement possible sur une application de production (après redémarrage)
  • Connaissance des fichiers qui sont exécutés dans votre application
  • Améliore les performances des déploiements de Azure App Service.
  • Peut réduire les temps de démarrage à froid, en particulier pour les fonctions JavaScript avec des arborescences de package npm de grande taille.

Déployer des conteneurs Linux avec la tâche de déploiement du serveur d’applications

La version 4. * de la tâche de déploiement Azure App Service prend désormais en charge le déploiement de votre propre conteneur personnalisé sur Azure Functions sur Linux.

Le modèle d’hébergement Linux pour Azure Functions est basé sur des conteneurs d’ancrage qui offrent une plus grande flexibilité en termes de Packaging et d’exploitation des dépendances spécifiques aux applications. Les fonctions sur Linux peuvent être hébergées dans 2 modes différents :

  1. Image de conteneur intégrée : Vous mettez le code Function App et Azure fournit et gère le conteneur (mode d’image intégré), de sorte qu’aucune connaissance spécifique de l’ancre n’est requise. Cela est pris en charge dans la version existante de App Service tâche de déploiement.
  2. Image de conteneur personnalisée : Nous avons amélioré la tâche de déploiement App Service pour prendre en charge le déploiement d’images de conteneur personnalisées sur Azure Functions sur Linux. Lorsque vos fonctions nécessitent une version de langage spécifique ou nécessitent une dépendance ou une configuration spécifique qui n’est pas fournie dans l’image intégrée, vous pouvez créer et déployer une image personnalisée vers Azure Function sur Linux à l’aide de Azure Pipelines.

La tâche Xcode prend en charge les nouvelles versions de Xcode 10

Coïncidant avec la sortie d’Apple de Xcode 10, vous pouvez maintenant définir vos projets pour qu’ils soient générés ou testés spécifiquement avec Xcode 10. Votre pipeline peut également exécuter des tâches en parallèle avec une matrice de versions de Xcode. Vous pouvez utiliser le pool d’agents macOS hébergé par Microsoft pour exécuter ces builds. Consultez les conseils relatifs à l’utilisation de Xcode dans Azure pipelines.

Xcode 10

Rationalisation du déploiement sur Kubernetes à l’aide de Helm

Helm est un outil qui simplifie l’installation et la gestion des applications Kubernetes. Elle a également acquis une grande popularité et un support de la Communauté au cours de l’année dernière. Une tâche Helm dans Release est désormais disponible pour l’empaquetage et le déploiement de graphiques Helm vers Azure Container Service (AKS) ou tout autre cluster Kubernetes.

Grâce à l’ajout de cette tâche Helm, vous pouvez désormais configurer un pipeline CI/CD Helm pour la livraison de conteneurs dans un cluster Kubernetes. Pour plus d’informations, consultez la documentation déployer à l’aide de Kubernetes pour Azure Container Service .

tâches Helm

Contrôler la version de Helm utilisée dans la mise en version

La tâche du programme d’installation de l' outil Helm acquiert une version spécifique de Helm à partir d’Internet ou du cache d’outils, puis l’ajoute au chemin d’accès de l’agent (hébergé ou privé). Utilisez cette tâche pour modifier la version de Helm utilisée dans les tâches suivantes, telles que la tâche CLI .net Core . L’ajout de cette tâche avant la tâche de déploiement Helm dans une définition de build ou de mise en version vous garantit que vous empaquetez et déployez votre application avec la version Helm appropriée. Cette tâche permet également d’installer l’outil kubectl , qui est une condition préalable à l’utilisation de Helm.

Déploiement en continu sur Azure Database pour MySQL

Vous pouvez maintenant effectuer un déploiement en continu sur Azure Database pour MySQL -base de données MySQL en tant que service Azure. Gérez vos fichiers de script MySQL dans le contrôle de version et déployez en continu dans le cadre d’un pipeline de mise en version à l’aide d’une tâche Native plutôt que de scripts PowerShell.

utiliser des tâches Windows PowerShell à distance améliorées

des tâches basées sur PowerShell nouvelles et améliorées Windows sont disponibles. Ces améliorations incluent plusieurs correctifs de performances et prennent en charge les journaux en temps réel et les commandes de sortie de console, telles que Write-Host et Write-Output.

PowerShell sur la tâche cible (version : 3. *): vous pouvez ajouter un script inline, modifier les options PSSession, contrôler « ErrorActionPreference » et basculer en cas d’erreur standard.

tâche de copie de fichiers Azure (version : 2. *): est fourni avec la dernière version de AzCopy (v 7.1.0) qui résout un problème GitHub.

filtrer les branches pour GitHub Enterprise ou les artefacts Git externes

lors de la publication à partir de GitHub Enterprise ou des dépôts Git externes, vous pouvez maintenant configurer les branches spécifiques qui seront publiées. Par exemple, vous souhaiterez peut-être déployer uniquement les builds provenant d’une branche spécifique en production.

filtres de branche

Créer des applications écrites en Go

Utilisez la tâche installer l’outil Go pour installer une ou plusieurs versions de l’outil Go à la volée. Cette tâche acquiert une version spécifique de l’outil Go nécessaire à votre projet et l’ajoute au chemin d’accès de l’agent de Build. Si la version de l’outil Go cible est déjà installée sur l’agent, cette tâche ignore le processus de téléchargement et d’installation.

La tâche atteindre vous aide à télécharger des dépendances, générer ou tester votre application. Vous pouvez également utiliser cette tâche pour exécuter une commande Go personnalisée de votre choix.

Exécuter des scripts Python en ligne ou basés sur des fichiers dans votre pipeline

Une nouvelle tâche de script Python simplifie l’exécution de scripts Python dans votre pipeline. La tâche exécute un script à partir d’un fichier Python (. py) dans votre référentiel, ou vous pouvez entrer manuellement un script dans les paramètres de la tâche, pour l’enregistrer dans le cadre de votre pipeline. La tâche utilisera la version de Python dans le chemin d’accès, ou vous pouvez spécifier un chemin d’accès absolu à un interpréteur Python à utiliser.

Tirez parti de la génération et des tests de sortie Xcode améliorés de xcpretty

xcpretty améliore la lisibilité de la sortie xcodebuild et génère des résultats de test au format JUnit. La tâche de génération Xcode utilise désormais automatiquement xcpretty lorsqu’elle est disponible sur l’ordinateur agent, comme c’est le cas sur les agents macOS hébergés. Bien que la sortie xcpretty puisse être différente et moins détaillée que la sortie xcodebuild, nous mettons à disposition les journaux xcodebuild complets avec chaque Build.

Test Plans

client Test Runner (Azure Test Plans) pour exécuter des tests manuels pour les applications de bureau

vous pouvez maintenant utiliser le client Test Runner (Azure Test Plans) pour exécuter des tests manuels pour les applications de bureau. Cela vous permet de passer de Microsoft Test Manager à Azure Test Plans. Reportez-vous à nos conseils ici. À l’aide du client test Runner, vous pouvez exécuter vos tests manuels et enregistrer les résultats des tests pour chaque étape de test. Vous disposez également de fonctionnalités de collecte de données telles que la capture d’écran, le journal des actions d’image et l’enregistrement vidéo audio. Si vous rencontrez un problème lors du test, utilisez Test Runner pour créer un bogue avec des étapes de test, des captures d’écran et des commentaires automatiquement inclus dans le bogue.

Test runner (Azure Test Plans) requiert un téléchargement et une installation à usage unique du testeur. Sélectionnez exécuter pour l’application de bureau , comme indiqué ci-dessous.

Azure Test Runner

Azure Test Runner installer

Artifacts

Sources amont

Azure DevOps Server 2019 apporte des mises à jour importantes aux sources amont disponibles sur vos flux de Azure Artifacts :

  • Vous pouvez ajouter des sources amont NuGet.org aux flux existants créés dans les versions précédentes de TFS. Recherchez la bannière au-dessus des packages de votre flux pour plus d’informations, y compris les changements de comportement que vous devez connaître avant de procéder à la mise à niveau.
  • vous pouvez ajouter d’autres flux Azure DevOps Server en tant que sources amont à votre flux, ce qui signifie que vous pouvez utiliser des packages NuGet et npm à partir de ces flux dans votre flux.

nous avons également introduit un nouveau rôle dans Azure Artifacts : « collaborateur ». Un collaborateur peut enregistrer des packages à partir d’une source amont, mais ne peut pas publier des packages de packages directement dans le flux (par exemple, à l’aide de la publication NuGet). Cela vous permet de limiter la publication du package à un utilisateur approuvé ou au système de génération tout en permettant à vos ingénieurs d’utiliser de nouveaux packages à partir de vos sources amont.

Suivre les packages

Nous avons encore plus facile de configurer des notifications avec un nouveau bouton suivant directement sur chaque package. Le bouton suivant est également compatible avec les affichages de mise en sortie. Si vous suivez un package lors de sa consultation par le biais d’une vue, vous obtiendrez uniquement des mises à jour pour les nouvelles versions qui sont promues à cette vue.

Modifier les paramètres de flux sans avoir à enregistrer manuellement

Quelques interactions sur la page Paramètres de flux ont été améliorées. Désormais, les modifications que vous apportez, telles que l’ajout d’une autorisation en amont ou en aval, sont enregistrées immédiatement. Cela signifie que vous n’avez pas à vous soucier de perdre des modifications lorsque vous basculez entre des pivots de paramètres.

Simplifiez l'authentification à l'aide du nouveau fournisseur d’informations d’identification multiplateforme de NuGet

l’interaction avec les flux d’NuGet authentifiés vient d’être beaucoup mieux. le nouveau fournisseur d’informations d’identification de Azure Artifacts basé sur .net Core fonctionne avec msbuild, dotnet et nuget (.exe) sur Windows, macOS et Linux. chaque fois que vous souhaitez utiliser des packages à partir d’un flux Azure Artifacts, le fournisseur d’informations d’identification acquière et stocke automatiquement un jeton pour le compte du client NuGet que vous utilisez. Vous n’avez plus besoin de stocker et de gérer manuellement un jeton dans un fichier de configuration.

pour obtenir le nouveau fournisseur, accédez à GitHub et suivez les instructions pour votre client et votre plateforme.

Compressez les symboles lors de la publication sur un partage de fichiers

Nous avons mis à jour l' Index & tâche publier les symboles pour prendre en charge la compression des symboles lorsqu’ils sont publiés sur un partage de fichiers.

Compresser les symboles

Wiki

Publier des fichiers de démarque à partir d’un dépôt git en tant que wiki

Les développeurs créent une documentation pour les « API », les « SDK » et les documents d’aide expliquant le code dans les référentiels de code. Les lecteurs doivent ensuite passer en revue le code pour trouver la documentation appropriée. À présent, vous pouvez simplement publier des fichiers de démarque à partir de référentiels de code et les héberger dans le wiki.

action du code public en tant que wiki

Dans le wiki, commencez par cliquer sur publier le code en tant que wiki. Ensuite, vous pouvez spécifier un dossier dans un dépôt git qui doit être promu.

boîte de dialogue publier des pages

Une fois que vous avez cliqué sur publier, tous les fichiers de démarque dans le dossier sélectionné seront publiés en tant que wiki. Cela permet également de mapper le en-tête de la branche sur le wiki afin que toutes les modifications apportées au référentiel git soient reflétées immédiatement.

Pour plus d’informations, consultez le billet de blog sur la documentation du produit .

Vous pouvez maintenant cliquer sur l’icône de lien en regard de n’importe quel en-tête de section dans une page wiki pour générer une URL directement dans cette section. Vous pouvez ensuite copier cette URL et la partager avec les membres de l’équipe pour les lier directement à cette section. Cette fonctionnalité a été rendue prioritaire à la suite d’une suggestion.

URL de titre de wiki

Joindre des fichiers et des images dans des dossiers

Lorsque vous modifiez des pages de wiki hors connexion, il peut être plus facile d’ajouter des images et des pièces jointes dans le même répertoire que la page wiki. À présent, vous pouvez ajouter une pièce jointe ou une image dans n’importe quel dossier du wiki et la lier à votre page. Cette fonctionnalité a été rendue prioritaire à la suite d’une suggestion.

Image wiki dans le dossier git référentiel

Intégrez une vidéo dans un wiki

Vous pouvez désormais incorporer des vidéos dans une page wiki à partir de services en ligne telles que Microsoft Stream et YouTube. Vous pouvez ajouter l’URL de la vidéo incorporée à l’aide de la syntaxe suivante :

::: video
<iframe width="560" height="315" src="https://www.youtube.com/embed/7DbslbKsQSk" frameborder="0" allow="autoplay; encrypted-media" allowfullscreen></iframe>
:::

Incorporer une vidéo dans le wiki

Renommez un wiki

Vous pouvez maintenant renommer votre wiki dans l’interface utilisateur du wiki et utiliser les API REST. Dans le menu plus , cliquez sur Renommer le wiki pour attribuer à votre wiki un nom mémorable.

Renommer le wiki

Ouvrir la page dans un nouvel onglet

Vous pouvez maintenant cliquer avec le bouton droit sur une page wiki et l’ouvrir dans un nouvel onglet ou appuyer simplement sur CTRL + gauche sur une page wiki pour l’ouvrir dans un nouvel onglet.

Onglet nouveau wiki

Conserver les caractères spéciaux dans les titres des pages wiki

Vous pouvez maintenant créer des pages wiki avec des caractères spéciaux tels que : < > * ? | - . À présent, les pages avec des titres tels que « FAQ ? » ou « Guide de configuration » peut être créé dans le wiki. Les caractères suivants sont convertis en chaînes encodées en UTF-8 :

Caractère Chaîne encodée
: %3A
< %3C
> %3E
* %2A
? %3F
| %7C
- % 2D

Tous les liens d’un wiki qui ne sont pas correctement liés s’affichent dans une icône de couleur rouge et de lien rompu, ce qui vous donne un indice visuel de tous les liens rompus dans une page wiki.

Liens rompus du wiki

Les liens de pages rompus constituent l’une des principales causes de mauvaise qualité de page dans une solution de documentation. Précédemment dans le wiki, lorsque vous avez déplacé une page dans l’arborescence ou renommé une page, cela peut éventuellement rompre des liens vers la page à partir d’autres pages et éléments de travail. À présent, vous pouvez vérifier et corriger les liens avant qu’ils ne soient rompus.

Important

N’oubliez pas d’utiliser la []() syntaxe de démarque pour les liens dans les pages et le type de lien page wiki dans éléments de travail pour permettre au wiki de rechercher et de corriger ces liens potentiellement rompus. Les URL en texte brut et les liens hypertexte dans les éléments de travail ne sont pas sélectionnés par cette fonctionnalité.

Lorsque vous renommez ou déplacez une page, vous êtes invité à vérifier les liens absolus ou relatifs.

Boîte de dialogue déplacer la page

Vous verrez ensuite une liste des liens de page et des éléments de travail affectés avant d’agir.

Déplacer les liens de page

Créer une table des matières pour les pages wiki

Parfois, les pages de wiki peuvent être longues, avec un contenu organisé en plusieurs en-têtes. Vous pouvez maintenant ajouter une table des matières à une page qui a au moins un titre à l’aide de la [[_TOC_]] syntaxe.

Table des matières wiki

Vous pouvez également insérer une table des matières en cliquant sur le bouton approprié dans le volet format lors de la modification de la page.

Insérer une table des wiki

Pour plus d’informations sur l’utilisation de la démarque dans Azure DevOps, consultez la documentation du Guide de la marque .

Métadonnées de surface pour les pages wiki et l’aperçu du code à l’aide de balises YAML

L’ajout de métadonnées à la documentation peut aider les lecteurs et les index de recherche à récupérer du contenu pertinent. Dans cette mise à jour, tout fichier qui contient un bloc YAML au début du fichier est transformé en une table de métadonnées d’une tête et d’une ligne. Le bloc YAML doit prendre la forme d’un jeu de YAML valides entre les lignes en pointillés. Il prend en charge tous les types de données de base, liste et objet comme valeur. La syntaxe est prise en charge dans le wiki et l’aperçu du fichier de code.

Exemple de balises YAML :

---
tag: post
title: Hello world
---

Table YAML

Exemple de balises YAML avec List :

---
tags:
- post
- code
- web
title: Hello world
---

Table YAML avec liste

Publier du code en tant que wiki avec les autorisations collaboration

Auparavant, seuls les utilisateurs disposant de l’autorisation Create Repository sur un référentiel git étaient en mesure de publier du code en tant que wiki. Ainsi, les administrateurs de référentiel ou les créateurs ont créé un goulot d’étranglement pour toutes les demandes de publication de fichiers de démarque hébergés dans des dépôts Git en tant que wikis. À présent, vous pouvez publier du code en tant que wiki si vous avez simplement l' autorisation collaboration sur le dépôt de code.

Signalement

L’extension de la place de marché Analytics pour la création de rapports est désormais disponible

L' extension Analytics Marketplace est désormais disponible pour Azure DevOps Server. l’analyse est le futur de la création de rapports pour les Azure DevOps et les Azure DevOps Server. l’installation de l’extension Analytics fournit des widgets avancés, l' intégration de Power BIet l' accès OData.

Pour plus d’informations, consultez qu’est-ce qu’Analytics et le Guide de création de rapports. Analytics est en version préliminaire publique. il contient actuellement des données pour Boards et les résultats des tests automatisés via Pipelines. Consultez données disponibles dans le service d’analyse.

Examiner l’historique de génération à l’aide d’un widget nouveau tableau de bord de build

Nous avons un nouveau widget d’historique de build amélioré que vous pouvez ajouter à vos tableaux de bord. Avec ce widget, vous pouvez désormais afficher un historique des builds à partir d’une branche spécifique de votre tableau de bord et la configurer sur un projet public pour les visiteurs anonymes.

Important

Si vous recherchez des informations sur vos builds XAML, continuez à utiliser l’ancien widget et découvrez comment migrer des builds XAML vers de nouvelles builds. Dans le cas contraire, nous vous recommandons de passer au widget plus récent.


Commentaires

Nous aimerions connaître votre opinion ! vous pouvez signaler un problème ou fournir une idée et le suivre par le biais des Community de développement et obtenir des conseils sur Stack Overflow.


Haut de page