Notes de publication Azure DevOps Server 2019

Communauté des développeursConfiguration système requiseConditions de licenceBlog DevOpsHachages SHA-1

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

Pour en savoir plus sur l’installation ou la mise à niveau d’un déploiement Azure DevOps Server, consultez Configuration requise pour Azure DevOps Server. Pour télécharger des produits Azure DevOps, consultez la page Téléchargements du serveur Azure DevOps.

La mise à niveau directe vers Azure DevOps Server est prise en charge à partir d’Azure DevOps Server 2020, Azure DevOps Server 2019 ou Team Foundation Server (TFS) 2015 ou version ultérieure. Si votre déploiement TFS se trouve sur TFS 2010 ou version antérieure, vous devez effectuer certaines étapes intermédiaires avant de procéder à la mise à niveau vers Azure DevOps Server 2019. Pour en savoir plus, consultez Installer et configurer Azure DevOps localement.

Mise à niveau sécurisée d’Azure DevOps Server 2019 vers Azure DevOps Server 2020

Azure DevOps Server 2020 introduit un nouveau modèle de rétention d’exécution de pipeline (build) qui fonctionne en fonction des paramètres au niveau du projet.

Azure DevOps Server 2020 gère la rétention des builds différemment, en fonction des stratégies de rétention au niveau du pipeline. Certaines configurations de politique entraînent la suppression des exécutions de pipeline après la mise à niveau. Les exécutions de pipeline qui ont été conservées manuellement ou qui sont conservées par une mise en production ne seront pas supprimées après la mise à niveau.

Lisez notre billet de blog pour plus d’informations sur la mise à niveau sécurisée d’Azure DevOps Server 2019 vers Azure DevOps Server 2020.

Date de publication d’Azure DevOps Server 2019.0.1 Patch 16 : 14 novembre 2023

Nous avons publié un correctif pour Azure DevOps Server 2019 Update 1.2 qui inclut des correctifs pour les éléments suivants.

• Extension de la liste des caractères autorisés pour les tâches PowerShell pour activer la validation des paramètres d’arguments des tâches de l’interpréteur de commandes.

Installer les correctifs

Configurer TFX

1. Suivez les étapes de la documentation sur le chargement des tâches dans la collection de projets pour installer et vous connecter à tfx-cli.

Mettre à jour les tâches avec TFX

1. Téléchargez et extrayez Tasks20231103.zip.
2. Accédez au répertoire des fichiers extraits.
3. Exécutez les commandes suivantes pour charger les tâches :

tfx build tasks upload --task-zip-path AzureFileCopyV1.1.230.0.zip
tfx build tasks upload --task-zip-path AzureFileCopyV2.2.230.0.zip 
tfx build tasks upload --task-zip-path AzureFileCopyV3.3.230.0.zip 
tfx build tasks upload --task-zip-path AzureFileCopyV4.4.230.0.zip 
tfx build tasks upload --task-zip-path AzureFileCopyV5.5.230.0.zip 
tfx build tasks upload --task-zip-path BashV3.3.226.2.zip 
tfx build tasks upload --task-zip-path BatchScriptV1.1.226.0.zip 
tfx build tasks upload --task-zip-path PowerShellV2.2.230.0.zip 
tfx build tasks upload --task-zip-path SSHV0.0.226.1.zip 
tfx build tasks upload --task-zip-path WindowsMachineFileCopyV1.1.230.0.zip 
tfx build tasks upload --task-zip-path WindowsMachineFileCopyV2.2.230.0.zip 

Exigences relatives au Pipeline

Pour utiliser le nouveau comportement, une variable AZP_75787_ENABLE_NEW_LOGIC = true doit être définie dans les pipelines qui utilisent les tâches affectées.

• Dans Classic :

  Définissez la variable dans l’onglet variable du pipeline.

• Exemple YAML :

variables: 
- name: AZP_75787_ENABLE_NEW_LOGIC 
  value: true 

Date de publication d’Azure DevOps Server 2019.0.1 Patch 15 : 12 septembre 2023

Nous avons publié un correctif pour Azure DevOps Server 2019.0.1 qui corrige ce qui suit.

• CVE-2023-33136 : Vulnérabilité d’exécution de code à distance d’Azure DevOps Server.
• CVE-2023-38155 : Vulnérabilité d’élévation de privilèges dans Azure DevOps Server et Team Foundation Server.

Installer les correctifs

1. Téléchargez et installez Azure DevOps Server 2019.0.1 Patch 15.

Mettre à jour l’agent Azure Pipelines

1. Téléchargez l’agent à partir de : https://github.com/microsoft/azure-pipelines-agent/releases/tag/v3.225.0 - Agent_20230825.zip
2. Utilisez les étapes décrites dans la documentation des agents Windows auto-hébergés pour déployer l’agent.  

Configurer TFX

1. Suivez les étapes de la documentation sur le téléversement de tâches vers la collection de projets pour installer et vous connecter à tfx-cli.

Mettre à jour les tâches à l’aide de TFX

1. Téléchargez et extrayez Tasks_20230825.zip.
2. Placez-vous dans le répertoire des fichiers extraits.
3. Exécutez les commandes suivantes pour charger les tâches :

tfx build tasks upload --task-zip-path AzureFileCopyV1.1.226.3.zip 
tfx build tasks upload --task-zip-path AzureFileCopyV2.2.226.2.zip 
tfx build tasks upload --task-zip-path AzureFileCopyV3.3.226.2.zip 
tfx build tasks upload --task-zip-path AzureFileCopyV4.4.226.2.zip 
tfx build tasks upload --task-zip-path AzureFileCopyV5.5.226.2.zip 
tfx build tasks upload --task-zip-path BashV3.3.226.2.zip 
tfx build tasks upload --task-zip-path BatchScriptV1.1.226.0.zip 
tfx build tasks upload --task-zip-path PowerShellV2.2.226.1.zip 
tfx build tasks upload --task-zip-path SSHV0.0.226.1.zip 
tfx build tasks upload --task-zip-path WindowsMachineFileCopyV1.1.226.2.zip 
tfx build tasks upload --task-zip-path WindowsMachineFileCopyV2.2.226.2.zip 

Exigences relatives aux pipelines

Pour utiliser le nouveau comportement, une variable AZP_75787_ENABLE_NEW_LOGIC = true doit être définie dans les pipelines qui utilisent les tâches affectées.

• Sur la version classique :

  Définissez la variable dans l’onglet variable du pipeline.

• Exemple YAML :

variables: 
- name: AZP_75787_ENABLE_NEW_LOGIC 
  value: true 

Date de publication d’Azure DevOps Server 2019.0.1 Patch 14 : 8 août 2022

Nous avons publié un correctif pour Azure DevOps Server 2019.0.1 qui corrige ce qui suit.

• CVE-2023-36869 : Vulnérabilité d’usurpation d’identité dans Azure DevOps Server.

Date de publication d’Azure DevOps Server 2019.0.1 Patch 13 : 17 mai 2022

Nous avons publié un correctif pour Azure DevOps Server 2019.0.1 qui corrige ce qui suit.

• Révoquez tous les jetons d’accès personnels après la désactivation du compte Active Directory d’un utilisateur.

Date de publication d’Azure DevOps Server 2019.0.1 Patch 12 : 26 janvier 2022

Nous avons publié un correctif pour Azure DevOps Server 2019.0.1 qui corrige ce qui suit.

• Correction de la vulnérabilité Elasticsearch en supprimant la classe jndilookup des fichiers binaires log4j.

Étapes d’installation

1. Mettez à niveau le serveur avec le correctif 12.
2. Vérifiez la valeur du registre dans HKLM:\Software\Elasticsearch\Version. Si la valeur du registre n’y figure pas, ajoutez une valeur chaîne et définissez Version sur 5.4.1 (Nom = Version, Valeur = 5.4.1).
3. Exécutez la commande PS C:\Program Files\{TFS Version Folder}\Search\zip> .\Configure-TFSSearch.ps1 -Operation update de mise à jour comme indiqué dans le fichier README. Elle peut renvoyer un avertissement tel que : Impossible de se connecter au serveur distant. Ne fermez pas la fenêtre, car la mise à jour effectue des nouvelles tentatives tant qu’elle n’est pas terminée.

1. Mettez à niveau le serveur avec le correctif 12.
2. Vérifiez la valeur du Registre à HKLM:\Software\Elasticsearch\Version. Si la valeur du registre n’y figure pas, ajoutez une valeur de chaîne et définissez la version sur 5.4.1 (Nom = Version, Valeur = 5.4.1).
3. Copiez le contenu du dossier nommé zip, situé sur C:\Program Files\{TFS Version Folder}\Search\zip, vers le dossier de fichiers distant d’Elasticsearch.
4. Exécutez Configure-TFSSearch.ps1 -Operation update sur l’ordinateur serveur Elasticsearch.

Hachage SHA-256 : 96C7AF3E3ED67C76451BA228427B3C0738EEB4A5835B6A91EBD3205A54C384D7

Date de publication d’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 corrige ce qui suit.

• Corrigez l’erreur de l’interface utilisateur de définition de version.

Date de publication d’Azure DevOps Server 2019.0.1 Patch 10 : 13 avril 2021

Nous avons publié un correctif pour Azure DevOps Server 2019.0.1 qui corrige ce qui suit.

• CVE-2021-27067 : divulgation d’informations

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

Installation de la tâche AzureResourceGroupDeploymentV2

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 avec 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

4. 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.

5. Exécutez ce qui suit à 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

6. Exécutez la commande suivante pour téléverser la tâche vers le serveur. Utilisez le chemin d’accès du fichier .zip extrait à l’étape 1.

  ~$ tfx build tasks upload --task-path *<Path of the extracted package>*

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

Nous avons publié un correctif pour Azure DevOps Server 2019.0.1 qui corrige ce qui suit. Consultez le billet de blog pour plus d’informations.

• CVE-2020-1325: Vulnérabilité d’usurpation d’identité Azure DevOps Server
• CVE-2020-17135 : Vulnérabilité d’usurpation d’identité d’Azure DevOps Server
• CVE-2020-17145 : Vulnérabilité d’usurpation d’identité Azure DevOps Server et Team Foundation Server
• Corriger un problème avec TFVC qui ne traite pas tous les résultats

Installation du correctif général

Si vous disposez d’Azure DevOps Server 2019.0.1, vous devez installer Azure DevOps Server 2019.0.1 Patch 9.

Vérification de l’installation en cours

• Option 1 : Exécutez 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 avoir installé Azure DevOps Server 2019.0.1 Patch 9, la version sera 17.143.30723.4 .

Installation de la tâche AzurePowerShellV4

Prérequis

1. Installez le module Az Azure PowerShell sur votre machine d’agent privé.

2. Créez un pipeline avec la tâche AzurePowerShellV4 . Vous ne verrez qu’un Échec sur la sortie d’erreur standard 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 avec 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

4. 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.

5. Exécutez ce qui suit à 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

6. Exécutez la commande suivante pour téléverser 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>*

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

Nous avons publié un correctif de sécurité pour Azure DevOps Server 2019.0.1 qui corrige 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 d’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 corrige les problèmes suivants. Consultez le billet de blog pour plus d’informations.

• CVE-2020-1326 : Vulnérabilité de script intersite
• Le pipeline de génération affiche une connexion incorrecte pour les utilisateurs non autorisés lors de la sélection d’une autre source Git.
• Corrigez l’erreur lors du passage de l’option Héritage à Activé ou Désactivé dans la définition de build XAML.

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

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

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

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

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

• CVE-2020-0700 : Vulnérabilité de script intersites
• CVE-2020-0758 : Vulnérabilité d’élévation de privilèges
• CVE 2020-0815 : Vulnérabilité d’élévation de privilèges

Date de publication d’Azure DevOps Server 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é de script intersite (XSS) dans Repos
• CVE-2019-1306 : Vulnérabilité d’exécution de code à distance dans le Wiki

Date de publication d’Azure DevOps Server 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 clarifier qu’elles sont autorisées pour tous les pipelines par défaut.

Date de publication d’Azure DevOps Server 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 pull requests

Date de publication d’Azure DevOps Server 2019.0.1 : 21 mai 2019

Azure DevOps Server 2019.0.1 est un cumul de correctifs de bogues. Il inclut tous les correctifs des patchs 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 d’Azure DevOps Server 2019 ou Team Foundation Server 2012 ou version ultérieure.

Cette version inclut les corrections des bugs suivants :

Azure Boards

• « Les critères du champ de ce plan comportent une erreur. » lors de la configuration d’un plan. Signalé par le biais de Developer Community.
• apiwitcontroller.executequery lève une exception lorsqu’une requête a la même colonne plusieurs fois.
• Dans le modèle objet client à l’aide de 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 dans un autre projet peut créer une image endommagée.

Azure Repos

• « TF401019 : GitRepositoryNotFoundException ».

Azure Pipelines

• L’onglet Test Analytics a une étoile (*) qui indique l’aperçu, même si cette fonctionnalité n’est pas en préversion.
• Sous l’onglet Publications, l’action de gestion de la sécurité s’affiche désormais à tous les utilisateurs, qu’ils puissent modifier les autorisations ou non.
• Sur les pages d’accueil de Releases, l’action de démarrage de la version brouillon créait une nouvelle version, mais elle lance maintenant la version brouillon.

Azure Test Plans

• Les filtres de 1 heure sur les dates CompletedDate de TestRuns et de TestResults sont trop granulaires.
• Dans le type d’élément de travail Test Case , le type « Test Case » ne doit pas être localisé.
• Les cas de test ne s’affichent pas dans MTM ou dans un navigateur.
• « Phase de validation : vous n’êtes pas autorisé à déclencher des mises en production sur le pipeline de mise en production associé » erreur lors de l’exécution de tests automatisés à partir d’un plan de test. Signalé par le biais de Developer Community.
• À l’aide de l’API de suppression de cas de test, les cas de test peuvent être supprimés d’autres projets. Signalé par le biais de Developer Community.
• Cliquer sur un lien d’élément de travail dans Test Runner ouvre l’URL de l’élément de travail dans 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 e-mail ne s’affichent pas dans la liste déroulante utilisateur de Test Runner.

Azure Artifacts

• Déplacer vers le haut et Déplacer vers le bas ne sont pas localisés dans Upstreams.

Analytique

• Les rapports d’analyse peuvent afficher des données incomplètes, car le modèle est marqué comme « prêt » avant qu’il ne soit réellement terminé.
• Les widgets vitesse, burndown et burnup affichent différents travaux planifiés pour les utilisateurs situés dans des fuseaux horaires différents.
• Une suspension peut être placée sur l’ingestion des données Analytics lors de la maintenance, ce qui peut entraîner des rapports obsolètes.

Général

• Les éléments de navigation de gauche sont compressés sur Internet Explorer lorsqu’il n’y a pas suffisamment d’espace.

Administration

• Ajout de journaux supplémentaires à la mise à niveau de Collection 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 d’administration ne répond plus lorsque la base de données de configuration est endommagée.
• Les hooks de service peuvent ne pas traiter correctement les notifications.
• L’indexation de recherche de code ne démarre pas après la configuration de la recherche.
• Il existe des chaînes non localisées sur les pages de résultats de recherche.

Cette publication comprend la mise à jour suivante :

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

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 Latest ou Visual Studio 2019 dans la liste déroulante des versions de la plateforme de test.

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

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

• CVE-2019-0872 : Vulnérabilité de scripts intersites (XSS) dans les plans de test
• 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

Date de publication d’Azure DevOps Server 2019 Patch 1 : 9 avril 2019

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

• CVE-2019-0857 : Vulnérabilité d’usurpation d’identité 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 intersites (XSS) dans Pipelines
• CVE-2019-0875 : Vulnérabilité d’élévation de privilèges dans Boards

Date de publication d’Azure DevOps Server 2019 : 5 mars 2019

Date de publication RC2 : 22 janvier 2019

Résumé des nouveautés d’Azure DevOps Server 2019 RC2

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

• Lier des commits GitHub Enterprise et des pull requests à des éléments de travail Azure Boards
• Configurer des builds à l’aide de YAML
• Les annotations de carte incluent des bogues et des types d’éléments de travail personnalisés
• Sélecteur de branches amélioré
• Modifications apportées aux licences de pipeline de déploiement d’artefacts et de gestion des mises en production

Date de publication RC1 : 19 novembre 2018

Résumé des nouveautés d’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 :

• Nouvelle expérience de navigation
• L’extension de la Place de marché Analytics pour la création de rapports est désormais disponible
• Prise en charge d’Azure SQL Database
• Héritage du processus sur les nouvelles collections
• Nouveau centre Éléments de travail
• Nouveaux hubs Boards, Backlogs et Sprints
• Nouveau centre de requêtes
• Normaliser les descriptions des pull requests à l’aide de modèles
• Modifier la branche cible d’une pull request
• Gérer les pipelines de build à l’aide de la nouvelle page Builds
• Gérer les pipelines de mise en production à l’aide de la nouvelle page Mises en production
• Visualiser la progression de la mise en production
• Mettre à jour localement votre agent
• Exposer et phaser progressivement des déploiements à l’aide de gates de publication
• Sources upstream
• Créer une table des matières pour les pages wiki

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

• Général
• Tableaux
• Dépôts
• Pipelines
• Plans de test
• Artefacts
• Wiki
• Reporting

Général

Annonce d’Azure DevOps Server

Le 10 septembre, nous avons annoncé Azure DevOps comme évolution de Visual Studio Team Services et team Foundation Server. Azure DevOps Server 2019 est notre première version sur site avec cette nouvelle marque. 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 sur le service Azure DevOps et est désormais disponible dans Azure DevOps Server 2019. Pour plus d’informations, consultez notre blog .

Modifications apportées aux licences d’Artifacts et du pipeline de déploiement de gestion des mises en production

En fonction des commentaires des utilisateurs, nous apportons deux modifications clés à nos licences pour Azure DevOps Server 2019. Tout d’abord, les clients n’auront plus besoin d’acheter l’extension Artifact pour utiliser Artifacts. Une licence Artifacts sera désormais incluse dans la licence Basic License. Tous les utilisateurs ayant une licence Basic qui leur est attribuée pourront désormais utiliser des artefacts. Deuxièmement, les clients ne seront plus obligés d’acheter Release Management Deployment Pipelines. Tout comme les pipelines de build, les pipelines de déploiement de gestion des mises en production sont désormais inclus dans Azure DevOps Server 2019.

Prise en charge d’Azure SQL Database

Pour simplifier l’expérience d’exécution d’Azure DevOps 2019 dans Azure, nous avons activé la prise en charge d’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 en fonction de vos besoins tout en réduisant la surcharge 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 maintenir la latence faible. Pour plus d’informations, consultez la documentation.

API SOAP du modèle objet des éléments de travail et du client de test dans les futures versions

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

Traitement de l’héritage sur les nouvelles collections

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

Zone de recherche étendue

Nous comprenons l’importance de la recherche et rétablissons la zone de recherche étendue dans l’en-tête du produit. En outre, vous pouvez maintenant afficher la zone de recherche en appuyant simplement sur la touche « / » sur n’importe quelle page de service dans Azure DevOps.

Voici la zone de recherche par défaut :

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

Mon menu déroulant de travail

Une nouvelle fonctionnalité que nous sommes ravis de présenter est le volet Mon travail. Nous avons entendu des commentaires indiquant que 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. Avec cette nouvelle fonctionnalité, vous pouvez accéder à ce volet n’importe où dans le produit, et il vous donnera un aperçu rapide des informations cruciales, notamment vos éléments de travail, vos pull requests et tous les favoris. Avec ce nouveau volet, si vous êtes dans Repos, absorbé par votre code, mais que vous souhaitez vérifier rapidement sur quel élément de travail vous devez travailler ensuite, vous pouvez simplement cliquer sur le volet et voir les éléments de travail qui vous sont affectés, puis prendre l’élément suivant.

Vous pouvez voir ci-dessous le menu déroulant Mon travail montrant les éléments de travail qui m’ont été attribués :

Ici, vous pouvez voir le deuxième pivot qui montre les PR qui me sont attribuées. Dans le menu déroulant, vous avez également un accès en un clic pour afficher d’autres pull requests :

Ici, vous pouvez voir le dernier onglet, qui correspond à tout ce que vous avez ajouté aux favoris. Cela inclut vos équipes préférées, tableaux de bord, tableaux, backlogs, requêtes et référentiels :

Tableaux

Lier des commits GitHub Enterprise et des pull requests à des éléments de travail Azure Boards

Les équipes qui utilisent GitHub Enterprise pour le code et veulent des fonctionnalités de gestion de projet enrichies peuvent désormais intégrer leurs dépôts à Azure Boards. En connectant GitHub et Azure Boards, vous pouvez obtenir toutes les fonctionnalités telles que les backlogs, les tableaux, les outils de planification sprint, plusieurs types d’éléments de travail et avoir toujours un flux de travail qui s’intègre aux flux de travail des développeurs dans GitHub.

Lier des commits et des pull requests à des éléments de travail est facile. Mentionnez l’élément de travail à l’aide de la syntaxe suivante :

AB#{work item ID}

Mentionnez un élément de travail dans un message de validation, un titre de pull request ou une description de pull request, et Azure Boards créera un lien vers cet artefact. Par exemple, considérez un message de validation comme suit :

Adds support for deleting connections. Fixes AB#20.

Cela crée un lien à partir de l’élément de travail #20 vers le commit dans GitHub, qui apparaît dans la section Développement de l’élément de travail. ​

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

Les équipes qui utilisent Azure Pipelines pour compiler le code dans GitHub verront également les éléments de travail liés à leurs validations GitHub dans le résumé de la build.

Nouveau centre des éléments de travail

Le Work Items Hub est notre nouveau hub qui sera l’emplacement central de vos éléments de travail ! Ici, vous avez de nombreuses vues de liste différentes de vos éléments de travail qui sont filtrés pour vous. Vous pouvez consulter Attribué(s) à moi pour obtenir rapidement un aperçu de tout le travail qui vous est attribué ou Récemment mis à jour, qui vous montre tous les éléments de travail de votre projet qui ont été mis à jour récemment. Toutes vos options de liste sont visibles ci-dessous :

Si vous souhaitez affiner davantage vos listes, vous pouvez filtrer sur le type, attribué à, l’état, la zone, les balises et le mot clé. Une fois que vous avez votre affichage de liste souhaité, vous pouvez ensuite 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 sont visibles ci-dessous :

Nouveaux hubs Boards, Backlogs et Sprints

Le hub Backlogs a été divisé en trois hubs distincts pour améliorer l’expérience utilisateur. Bien que puissant, l’ancien hub Backlogs accueillait trop de fonctionnalités. Cela a souvent rendu la recherche des fonctionnalités ou des capacités que les utilisateurs recherchaient difficile. Pour résoudre ce problème, nous avons fractionné le hub Backlogs en :

• Le hub Backlogs abrite désormais uniquement les backlogs d’un projet. Un backlog est une liste de travail hiérarchisée pour l’équipe. Les backlogs fournissent des outils de planification tels que la hiérarchie des éléments de travail, la prévision et une nouvelle expérience de planification sprint.
• Le nouveau hub Boards abrite tous les tableaux Kanban pour un projet. Les Boards sont utilisés pour communiquer l’état et le flux de travail. Les cartes (éléments de travail) passent de gauche à droite dans le tableau à travers les colonnes définies par l’équipe.
• Le nouveau hub Sprints abrite les fonctionnalités utilisées pour planifier et exécuter un incrément de travail. Chaque sprint contient un backlog sprint, un tableau des tâches et une vue pour gérer et définir la capacité de l’équipe.

Nouveau centre de requêtes

Le nouveau hub de requêtes simplifie bon nombre des fonctionnalités de requête existantes de l’ancien hub, avec une apparence plus moderne, et offre également de nouvelles fonctionnalités pour faciliter l’accès aux requêtes qui sont importantes pour vous. Voici quelques points forts de la nouvelle expérience :

• Pages d’annuaire avec les informations sur la dernière modification par et possibilité d’effectuer des recherches
• Fil d’Ariane avec URL uniques pour les dossiers afin d’ajouter aux favoris des groupes importants de requêtes
• Accès rapide à vos requêtes favorites à partir de la page de résultats

En savoir plus sur ces mises à jour passionnantes sur 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 des éléments de travail vers un autre projet au sein d’une collection de projets. Ces fonctionnalités nécessitent que l’entrepôt de données soit désactivé. Une fois l’entrepôt de données désactivé, vous pouvez utiliser le service Analytics pour prendre en charge 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 des sprints

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

• Créez votre sprint suivant ou abonnez-vous à une planification de sprint existante directement à partir du hub Sprints .
• Utilisez le nouveau volet Planification de votre backlog pour faire glisser et déplacer des éléments de travail dans les sprints futurs. Le volet Planification inclut les dates de sprint, le nombre d’éléments de travail et l’effort planifié.
• Ajoutez des exigences en haut du Taskboard ou utilisez la création rapide pour ajouter au haut, au bas ou à la ligne de votre choix dans votre backlog de sprint.
• Utilisez des filtres pour Assigné, Type d’élément de travail, État et Balises pour adapter les vues à vos besoins.

Nouvelles pages Directory

Tous les nouveaux hubs, notamment Backlogs, Boards et Sprints, ont désormais de nouvelles pages de répertoire organisées avec les sections suivantes :

• Continuer là où vous vous êtes arrêté Cette nouvelle section vous fournit un lien rapide directement vers le dernier (Tableau | Backlog | Sprint) sur lequel vous étiez.
• Favoris Tous vos tableaux préférés, sprints et backlogs dans toutes les équipes.
• Mes tous les tableaux, backlogs et sprints pour les équipes auxquelles vous appartenez.
• Tous Liste complète de tous vos tableaux, backlogs et sprints.

Nouveau menu Options d’affichage

Les nouveaux hubs, notamment Backlogs, Boards et Sprints, ont un nouveau menu Options d’affichage. Il s’agit d’un nouvel emplacement central pour toutes les actions permettant de personnaliser la mise en page et le contenu de la page. Utilisez Options d’affichage pour activer des vues supplémentaires, telles que l’affichage de la hiérarchie dans les backlogs ou la modification de l’option Grouper par dans un tableau des tâches, pour activer le panneau latéral pour le mappage et la planification des sprints, ou pour explorer les graphiques de détails de travail.

En savoir plus sur ces mises à jour passionnantes, le nouveau volet Profil d’équipe et les Favoris sur notre blog DevOps.

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

Les annotations de fiche sont appréciées pour leur vue en liste de contrôle intuitive et leur interaction. Auparavant, les annotations de carte étaient limitées aux types de niveau 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 les bogues et tout type d’élément de travail personnalisé en tant qu’annotation de carte.

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

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

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

Déplacer les éléments de travail à l’aide des chemins de zone et d’itération suggérés

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

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

Interroger le travail sur l’ensemble de la planification d’itération avec +/- @CurrentIteration

La @CurrentIteration macro qui aide votre équipe à suivre le travail en fonction de votre planification d’itération prend désormais en charge un décalage entier. Suivez facilement le travail qui n’a pas été fermé avec @CurrentIteration - 1, ou consultez le travail prévu pour les itérations futures avec @CurrentIteration + 1. Pour plus d’informations, consultez le billet @CurrentIteration sur le blog Microsoft DevOps.

Clarifier les calendriers d’itération des requêtes avec le paramètre @CurrentIteration Team

Si vous avez utilisé la macro @CurrentIteration dans les requêtes dans le passé, vous avez peut-être remarqué que les résultats peuvent varier si le contexte d’équipe change dans Teams avec des planifications d’itération différentes. À présent, 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 est pertinente pour la requête. Avec le paramètre Team, vous pouvez utiliser la macro @CurrentIteration dans la même requête, mais sur plusieurs équipes. Un exemple peut être une requête pour les éléments de travail dans deux projets d’équipe différents utilisant des noms d’itération différents et même des planifications. Cela signifie qu’il n’est plus nécessaire de mettre à jour les requêtes au fur et à mesure que les sprints changent ! Pour plus d’informations, consultez le billet @CurrentIteration sur le blog Microsoft DevOps.

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

Dans les paramètres d’une équipe, vous pouvez associer un ou plusieurs chemins d’accès de zone, ce qui vous permet de concentrer les backlogs, les tableaux, les plans, même les tableaux de bord au travail de cette équipe. Si vous vouliez écrire une requête pour une équipe, vous deviez répertorier les Area Paths spécifiques pour cette équipe dans les clauses de requête. À présent, une nouvelle macro @TeamAreas est disponible pour vous permettre de référencer facilement les chemins de zone appartenant à l’équipe spécifiée.

Requête pour les champs de texte enrichi vides

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

Trouver facilement des éléments de travail existants dans les interfaces de liaison et de mention

Lorsque vous souhaitez lier deux éléments de travail existants ensemble, vous pouvez maintenant trouver facilement l’élément qui est important pour vous à 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 vos é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 titre.

Ouvrir les éléments de travail à partir de la recherche

Auparavant, un élément de travail n’a pas pu être ouvert à partir de la page des résultats de la recherche si le volet d’aperçu de l’élément de travail a été désactivé. Cela rendrait difficile l’analyse de vos résultats de recherche. Vous pouvez maintenant cliquer sur le titre de l’élément de travail pour ouvrir l’élément de travail dans une fenêtre modale.

Dépôts

Sélecteur de branches amélioré

La plupart des expériences dans Azure Repos vous obligent à sélectionner un dépôt, 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 succursales. Le sélecteur vous permet désormais de sélectionner vos branches préférées ou de rechercher rapidement une branche.

Recevoir des notifications lorsque les politiques de pull request sont contournées

Pour les équipes qui utilisent des pull requests (PR) et des stratégies de branchement, il peut arriver que les utilisateurs doivent remplacer et contourner ces stratégies, par exemple lors du déploiement d’un correctif logiciel pour corriger un incident en production au milieu de la nuit. Il est judicieux de faire confiance aux développeurs pour faire la bonne chose et d’utiliser la fonctionnalité de remplacement avec parcimonie. En même temps, les équipes ont besoin d’un moyen de vérifier que ces dérogations à ces politiques sont utilisées dans les bonnes situations. Pour ce faire, nous avons ajouté un nouveau filtre de notification pour permettre aux utilisateurs et aux équipes de recevoir des alertes par e-mail chaque fois qu’une politique est contournée. Commencez par le modèle Une demande de tirage est créée ou mise à jour, puis sélectionnez Contournement de stratégie dans la liste des filtres. Sélectionnez Les stratégies ont été contournées comme valeur et vous serez averti chaque fois qu’une PR est terminée et que les stratégies sont ignorées.

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

Il existe de nombreux scénarios où vous avez parfois besoin de contourner une stratégie de branche : annulation d’une modification à l’origine d’un échec de build, application d’un correctif urgent au milieu de la nuit, etc. Auparavant, nous proposions une autorisation (« Exempté de l’application de la stratégie ») pour aider les équipes à gérer les utilisateurs auxquels elles accordaient la possibilité de contourner les stratégies de branche lors de la finalisation d’une pull request. Toutefois, cette autorisation a également accordé la possibilité d’envoyer directement à la branche, en contournant entièrement le processus de pull request.

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

1. Contourner les politiques lors des demandes de tirage (pull requests). Les utilisateurs disposant de cette autorisation pourront utiliser l’expérience « Override » pour les pull requests.
2. Contourner les stratégies lors du push. Les utilisateurs disposant de cette permission pourront envoyer (push) directement aux branches dont les politiques requises sont 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 contre un push accidentel vers une branche avec des stratégies de branche.

Pour plus d’informations, consultez la documentation Définir les autorisations de branche.

Décrire rapidement les demandes de fusion à l’aide de messages de validation

L’écriture de messages de commit descriptifs ajoute de la valeur à l’historique de n’importe quel dépôt Git. Pour encourager les messages de commit de qualité, les nouvelles pull requests (PR) qui ont plusieurs commits nécessitent que les contributeurs entrent manuellement un titre.

Les descriptions des pull requests continueront d’être vides par défaut, mais une nouvelle fonctionnalité facilitera l’incorporation des messages de commit des commits de la PR dans la description de la PR. Pour ajouter les messages de commit, cliquez simplement sur Ajouter des messages de commit pour ajouter les messages de commit à la fin du texte de description de la PR.

Créer des pull requests sans équipe par défaut comme réviseur

Lors du premier lancement de l’expérience de pull request (PR), nous avons pensé qu’il serait judicieux d’affecter toutes les PR au contexte d’équipe que vous aviez sélectionné lors de la création de la pull request. Ce comportement a été un point de frustration, car beaucoup de personnes n’ont pas remarqué la connexion entre le contexte de l’équipe et l’affectation de pull request.

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

1. Lors de la création d’une PR, aucun relecteur n’est ajouté par défaut. La liste des réviseurs dispose d’une fonctionnalité permettant d’ajouter plus facilement des individus et des groupes qui ont été ajoutés aux pull requests récemment. La stratégie de réviseurs requis peut également aider les équipes qui souhaitent s’assurer que des réviseurs spécifiques sont ajoutés pour passer en revue leur code.
2. Le hub Pull Requests a une nouvelle section personnalisable. Par défaut, cette section affiche les pull requests « Affectées à mes équipes », fournissant des fonctionnalités équivalentes à l’ancienne section. Toutefois, si vous appartenez à plusieurs équipes, cette section affiche les pull requests attribuées à l’une de vos équipes. La section est également personnalisable. Cliquez simplement sur l’action « Personnaliser cette vue » près de l’en-tête de section.

Normaliser les descriptions des pull requests à l’aide de modèles

L’écriture de descriptions de bonnes pull requests est un excellent moyen d’aider les réviseurs à savoir ce qu’il faut attendre lors de l’examen du code. Il s’agit également d’un excellent moyen de suivre ce qui doit être effectué pour chaque modification, comme les tests, l’ajout de tests unitaires et la mise à jour de la documentation. Bon nombre d’entre vous demandent que nous ajoutions des modèles de demandes de tirage pour faciliter l’écriture d’excellentes descriptions par les équipes, et nous avons maintenant ajouté cette fonctionnalité.

En plus de prendre en charge un modèle de description de pull request par défaut, les équipes peuvent ajouter plusieurs modèles, qui vous sont présentés dans un menu sur la page de création de pull request. Cliquez simplement sur le bouton Ajouter un modèle pour choisir parmi n’importe quel modèle du référentiel afin de l’ajouter à la description de la pull request.

Les modèles spécifiques à une branche sont également pris en charge si vous souhaitez appliquer un autre modèle pour une pull request dans une branche spécifique ou un dossier de branche. 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 tous les PR dans ces branches.

Consultez la documentation sur les modèles de pull request pour en savoir plus sur la création et l’utilisation de modèles.

Modifier la branche cible d’une pull request

Pour la plupart des équipes, presque toutes les pull requests ciblent la même branche, telle que main ou develop. Toutefois, dans le cas où vous devez cibler une autre branche, il est facile d’oublier de remplacer la branche cible par défaut. Avec la nouvelle fonctionnalité permettant de modifier la branche cible d’une pull request active, il s’agit maintenant d’une action simple. Cliquez simplement sur l’icône en forme de crayon près du nom de la branche cible dans l’en-tête de pull request.

Au-delà de la correction d’erreurs, la fonctionnalité permettant de modifier les branches cibles facilite également le « reciblage » d’une pull request lorsque la branche cible a été fusionnée ou supprimée. Envisagez un scénario dans lequel vous avez une pull request ciblant une branche de fonctionnalité qui contient une fonctionnalité dont dépendent vos modifications. Vous souhaitez examiner vos modifications dépendantes séparément des autres modifications de la branche de fonctionnalité, vous ciblez donc initialement features/new-feature. Les réviseurs peuvent alors voir uniquement vos modifications et laisser les commentaires appropriés.

Maintenant, envisagez ce qui se passerait si la branche de fonctionnalité avait également une pull request active et avait été fusionnée dans main avant vos modifications ? Auparavant, vous deviez abandonner vos modifications et créer une nouvelle PR dans main, ou fusionner votre PR dans features/new-feature, puis créer une autre PR de features/new-feature vers main. Avec cette nouvelle action pour mettre à jour la branche cible, vous pouvez simplement modifier la branche cible de la PR de features/new-feature vers 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 pull request, ce qui facilite l’analyse des différences antérieures avant la modification de la branche cible.

Les auteurs d’extension peuvent interroger le contexte à propos du dépôt actuel

L’un des défis pour un auteur d’une extension de contrôle de version consiste à obtenir le contexte du référentiel présenté à l’utilisateur, tel que le nom, l’ID et l’URL. Pour vous aider, nous avons ajouté le Service VersionControlRepositoryService en tant que service accessible par extension. À l’aide de cela, un auteur d’extension peut rechercher des informations sur le contexte actuel du référentiel Git dans l’interface utilisateur web. Il a actuellement une méthode, getCurrentGitRepository().

• Si un dépôt Git est sélectionné, un objet GitRepository est retourné avec des données de base sur le dépôt (nom, ID et URL)
• Si un référentiel 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 les pipelines de build à l’aide de la nouvelle page Builds

Nous apportons plusieurs améliorations et déployons une nouvelle version de la page Builds . Cette nouvelle version combine le répertoire de tous vos pipelines de build et la liste des builds actuels afin que vous puissiez rapidement parcourir les builds de votre projet pour voir leur état. Il inclut également un aperçu des analyses de test pour le pipeline sélectionné.

Gérer les e-mails de génération et de fin de déploiement mieux à l’aide d’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 facilement filtrables par les règles de messagerie. Maintenant, la ligne d’objet inclut des informations plus pertinentes en un clin d’œil, le corps contient plus de détails et leur style a été actualisé avec la dernière identité de marque.

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

Suivez la nouvelle terminologie unifiée d’Azure Pipelines

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

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

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

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

Une nouvelle expérience utilisateur entièrement repensée est disponible pour la page d’accueil de la version. Consultez la liste des pipelines de version que vous utilisez souvent à gauche. Vous pouvez également rechercher vos pipelines et les ajouter aux favoris.

Passez à l’affichage 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.

Visualiser la progression de la version

La nouvelle vue de progression de la mise en production vous offre des mises à jour en temps réel de la progression du déploiement et un clic vous permet d’accéder à d’autres détails. La nouvelle vue visualise le pipeline de mise en production, ce qui facilite la compréhension de ce qui se passe et expose les détails et les actions appropriés aux différentes étapes de la mise en production.

Pipeline, détails des mises en production et environnements

La vue Pipeline affiche les artefacts de la version et les environnements dans lesquels ils seront déployés. L’espace Release fournit des détails de publication tels que le déclencheur de mise en production, les versions d’artefact et les balises.

Les environnements sont modélisés de manière à mieux comprendre leur état, ainsi que des informations détaillées sur l’avancement. À tout moment, vous pouvez accéder aux journaux en cliquant sur le lien d’état dans l’environnement.

Pré-déploiement et post-déploiement

Si des conditions de prédéploiement ou de post-déploiement ont été définies pour un environnement, elles sont indiquées sur l’environnement avec la présence des approbations et des gates. La progression des approbations et des jalons s’affiche également dans l’état de l’environnement. Vous pouvez effectuer des actions ou afficher des détails supplémentaires en cliquant sur l’icône de condition de l’environnement située sur le côté droit ou gauche de l’environnement.

Commits et éléments de travail

À chaque nouvelle version, vous pouvez voir 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 un commit ou un élément de travail qui vous intéresse.

Progression du déploiement et journaux

Les environnements affichent des mises à jour actives pour les déploiements en cours, notamment le nombre de phases et de tâches terminées et la durée d’exécution. Cliquer sur l’état de l’environnement ouvre une vue contenant les journaux, l’accent étant mis sur l’élément actuellement actif.

Vous pouvez cliquer dans les journaux pour accéder à une vue ciblée.

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

Les groupes de machines sous Test Hub 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 « Windows Machine File Copy » version 1.* et de la tâche « PowerShell on Target Machines » version 1.*. Pour que vos pipelines continuent de fonctionner,

• Vous devez basculer vers la tâche « Copie de fichiers de machine Windows » version 2.* et fournir le FQDN complet de la machine cible au lieu du nom de la machine.
• Basculez vers la tâche « PowerShell sur l’ordinateur cible » version 2.* ou ultérieure et fournissez le nom de domaine complet (FQDN) de la machine ou le nom de la machine suivi des ports de gestion à distance Windows (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 du test ouvre une vue contenant les détails du test, y compris les résultats d’autres extensions qui contribuent au processus.

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

Configurer des builds à l’aide de YAML

Les pipelines de build BASÉS sur YAML sont disponibles dans votre serveur Azure DevOps. Automatisez votre pipeline d’intégration continue à l’aide d’un fichier YAML validé dans votre dépôt. Vous trouverez ici une référence complète pour le schéma YAML.

Pour prendre en charge les pipelines de build basés sur YAML de manière plus transparente, nous avons modifié le comportement par défaut de toutes les nouvelles ressources que vous créez (par exemple, les connexions de service, les groupes de variables, les pools d’agents et les fichiers sécurisés) afin qu’elles puissent être utilisées dans tout pipeline de ce projet. Si vous souhaitez un contrôle plus strict sur vos ressources, vous pouvez désactiver le modèle d’autorisation par défaut (voir la figure ci-dessous). Lorsque vous le faites, une personne disposant des autorisations d’utilisation de 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.

Chaîner des builds associées à l’aide de déclencheurs d’achèvement de build

Les produits complexes contiennent plusieurs composants qui dépendent les uns des autres. Ces composants sont souvent construits indépendamment. Lorsqu’un composant en amont (une bibliothèque, par exemple) change, les dépendances en aval doivent être reconstruites et validées à nouveau. Les équipes gèrent généralement ces dépendances manuellement.

Vous pouvez maintenant déclencher une compilation une fois qu’une autre compilation s’est terminée avec succès. Les artefacts générés par une build en amont peuvent être téléchargés et utilisés dans la build ultérieure, et vous pouvez également obtenir des données à partir de ces variables : Build.TriggeredBy.BuildId, Build.TriggeredBy.DefinitionId, Build.TriggeredBy.BuildDefinitionName. Pour plus d’informations, consultez la documentation sur les déclencheurs de build.

Gardez à l’esprit que dans certains cas, une build unique en plusieurs phases peut répondre à vos besoins. Toutefois, un déclencheur d’achèvement de build est utile si vos besoins incluent différents paramètres de configuration, options ou une autre équipe chargée du processus dépendant.

Mettre à jour localement votre agent

Les tâches que vous installez à partir de la galerie nécessitent parfois une version plus récente de l’agent pipelines. Si votre serveur Azure DevOps 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. À compter 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. Cela vous offre à la fois flexibilité et contrôle sur les versions de l’agent que vous rendez disponibles, sans avoir à exposer votre Azure DevOps Server à Internet.

URL du badge d’état de la nouvelle build

Les badges de build incorporés dans la page d’accueil d’un dépôt sont un moyen courant d’afficher l’état du dépôt. Même si nous avions des badges de build jusqu’à présent, il y avait quelques problèmes :

• L’URL n’était pas intuitive
• Le badge n’était pas spécifique à une branche
• Il n’y avait aucun moyen pour un utilisateur de cliquer sur le badge pour rediriger l’utilisateur vers la dernière build 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 branche et peut amener les utilisateurs à la dernière build de la branche sélectionnée. Vous pouvez obtenir le Markdown de la nouvelle URL du badge d’état en sélectionnant l’action de menu Badge d’état dans la nouvelle page Builds.

Pour la compatibilité descendante, nous continuerons également à honorer les URL de badge de build plus anciennes.

Ajouter des compteurs de compilation personnalisés à vos compilations

Les compteurs de build permettent de numéroter et d’étiqueter les builds de façon 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, vous effectuez cette opération sous l’onglet Variables d’une définition. Cette nouvelle fonctionnalité vous donne plus de puissance de la manière suivante :

• Vous pouvez définir un compteur personnalisé et définir sa valeur initiale. 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 il est réinitialisé automatiquement chaque fois qu’il existe un nouveau préfixe 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 build, consultez la documentation sur variables définies par l’utilisateur.

Validations de la conformité et de la sécurité Azure Policy dans les pipelines

Nous voulons assurer la stabilité et la sécurité des logiciels dès le début du processus de développement tout en regroupant le développement, la sécurité et les opérations. Pour ce faire, nous avons ajouté la prise en charge d’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 aux normes de votre entreprise et aux contrats de niveau de service.

Pour respecter les directives de conformité et de sécurité dans le cadre du processus de mise en production, nous avons amélioré notre expérience de déploiement de groupe de ressources Azure. À présent, nous faisons échouer la tâche de déploiement du groupe de ressources Azure avec les erreurs de stratégie pertinentes en cas de violations lors du déploiement de modèles ARM.

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

Générer sur les plateformes Linux/ARM et Windows 32 bits

L’agent Azure Pipelines open source et multiplateforme a toujours été pris en charge sur Windows 64 bits (x64), macOS et Linux. Avec cette version, nous présentons deux nouvelles plateformes prises en charge : Linux/ARM et Windows/32 bits. Ces nouvelles plateformes vous permettent de créer sur des plateformes moins courantes, mais pas moins importantes, telles que Raspberry Pi, une machine Linux/ARM.

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

L’onglet Tests offre désormais une expérience moderne qui vous fournit des informations de test contextuelles enrichies 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 des tests en contexte, des rapports sur les exécutions de test annulées et le résumé du niveau d’exécution.

Afficher l’exécution des tests en cours

Les tests, tels que les tests d’intégration et fonctionnels, peuvent s’exécuter pendant longtemps. Il est donc important de voir l’exécution des tests à tout moment donné. Avec la vue de test en cours, 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 en quasi temps réel au fur et à mesure de leur exécution, ce qui vous permet de prendre des mesures plus rapidement. Vous pouvez déboguer un échec ou abandonner, déposer un bogue ou abandonner le pipeline. La fonctionnalité est actuellement disponible pour les pipelines de génération et de mise en production à l’aide de VS Test Task dans la phase Multi Agent, à l’aide de Publish Test Results Task ou en publiant les 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 de Single Agent.

L’affichage ci-dessous montre le résumé du test en cours dans la nouvelle vue de progression de la version, indiquant le nombre total de tests et le nombre d’échecs de test à un moment donné.

En cliquant sur le résumé du test en cours ci-dessus, vous pouvez afficher le résumé détaillé des tests, ainsi que les informations de test ayant échoué ou abandonnées dans Plans de test. Le résumé des tests s’actualise à intervalles réguliers avec la possibilité d’actualiser la vue des détails à la demande, en fonction de la disponibilité des nouveaux résultats.

Afficher les détails du débogage des exécutions de test dans la page complète

Les messages d’erreur et les traces de pile sont assez longs et ont besoin de suffisamment d’espace pour afficher les détails pendant le débogage. Pour bénéficier d’une expérience de débogage immersive, vous pouvez maintenant agrandir la vue de test ou d’exécution de test en vue pleine page, tout en étant toujours en mesure d’effectuer les opérations contextuelles requises, telles que la création de bogues ou l’association de conditions requises pour le résultat du test actuel.

Afficher l’historique des tests dans le contexte

Historiquement, les équipes doivent accéder au hub d’exécutions pour afficher l’historique d’un résultat de test. Avec la nouvelle expérience, nous apportons l’historique des tests directement dans le contexte dans l’onglet Plans de test pour le build et la mise en production. Les informations d’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é, suivie d’autres branches et environnements pour la génération et la mise en production respectivement.

Afficher les tests abandonnés

L’exécution de test peut être interrompue en raison de plusieurs raisons telles que le code de test incorrect, la source sous test et les problèmes environnementaux. Quelle que soit la raison de l’interruption, il est important de diagnostiquer le comportement et d’identifier la cause racine. Vous pouvez maintenant afficher les tests abandonnés et les exécutions de test, en même temps que les exécutions terminées dans Plans de test. La fonctionnalité est actuellement disponible pour le pipeline de build et de release à l’aide de VS Test Task en phase Multi Agent ou la publication des résultats de test à l’aide des API. À l’avenir, nous prévoyons d’étendre cette expérience pour l’exécution des tests à l’aide de Single Agent.

Prise en charge de la traçabilité des tests et des environnements de version dans l’historique des tests

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

Passer en revue les résultats des tests résumés

Pendant l’exécution, 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 d’échecs, les tests composés d’une combinaison ordonnée d’autres tests (par exemple, test ordonné) ou les tests ayant différentes instances en fonction du 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 individuels des tests. Avec cette mise à jour, nous présentons une version améliorée des résultats des tests présentés sous la forme d’une hiérarchie dans l’onglet Tests d’une version. Examinons un exemple.

Plus tôt, nous avons introduit la possibilité de réexécuter les tests ayant échoué dans la tâche VS Test. Toutefois, nous n’avons signalé que la dernière tentative d’un test, ce qui a quelque peu limité l’utilité de cette fonctionnalité. Nous avons maintenant étendu cette fonctionnalité pour signaler chaque instance de l’exécution de test en tant que tentative. En outre, l’API Gestion des tests prend désormais en charge la possibilité de publier et d’interroger des résultats de test hiérarchiques. Pour plus d’informations, consultez la documentation de l’API de résultats des tests.

Afficher l’analytique des tests dans Pipelines

Le suivi de la qualité des tests au fil du temps et l’amélioration des artefacts de test sont essentiels à la maintenance d’un pipeline sain. La fonctionnalité d’analyse de test fournit une visibilité quasi en temps réel de vos données de test pour les builds et les pipelines de mise en production. Elle permet d’améliorer l’efficacité de votre pipeline en identifiant les problèmes de qualité répétitifs et à impact élevé.

Vous pouvez regrouper les résultats des tests par différents éléments, identifier les tests clés pour votre branche ou vos fichiers de test, ou explorer un test spécifique pour afficher les tendances et comprendre les problèmes de qualité tels que l’instabilité.

Affichez les analyses de test pour les builds et la version, aperçu ci-dessous :

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 le serveur et exécutées sur le serveur. Les phases sans agent ne nécessitent pas d’agent ni d’ordinateurs cibles. Contrairement aux phases de l’agent, une seule tâche pouvait être ajoutée à chaque phase sans agent dans les définitions. Cela signifiait que plusieurs phases devaient être ajoutées lorsqu’il y avait plus d’une tâche sans agent dans le processus, ce qui rendait la définition volumineuse. Nous avons assoupli cette restriction, ce qui vous permet de gérer plusieurs tâches au sein de phases 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 d’agent. Pour plus d’informations, consultez la documentation sur les phases du serveur.

Exposer et phaser progressivement des déploiements à l’aide de gates de publication

À l’aide de gates de mise en production, vous pouvez spécifier des critères d’état de santé de l’application qui doivent être remplis avant qu’une mise en production soit promue vers l’environnement suivant. Tous les contrôles spécifiés sont évalués régulièrement avant ou après tout déploiement, jusqu’à ce qu’ils soient tous validés. Quatre types de passerelles sont disponibles par défaut et vous pouvez ajouter d’autres passerelles à partir du Marketplace. Vous pourrez vérifier que tous les critères nécessaires pour un déploiement ont été remplis. Pour plus d’informations, consultez la documentation relative aux gates de mise en production.

Maintenez les déploiements en attente jusqu’à ce que les contrôles soient systématiquement validés

Les gates de mise en production permettent l’évaluation automatique des critères d’état de santé avant qu’une mise en production soit promue vers l’environnement suivant. Par défaut, la publication se poursuit après réception d’un échantillon valide pour tous les jalons. Même si un contrôle est instable et que l’échantillon reçu et considéré comme valide n’est en réalité que du bruit, la publication progresse. Pour éviter ces types de problèmes, vous pouvez maintenant configurer la version pour vérifier la cohérence de l’état de santé pendant une durée minimale avant de poursuivre le déploiement. Au moment de l’exécution, la release s’assurerait que les évaluations consécutives des gates ont réussi avant d’autoriser la promotion. Le temps total d’évaluation dépend du « temps entre la réévaluation » et est généralement supérieur à la durée minimale configurée. Pour plus d’informations, consultez la documentation relative au contrôle du déploiement de version à l’aide de gates.

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

Auparavant, lorsque de nouvelles cibles ont été ajoutées à un groupe de déploiement, un déploiement manuel a été nécessaire pour s’assurer que toutes les cibles ont la même version publiée. 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.

Déployer en continu des builds marqués par un traitement post-build

Les déclencheurs de déploiement continu créent une mise en production à la fin de la build. Toutefois, les builds sont parfois post-traités et la build ne doit être publiée qu’une fois ce traitement terminé. Vous pouvez maintenant tirer parti des balises de génération, qui seraient attribuées pendant le post-traitement, dans les filtres de déclencheur de la mise en production.

Définir une variable au moment du déploiement

Dans une définition de mise en production, vous pouvez maintenant choisir les variables que vous souhaitez définir lorsque vous créez la mise en production.

La valeur fournie pour la variable lorsque la mise en production est créée est utilisée uniquement pour cette mise en production. Cette fonctionnalité vous permet d’éviter plusieurs étapes pour Create-in-Draft, de mettre à jour les variables dans le brouillon et de déclencher le release avec la variable.

Passer des variables d’environnement aux tâches

Les auteurs de tâches CI/CD peuvent définir une nouvelle propriété, showEnvironmentVariables, dans le task.json pour passer des variables d’environnement à des tâches. Lorsque vous le faites, un contrôle supplémentaire s’affiche sur la tâche dans l’éditeur de version. Ceci est disponible pour les tâches PowerShell, Cmd et Bash.

Cela active deux scénarios :

• Une tâche nécessite une variable d’environnement avec la conservation de la casse dans le nom de la variable. Par exemple, dans l’exemple ci-dessus, la variable d’environnement transmise à la tâche serait « foo » et non « FOO ».
• Il permet aux valeurs de secrets d’être transmises de manière sécurisée aux scripts. Ceci est préférable au passage des secrets en tant qu’arguments aux scripts, car le système d’exploitation sur l’agent peut journaliser les appels de processus, y compris leurs arguments.

Clonage des groupes de variables

Nous avons ajouté la prise en charge du clonage de groupes de variables. Chaque fois que vous souhaitez répliquer un groupe de variables et que vous mettez simplement à jour quelques-unes des variables, vous n’avez pas besoin de passer par le processus fastidieux d’ajout de variables une par une. Vous pouvez maintenant rapidement effectuer 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.

Ignorer une gate de mise en production pour un déploiement

Les gates de publication permettent l’évaluation automatique des critères d’état de santé avant qu’une mise en production soit promue vers l’environnement suivant. Par défaut, le pipeline de mise en production progresse uniquement lorsque tous les contrôles sont sains en même temps. Dans certaines situations, par exemple lors de l’accélération d’une mise en production ou après vérification manuelle de l’état de santé, un approbateur peut ignorer un gate et autoriser la mise en production à progresser même si ce gate n’a pas encore été évalué comme sain. Consultez la documentation sur les release gates pour plus d’informations.

Effectuer des tests supplémentaires à l’aide d’un déclencheur de publication de pull request

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

Créer une connexion au service Azure avec un principal de service qui effectue l’authentification 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 de service Azure prenant désormais en charge le principal de service qui s’authentifie avec un certificat, vous pouvez désormais 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.

L’exécution à partir du package est prise en charge dans les déploiements Azure App Service

La version de la tâche Azure App Service Deploy (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 (aka WebDeploy), git, ARM et bien plus encore. Mais toutes ces techniques ont une limitation. Vos fichiers sont déployés sous votre dossier wwwroot (en particulier d :\home\site\wwwroot) et le runtime exécute ensuite les fichiers à partir de là.

Avec Run From Package, il n’existe plus d’étape de déploiement qui copie les fichiers individuels dans wwwroot. Au lieu de cela, vous pointez simplement vers un fichier zip, et le fichier zip est monté sur wwwroot en tant que système de fichiers en lecture seule. Cela a plusieurs avantages :

• Réduit le risque de verrouillage lors de la copie de fichiers.
• Déploiement possible sur une application de production (avec redémarrage)
• Vous pouvez être certain des fichiers qui sont exécutés dans votre application.
• Améliore les performances des déploiements 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 App Server Deploy

La version 4.* de la tâche Azure App Service Deploy 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 Docker qui offrent une plus grande flexibilité en termes d’empaquetage et d’exploitation des dépendances spécifiques à l’application. Les fonctions sur Linux peuvent être hébergées dans 2 modes différents :

1. Image de conteneur intégrée : vous apportez le code de l’application de fonction et Azure fournit et gère le conteneur (mode image intégré), de sorte qu’aucune connaissance spécifique liée à Docker n’est requise. Cela est pris en charge dans la version existante de la tâche De déploiement App Service.
2. Image conteneur personnalisée : nous avons amélioré la tâche De déploiement App Service pour prendre en charge le déploiement d’images conteneur personnalisées sur Azure Functions sur Linux. Lorsque vos fonctions ont besoin d’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 générer et déployer une image personnalisée sur Azure Function sur Linux à l’aide d’Azure Pipelines.

La tâche Xcode prend en charge Xcode 10, récemment publié

Avec la sortie de Xcode 10 par Apple, 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 travaux en parallèle avec une matrice de versions Xcode. Vous pouvez utiliser le pool d’agents macOS hébergé par Microsoft pour exécuter ces builds. Consultez les instructions relatives à l’utilisation de Xcode dans Azure Pipelines.

Simplifiez le déploiement sur Kubernetes à l’aide de Helm

Helm est un outil qui simplifie l’installation et la gestion des applications Kubernetes. Il a également gagné beaucoup de popularité et de soutien communautaire au cours de l’année dernière. Une tâche Helm dans Release est désormais disponible pour empaqueter et déployer des graphiques Helm sur Azure Container Service (AKS) ou tout autre cluster Kubernetes.

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

Contrôler la version de Helm utilisée dans la Release

La tâche Helm Tool Installer acquiert une version spécifique de Helm à partir d’Internet ou du cache des outils et l’ajoute au PATH 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 .NET Core CLI. L’ajout de cette tâche avant la tâche Helm Deploy dans une définition de build ou de mise en production garantit l’empaquetage et le déploiement de votre application avec la version Helm appropriée. Cette tâche permet également d’installer éventuellement l’outil kubectl, qui est un prérequis pour que Helm fonctionne.

Déployer en continu sur Azure Database pour MySQL

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

Utiliser des tâches Windows distantes basées sur PowerShell améliorées

Des tâches nouvelles et améliorées basées sur Windows PowerShell à distance 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.

Tâche PowerShell sur cible (version : 3.*) : vous pouvez ajouter un script inline, modifier des options PSSession, contrôler « ErrorActionPreference » et échouer en cas de sortie sur stderr.

Tâche de copie de fichiers Azure (version : 2.*) : fournie avec la dernière version d’AzCopy (v7.1.0) qui résout un problème GitHub.

Filtrer des branches pour GitHub Enterprise ou des artefacts Git externes

Lorsque vous effectuez une publication depuis GitHub Enterprise ou des dépôts Git externes, vous pouvez maintenant configurer les branches spécifiques qui seront publiées. Par exemple, vous pouvez déployer uniquement des builds provenant d’une branche spécifique en production.

Compiler des applications écrites en Go

Utilisez la tâche Go Tool Installer pour installer une ou plusieurs versions de Go Tool à la volée. Cette tâche récupère une version spécifique de Go Tool nécessaire à votre projet et l’ajoute au CHEMIN d’accès de l’agent de build. Si la version de l’outil Go ciblé est déjà installée sur l’agent, cette tâche ignore le processus de téléchargement et d’installation à nouveau.

La tâche Go vous permet de télécharger des dépendances, de générer ou de 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 Python Script simplifie l’exécution de scripts Python dans votre pipeline. La tâche exécutera 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, à enregistrer comme faisant partie de votre pipeline. La tâche utilise la version de Python dans le PATH, ou vous pouvez spécifier un chemin absolu vers un interpréteur Python à utiliser.

Tirer parti des sorties de compilation et de test Xcode améliorées à partir 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 de l’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 rendons les journaux xcodebuild complets disponibles avec chaque build.

Plans de test

Client Test Runner (Plans de test Azure) pour exécuter des tests manuels d’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 aidera à 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 audio et vidéo. 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 (Plans de test Azure) nécessite un téléchargement unique et une installation du runner. Sélectionnez Exécuter pour l’application de bureau, comme indiqué ci-dessous.

Artefacts

Sources en amont

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

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

Nous avons également introduit un nouveau rôle dans Azure Artifacts : « Collaborateur ». Un collaborateur peut enregistrer des packages à partir d’une source en amont, mais ne peut pas publier des packages directement dans le flux de package (par exemple, en utilisant `nuget publish`). Cela vous permet de limiter la publication de packages à 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 en amont.

Suivre les paquets

Nous avons rendu la configuration des notifications encore plus facile grâce à un nouveau bouton Suivre directement sur chaque colis. Le bouton Suivi est également compatible avec les vues de mise en production. Si vous suivez un package tout en l’examinant via une vue, vous obtiendrez uniquement des mises à jour pour les nouvelles versions promues à cette vue.

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

Quelques-unes des interactions sur la page des paramètres de flux ont été améliorées. À présent, les modifications que vous apportez, telles que l’ajout d’un upstream ou d’une autorisation, sont enregistrées immédiatement. Cela signifie que vous n’avez pas à vous soucier de perdre des modifications lorsque vous basculez entre les sections des paramètres.

Simplifiez l'authentification à l'aide du nouveau Credential Provider multiplateforme de NuGet

L’utilisation des flux NuGet authentifiés s’est nettement améliorée. Le nouveau Azure Artifacts Credential Provider 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 acquiert 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 de service, accédez à GitHub et suivez les instructions pour votre client et votre plateforme.

Compressez les symboles de débogage lors de la publication sur un partage de fichiers

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

Wiki

Publier des fichiers Markdown à partir d’un dépôt Git en tant que Wiki

Les développeurs créent de la documentation pour les « API », les kits de développement logiciel (SDK) et les « documents d’aide expliquant le code » dans les dépôts de code. Les lecteurs doivent ensuite parcourir le code pour trouver la documentation appropriée. Vous pouvez maintenant simplement publier des fichiers Markdown à partir de référentiels de code et les héberger dans Wiki.

À partir du Wiki, commencez par cliquer sur Publier le code en tant que wiki. Ensuite, vous pouvez spécifier un dossier d’un dépôt Git à promouvoir.

Une fois que vous avez cliqué sur Publier, tous les fichiers markdown sous le dossier sélectionné seront publiés en tant que wiki. Cela associe également le HEAD de la branche au wiki afin que les modifications que vous apportez au référentiel Git soient immédiatement reflétées.

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

Lien vers des titres sur une page

Vous pouvez maintenant cliquer sur l’icône de lien en regard de n’importe quel titre de section d’une page wiki pour générer une URL directement vers cette section. Vous pouvez ensuite copier cette URL et la partager avec les membres de l’équipe pour les diriger directement vers cette section.

Joindre des fichiers et des images dans des dossiers

Lors de la modification des pages wiki hors connexion, il peut être plus facile d’ajouter des pièces jointes et des images 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.

Intégrez une vidéo dans un wiki

Vous pouvez maintenant incorporer des vidéos dans une page wiki à partir de services en ligne telles que Microsoft Stream et YouTube. Vous pouvez ajouter l’URL 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>
:::

Renommer un wiki

Vous pouvez maintenant renommer votre wiki dans l’interface utilisateur wiki et à l’aide d’API REST. Dans le menu Plus , cliquez sur Renommer le wiki pour donner un nom mémorable à votre 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 simplement appuyer sur Ctrl + clic gauche sur une page wiki pour l’ouvrir dans un nouvel onglet.

Conserver des caractères spéciaux dans les titres de page Wiki

Vous pouvez maintenant créer des pages wiki avec des caractères spéciaux tels que : < > * ? | -. Maintenant, les pages avec des titres tels que « FAQ ? » Sinon, un « Guide de configuration » peut être créé dans Wiki. Les caractères suivants sont traduits en chaînes codées en UTF-8 :

Afficher les liens rompus

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

Corriger les liens rompus lors du déplacement de pages

Les liens de page rompus sont l’une des principales causes d’une mauvaise qualité de page dans n’importe quelle solution de documentation. Précédemment dans Wiki, lorsque vous déplaciez une page dans l’arborescence ou renommiez une page, cela pouvait potentiellement interrompre les liens vers la page à partir d’autres pages et éléments de travail. À présent, vous pouvez rechercher et corriger les liens avant qu’ils ne soient rompus.

Lorsque vous renommez ou déplacez une page, vous serez invité à vérifier les liens absolus ou relatifs affectés.

Vous verrez ensuite une liste des liens vers des pages et des éléments de travail affectés avant de prendre des mesures.

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

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

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.

Pour plus d’informations sur l’utilisation de Markdown dans Azure DevOps, consultez la documentation de markdown .

Afficher les métadonnées 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 et à exposer du contenu significatif. Dans cette mise à jour, tout fichier qui contient un bloc YAML au début du fichier sera transformé en une table de métadonnées composée d’un en-tête et d’une ligne. Le bloc YAML doit prendre la forme d’un ensemble YAML valide délimité par des lignes de trois tirets. Il prend en charge tous les types de données de base, les listes et les objets comme valeurs. La syntaxe est prise en charge dans Wiki et dans l’aperçu des fichiers de code.

Exemple de balises YAML:

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

Exemple de balises YAML avec liste :

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

Publier le code sous forme de wiki avec les autorisations de contribution

Auparavant, seuls les utilisateurs disposant de l’autorisation Créer un référentiel sur un dépôt Git pouvaient publier du code en tant que wiki. Cela a rendu les administrateurs de référentiel ou les créateurs un goulot d’étranglement pour toutes les demandes de publication de fichiers Markdown hébergés dans des dépôts git en tant que wikis. À présent, vous pouvez publier le code comme wiki si vous disposez simplement de l’autorisation Contribuer sur le référentiel de code.

Reporting

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

L’extension Place de marché Analytics est désormais disponible pour Azure DevOps Server. L’analytique est l’avenir de la création de rapports pour Azure DevOps et Azure DevOps Server. L’installation de l’extension Analytics fournit des widgets avancés, l’intégration de Power BI et l’accès à OData.

Pour plus d’informations, consultez What is Analytics et la Reporting Roadmap. Analytics est disponible en préversion publique. Il contient actuellement des données pour Boards et les résultats des tests automatisés via Pipelines. Consultez les données disponibles dans Analytics Service.

Examiner l’historique des compilations via un nouveau widget de tableau de bord de compilation

Nous avons un widget d’historique de build nouveau et 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 sur votre tableau de bord et le configurer sur un projet public pour les visiteurs anonymes.

Commentaires

Nous sommes à votre écoute ! Vous pouvez signaler un problème ou soumettre une idée et en suivre le traitement via Developer Community et obtenir des conseils sur Stack Overflow.