Notes de publication Azure DevOps Server 2019

| Developer Community Conditionsdu contrat de licence | Requises | système Blog | DevOps SHA-1 Hachages

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 Azure DevOps Server. Pour télécharger des produits Azure DevOps, visitez la page Azure DevOps Server Téléchargements.

La mise à niveau directe vers Azure DevOps Server 2020 est prise en charge à partir de Azure DevOps Server 2019 ou de Team Foundation Server 2015 ou version ultérieure. Si votre déploiement TFS est 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 plus d’informations, consultez Installer et configurer Azure DevOps en local.

---

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

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

Azure DevOps Server 2020 gère différemment la rétention des builds, en fonction des stratégies de rétention au niveau du pipeline. Certaines configurations de stratégie 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 version ne seront pas supprimées après la mise à niveau.

Lisez notre billet de blog pour plus d’informations sur la mise à niveau en toute sécurité de Azure DevOps Server 2019 à Azure DevOps Server 2020.

Azure DevOps Server 2019.0.1 Patch 16 Date de publication : 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 tâches PowerShell autorisées pour la validation des paramètres Activer les tâches de l’interpréteur de commandes.

Notes

Pour implémenter des correctifs pour ce correctif, vous devez suivre un certain nombre d’étapes pour mettre à jour manuellement les tâches.

Installer les correctifs

Important

Nous avons publié des mises à jour de l’agent Azure Pipelines avec le correctif 15 publié le 12 septembre 2023. Si vous n’avez pas installé les mises à jour de l’agent comme décrit dans les notes de publication du correctif 15, nous vous recommandons d’installer ces mises à jour avant d’installer le correctif 16. La nouvelle version de l’agent après l’installation du correctif 15 sera 3.225.0.

Configurer TFX

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

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

Fichier	Hachage SHA-256
Tasks20231103.zip	389BA66EEBC32622FB83402E21373CE20AE040F70461B9F9AF9EFCED5034D2E5

1. Téléchargez et extrayez Tasks20231103.zip.
2. Remplacez le répertoire par les 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 

Configuration requise du 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.

• Sur classique :

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

• Exemple YAML :

variables: 
- name: AZP_75787_ENABLE_NEW_LOGIC 
  value: true 

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

Nous avons publié un correctif pour Azure DevOps Server 2019.0.1 qui corrige les problèmes suivants.

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

Important

Déployez le correctif dans un environnement de test et assurez-vous que les pipelines de l’environnement fonctionnent comme prévu avant d’appliquer le correctif en production.

Notes

Pour implémenter des correctifs pour ce correctif, vous devez suivre un certain nombre d’étapes pour mettre à jour manuellement l’agent et les tâches.

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 sur les agents Windows auto-hébergés pour déployer l’agent.  

Notes

Le AZP_AGENT_DOWNGRADE_DISABLED doit être défini sur « true » pour empêcher la rétrogradé de l’agent. Sur Windows, la commande suivante peut être utilisée dans une invite de commandes d’administration, suivie d’un redémarrage. setx AZP_AGENT_DOWNGRADE_DISABLED true /M

Configurer TFX

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

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

1. Téléchargez et extrayez Tasks_20230825.zip.
2. Remplacez le répertoire par les 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 

Configuration requise du 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.

• Sur classique :

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

• Exemple YAML :

variables: 
- name: AZP_75787_ENABLE_NEW_LOGIC 
  value: true 

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

Nous avons publié un correctif pour Azure DevOps Server 2019.0.1 qui corrige les problèmes suivants.

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

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

Nous avons publié un correctif pour Azure DevOps Server 2019.0.1 qui corrige les problèmes suivants.

• Révoquez tous les jetons d’accès personnels une fois le compte Active Directory d’un utilisateur désactivé.

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

Nous avons publié un correctif pour Azure DevOps Server 2019.0.1 qui corrige les problèmes suivants.

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

Procédure d’installation :

1. Mettez à niveau le serveur avec le correctif 12.
2. Vérifiez la valeur du Registre à l’adresse HKLM:\Software\Elasticsearch\Version. Si la valeur de Registre n’existe pas, ajoutez une valeur de 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 update comme indiqué dans le fichier lisez-moi. Il peut renvoyer un avertissement du type : Impossible de se connecter au serveur distant. Ne fermez pas la fenêtre, car la mise à jour effectue de nouvelles tentatives jusqu’à ce qu’elle soit terminée.

Notes

Si Azure DevOps Server et Elasticsearch sont installés sur des ordinateurs différents, suivez les étapes décrites ci-dessous.

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

Hachage SHA-256 : 96C7AF3E3ED67C76451BA228427B3C0738EEB4A5835B6A91EBD3205A54C384D7

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

Nous avons publié un correctif pour Azure DevOps Server 2019.0.1 qui corrige les problèmes suivants.

• Correction de l’erreur d’interface utilisateur de définition de build.

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

Nous avons publié un correctif pour Azure DevOps Server 2019.0.1 qui corrige les problèmes suivants.

• CVE-2021-27067 : Divulgation d’informations

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

Installation de la tâche AzureResourceGroupDeploymentV2

Notes

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

Installer

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

2. Téléchargez et installez Node.js 14.15.1 et npm (inclus 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 total 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 charger la tâche sur le serveur. Utilisez le chemin du fichier .zip extrait à l’étape 1.

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

Azure DevOps Server 2019.0.1 Patch 9 Date de publication : 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 : Azure DevOps Server vulnérabilité d’usurpation d’identité
• CVE-2020-17135 : Azure DevOps Server vulnérabilité d’usurpation d’identité
• CVE-2020-17145 : vulnérabilité d’usurpation d’identité Azure DevOps Server et Team Foundation Server
• Résolution du problème lié au traitement de tous les résultats par TFVC

Important

Lisez les instructions complètes fournies ci-dessous avant d’installer ce correctif.

Installation corrective générale

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

Vérification de l’installation

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

• Option 2 : Vérifiez la version du fichier suivant : [INSTALL_DIR]\Azure DevOps Server 2019\Application Tier\Web Services\bin\Microsoft.VisualStudio.Services.Feed.Server.dll. Azure DevOps Server 2019 est installé c:\Program Files\Azure DevOps Server 2019 sur 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

Notes

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

Prérequis

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

2. Créez un pipeline avec la tâche AzurePowerShellV4 . Vous ne verrez qu’une seule erreur d’échec sur l’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 total 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 charger la tâche sur le serveur. Le chemin d’accès du package extrait est D :\tasks (1)\AzurePowerShellv4.

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

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

Nous avons publié un correctif de sécurité pour Azure DevOps Server 2019.0.1 qui corrige ce qui suit. 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é.

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

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

• CVE-2020-1326 : Vulnérabilité de script intersite
• Le pipeline de build affiche une connexion incorrecte pour les utilisateurs non autorisés lors de la sélection d’une autre source Git.
• Correction de l’erreur lors de la modification de l’héritage sur Activé ou Désactivé dans la définition de build XAML.

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

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

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

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

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

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

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

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

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

---

Azure DevOps Server 2019.0.1 Patch 2 Date de publication : 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 par défaut pour tous les pipelines.

---

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

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

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

---

Azure DevOps Server 2019.0.1 Date de publication : 21 mai 2019

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

Notes

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

Cette version inclut les corrections des bugs suivants :

Azure Boards

• « Les critères de champ de ce plan ont une erreur . » lors de la configuration d’un plan. Signalé via 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 utilisant l’étendue oauth vso.work_full, WorkItemServer.DownloadFile() échoue.
• La copie d’une image incorporée 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 cassée.

Azure Repos

• « TF401019 : GitRepositoryNotFoundException ».

Azure Pipelines

• L’onglet Analyse de test a un star (*) qui indique la préversion, même si cette fonctionnalité n’est pas en préversion.
• Sous l’onglet Mises en production , l’action de gestion de la sécurité s’affiche désormais à tous les utilisateurs, qu’ils puissent ou non modifier les autorisations.
• Dans les pages d’accueil Mises en production, l’action démarrer le brouillon de mise en production créait une nouvelle version, mais elle démarre maintenant la version préliminaire.

Azure Test Plans

• Le filtre d’une heure sur TestRuns et TestResults CompletedDate est trop granulaire.
• Dans le type d’élément de travail Cas de test, le type « Cas de test » ne doit pas être localisé.
• Les cas de test n’apparaissent pas dans MTM ou dans un navigateur.
• Erreur « Phase de validation : vous n’avez pas l’autorisation de déclencher des mises en production sur le pipeline de mise en production associé » lors de l’exécution de tests automatisés à partir d’un plan de test. Signalé via 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é via 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.
• Cas de test status 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 de l’utilisateur dans Test Runner.

Azure Artifacts

• Déplacer vers le haut et descendre ne sont pas localisés dans Amonts.

Analytics

• Les rapports d’analyse peuvent afficher des données incomplètes, car le modèle est marqué comme « prêt » avant d’être réellement terminé.
• Les widgets vitesse, burndown et burnup affichent différents travaux planifiés pour les utilisateurs sur différents fuseaux horaires.
• Une conservation peut être placée sur l’ingestion de 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

• Une journalisation supplémentaire a été ajoutée à la mise à niveau du regroupement pour faciliter le débogage des problèmes.
• Lorsque TfsConfig offlineDetach échoue, le message d’erreur ne peut pas être 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 dans les résultats des pages de recherche.

Cette version inclut 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 Dernière ou Visual Studio 2019 dans la liste déroulante Version de la plateforme de test.

---

Azure DevOps Server 2019 Patch 2 Date de publication : 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é liée aux scripts intersites (XSS) dans Test Plans
• CVE-2019-0971 : Vulnérabilité sur la divulgation d’informations dans l’API Repos
• CVE-2019-0979 : Vulnérabilité liée aux scripts intersites (XSS) dans le hub Utilisateur

---

Azure DevOps Server 2019 Patch 1 Date de publication : 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 les 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 les pipelines
• CVE-2019-0875 : Vulnérabilité d’élévation de privilèges dans les tableaux

---

date de publication Azure DevOps Server 2019 : 5 mars 2019

Notes

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

---

Date de publication RC2 : 22 janvier 2019

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

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

• Lier des validations et des demandes de tirage GitHub Enterprise à 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 branche amélioré
• Modifications apportées aux licences d’artefacts et de pipeline de déploiement Release Management

---

Date de publication RC1 : 19 novembre 2018

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

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 de la base de données Azure SQL
• Traiter l’héritage sur les nouvelles collections
• Hub Nouveaux éléments de travail
• Nouveaux hubs de tableaux, de backlogs et de sprints
• Hub Nouvelles requêtes
• Normaliser les descriptions des demandes de tirage à l’aide de modèles
• Modifier la branche cible d’une demande de tirage
• 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 les déploiements à l’aide de portes de mise en production
• Sources en amont
• Créer une table des matières pour les pages wiki

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

• Généralités
• Boards
• Repos
• Pipelines
• Test Plans
• Artefacts
• Wiki
• Rapports

---

Général

Annonce de Azure DevOps Server

Le 10 septembre, nous avons annoncé Azure DevOps comme l’évolution de Visual Studio Team Services et Team Foundation Server. Azure DevOps Server 2019 est notre première version locale 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 a été 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’artefacts et de pipeline de déploiement Release Management

Sur la base des commentaires des utilisateurs, nous apportons deux modifications clés à nos licences avec Azure DevOps Server 2019. Tout d’abord, les clients n’auront plus besoin d’acheter l’extension Artifact pour utiliser Artifacts. Une utilisation de licence Artifacts sera désormais incluse dans la licence de base. Tous les utilisateurs auxquels une licence de base est affectée pourront désormais utiliser artifacts. Deuxièmement, les clients ne seront plus tenus d’acheter Release Management pipelines de déploiement. Tout comme les pipelines de build, les pipelines de déploiement Release Management sont désormais inclus dans Azure DevOps Server 2019.

Prise en charge de la base de données Azure SQL

Afin de simplifier l’expérience d’exécution d’Azure DevOps 2019 dans Azure, nous avons activé la prise en charge de Azure SQL Database (usage général S3 et versions ultérieures). Cela vous permettra de tirer parti des fonctionnalités de sauvegarde étendues et des options de mise à l’échelle 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 une latence faible. Pour plus d’informations, consultez la documentation .

Élément de travail & tester les API SOAP du modèle objet client dans les versions ultérieures

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, il sera marqué comme déprécié dans les versions ultérieures de Azure DevOps Server. Vous trouverez plus d’informations dans notre documentation.

Traiter 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 en conscience sur le modèle de processus lors de la création d’une collection. Consultez notre documentation sur ce qu’est le modèle d’héritage et comment il est différent de XML.

Zone de recherche développée

Nous comprenons l’importance de la recherche et rétablissons la zone de recherche développée sur l’en-tête de produit. En outre, vous pouvez maintenant appeler la zone de recherche en cliquant simplement sur « / » sur n’importe quelle page de service dans Azure DevOps.

Voici la zone de recherche par défaut :

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

Menu volant mon travail

Une nouvelle fonctionnalité que nous sommes très heureux de présenter est le menu volant my work . Nous avons entendu des commentaires selon lesquels lorsque vous êtes dans une partie du produit et que vous souhaitez obtenir des informations d’une autre partie, vous ne voulez pas perdre votre contexte. Avec cette nouvelle fonctionnalité, vous pouvez accéder à ce menu volant à partir de n’importe où dans le produit, et il vous donnera un aperçu rapide des informations cruciales, y compris vos éléments de travail, les demandes de tirage et tous les favoris. Avec ce nouveau menu volant, si vous êtes dans Repos têtes vers le bas dans votre code, mais que vous souhaitez case activée rapidement l’élément de travail sur lequel vous devez travailler ensuite, vous pouvez simplement cliquer sur le menu volant et voir les éléments de travail qui vous ont été attribués et sélectionner l’élément suivant.

Ci-dessous, vous pouvez voir le menu volant Mon travail montrant les éléments de travail qui m’ont été attribués :

Ici, vous pouvez voir le deuxième tableau croisé dynamique qui montre les demandes de tirage qui m’ont été attribuées. Dans le menu volant, vous disposez également d’un accès en un clic pour afficher d’autres demandes de tirage :

Ici, vous pouvez voir le dernier tableau croisé dynamique, qui est tout ce que vous avez préféré. Cela inclut vos équipes, tableaux de bord, tableaux de bord, backlogs, requêtes et référentiels favoris :

Boards

Lier des validations et des demandes de tirage GitHub Enterprise à des éléments de travail Azure Boards

Les équipes qui utilisent GitHub Enterprise pour le code et qui souhaitent 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 de sprint, plusieurs types d’éléments de travail, tout en conservant un flux de travail qui s’intègre aux flux de travail des développeurs dans GitHub.

Il est facile de lier des commits et des demandes de tirage à des éléments de travail. Mentionnez l’élément de travail à l’aide de la syntaxe suivante :

AB#{work item ID}

Mentionnez un élément de travail dans un message de validation, un titre de demande de tirage ou une description de demande de tirage, et Azure Boards créez 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îtra dans la section Développement de l’élément de travail. ​

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

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

Hub Nouveaux éléments de travail

Le hub d’éléments de travail est notre nouveau hub qui servira d’accueil à vos éléments de travail ! Ici, vous avez de nombreux affichages de liste différents de vos éléments de travail qui sont limités pour vous. Vous pouvez afficher Affecté à moi pour obtenir rapidement un aperçu de tout le travail qui vous est affecté ou Récemment mis à jour qui affiche tous les éléments de travail de votre projet qui ont été mis à jour les plus récemment. Toutes les options de liste sont disponibles ci-dessous :

Si vous souhaitez étendre vos listes encore plus loin, vous pouvez filtrer sur le type, l’affectation, l’état, la zone, les balises et mot clé. Une fois que vous avez l’affichage de liste souhaité, vous pouvez trier les éléments de travail en cliquant simplement sur l’en-tête de la colonne. Si une colonne est trop étroite pour que vous puissiez 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 de tableaux, de backlogs et de 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 rendait souvent difficile la recherche de la fonctionnalité ou de la fonctionnalité recherchée par les utilisateurs. Pour résoudre ce problème, nous avons divisé le hub Backlogs en :

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

Hub Nouvelles requêtes

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

• Pages d’annuaire avec la dernière modification par les informations et la possibilité de rechercher des requêtes
• Barre de navigation avec des URL uniques pour les dossiers afin de créer des signets de requêtes importants
• Accès rapide à vos requêtes préférées à partir de la page de résultats

Pour en savoir plus sur ces mises à jour passionnantes, consultez notre blog DevOps.

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

Vous pouvez maintenant modifier le type d’élément de travail ou déplacer 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 de sprint

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

• Créez votre prochain sprint ou abonnez-vous à une planification de sprint existante directement à partir du hub Sprints .
• Utilisez le nouveau volet Planification de votre backlog pour glisser-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 les exigences en haut du tableau des tâches 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 l’attribut, le type d’élément de travail, l’état et les étiquettes pour adapter les vues à vos besoins.

Nouvelles pages d’annuaire

Tous les nouveaux hubs, y compris les backlogs, les tableaux etles sprints, ont désormais de nouvelles pages d’annuaire organisées avec les sections suivantes :

• Continuez là où vous vous étiez arrêté Cette nouvelle section vous fournit un lien rapide directement vers la dernière (Conseil | Backlog | Sprint) vous étiez sur.
• Favoris Tous vos tableaux favoris, sprints et backlogs dans toutes les équipes.
• Mon Tous les tableaux, backlogs et sprints pour les équipes auxquelles vous appartenez.
• Tous Liste complète de tous vos tableaux, backlogs et sprints.

Menu Nouvelles options d’affichage

Les nouveaux hubs, notamment Backlogs, Tableaux et Sprints, ont un nouveau menu Options d’affichage . Il s’agit d’une nouvelle page d’accueil pour toutes les actions permettant de personnaliser la mise en page et le contenu de la page. Utilisez les 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 Group By sur 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 du travail.

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

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

Les annotations de carte sont appréciées pour leur interaction et leur affichage de liste intuitifs case activée. Auparavant, les annotations carte étaient limitées aux types de niveau 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 carte.

Les paramètres de tableau pour carte annotations ont été développés 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 le carte en tant que liste case activée distincte.

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

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

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

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

Travail de requête 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 le décalage entier. Gardez facilement des onglets sur le travail qui n’a pas été fermé avec @CurrentIteration - 1, ou examinez le travail prévu pour les itérations futures avec @CurrentIteration + 1. Pour plus d’informations, consultez le billet de @CurrentIteration sur le blog Microsoft DevOps.

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

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

Travail de requête dans les chemins de zone d’une équipe avec la nouvelle @TeamAreas macro

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 de bord, les plans et même les tableaux de bord uniquement sur le travail de cette équipe. Si vous souhaitez écrire une requête pour une équipe, vous devez toutefois répertorier les chemins d’accès de zone spécifiques pour cette équipe dans les clauses de requête. Maintenant, une nouvelle macro @TeamAreas est disponible pour vous permettre de référencer facilement les chemins d’accès de zone appartenant à l’équipe spécifiée.

Requête de 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 expériences de liaison et de mention

Lorsque vous souhaitez lier deux éléments de travail existants ensemble, vous pouvez désormais facilement trouver l’élément qui 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 des éléments de travail à partir de la recherche

Auparavant, un élément de travail ne pouvait pas être ouvert à partir de la page des résultats de recherche si le volet d’aperçu de l’élément de travail était désactivé. Cela rendrait difficile d’explorer les résultats de votre recherche. Vous pouvez maintenant cliquer sur le titre de l’élément de travail pour ouvrir les éléments de travail dans une fenêtre modale.

Repos

Sélecteur de branche 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 disposant d’un grand nombre de branches, nous déployons un nouveau sélecteur de branches. Le sélecteur vous permet désormais de sélectionner vos branches favorites ou de rechercher rapidement une branche.

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

Pour les équipes qui utilisent des demandes de tirage (PRs) et des stratégies de branche, il peut arriver que des utilisateurs doivent remplacer et contourner ces stratégies, par exemple, lors du déploiement d’un correctif logiciel sur un problème de production au milieu de la nuit. Il est logique de faire confiance aux développeurs pour faire ce qui convient 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 remplacements de stratégie sont utilisés dans les situations appropriées. Pour cela, 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 stratégie 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 Stratégies ont été ignorées comme valeur et vous serez averti chaque fois qu’une demande de tirage est terminée, et les stratégies sont ignorées.

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

Il existe de nombreux scénarios dans lesquels vous avez parfois besoin de contourner une stratégie de branche : restauration d’une modification qui a provoqué un arrêt de build, application d’un correctif logiciel au milieu de la nuit, etc. Auparavant, nous proposions une autorisation (« Exempt de l’application de stratégie ») pour aider les équipes à gérer les utilisateurs qui avaient la possibilité de contourner les stratégies de branche lors de l’exécution d’une demande de tirage. Toutefois, cette autorisation a également accordé la possibilité d’envoyer directement à la branche, en contournant entièrement le processus de demande de tirage.

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

1. Contourner les stratégies lors des demandes de tirage. Les utilisateurs disposant de cette autorisation pourront utiliser l’expérience « Remplacer » pour les demandes de tirage.
2. Contourner les stratégies lors de l’envoi. Les utilisateurs disposant de cette autorisation pourront envoyer directement à des branches dont les stratégies requises sont configurées.

En accordant la première autorisation et en refusant la seconde, un utilisateur peut utiliser l’option de contournement si nécessaire, mais il dispose toujours de la protection contre l’envoi par push accidentel à une branche avec des stratégies.

Notes

Cette modification n’introduit aucune modification de comportement. Les utilisateurs qui avaient précédemment accordé l’autorisation « Exempt de l’application de stratégie » se verront accorder l’autorisation pour les deux nouvelles autorisations, de sorte qu’ils pourront à la fois remplacer l’achèvement sur les demandes de tirage et envoyer directement aux branches avec des stratégies.

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

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

L’écriture de messages de validation descriptifs ajoute de la valeur à l’historique de tout dépôt Git. Pour encourager les messages de validation de qualité, les nouvelles demandes de tirage (TIRAGE) qui ont plusieurs validations obligent les contributeurs à entrer un titre manuellement.

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

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

Lorsque nous avons lancé l’expérience de demande de tirage (TIRAGE), nous avons pensé qu’il était judicieux d’affecter toutes les demandes de tirage au contexte d’équipe que vous aviez sélectionné lors de la création de la demande de tirage. Ce comportement a été un point de frustration, car de nombreuses personnes n’ont pas remarqué la connexion entre le contexte d’équipe et l’affectation de demande de tirage.

Dans le cadre des nouvelles modifications de navigation, nous avons profité de l’occasion pour modifier cette association par défaut avec les équipes. Vous remarquerez deux changements :

1. Lors de la création d’une demande de tirage, aucun réviseur n’est ajouté par défaut. La liste des réviseurs dispose d’une fonctionnalité qui facilite l’ajout d’individus et de groupes récemment ajoutés aux demandes de tirage. 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 Demandes de tirage a une nouvelle section personnalisable. Par défaut, cette section affiche les demandes de tirage « Attribuées à mes équipes », ce qui fournit des fonctionnalités équivalentes à celles de l’ancienne section. Toutefois, si vous appartenez à plusieurs équipes, cette section affiche les demandes de tirage 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 demandes de tirage à l’aide de modèles

L’écriture de descriptions de bonnes demandes de tirage 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. Beaucoup d’entre vous ont demandé que nous ajoutions des modèles de demande de tirage pour faciliter l’écriture de descriptions de qualité pour les équipes, et nous avons maintenant ajouté cette fonctionnalité.

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

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

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

Modifier la branche cible d’une demande de tirage

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

Au-delà de la simple correction des erreurs, la fonctionnalité de modification des branches cibles permet également de « recibler » facilement une demande de tirage lorsque la branche cible a été fusionnée ou supprimée. Envisagez un scénario où vous avez une demande de tirage ciblant une branche de fonctionnalité qui contient certaines fonctionnalités dont vos modifications dépendent. Vous souhaitez passer en revue vos modifications dépendantes à l’isolement des autres modifications apportées au branche de fonctionnalité, de sorte que vous ciblez features/new-featureinitialement . Les réviseurs peuvent alors voir uniquement vos modifications et laisser les commentaires appropriés.

Maintenant, réfléchissez à ce qui se passerait si le branche de fonctionnalité avait également une demande de tirage active et qu’elle était fusionnée dans main avant vos modifications ? Auparavant, vous devrez abandonner vos modifications et créer une nouvelle demande de tirage dans main, ou fusionner votre demande de tirage dans features/new-feature, puis créer une autre demande de tirage à partir de features/new-feature à main. Avec cette nouvelle action de mise à jour de la branche cible, vous pouvez simplement changer la branche cible de la demande de features/new-feature tirage en main, en conservant tous les contextes et commentaires. La modification de la branche cible crée même une nouvelle mise à jour de la demande de tirage, ce qui facilite l’analyse des différences antérieures avant le changement de branche cible.

Les auteurs d’extensions peuvent interroger le contexte sur le dépôt actuel

L’un des défis pour un auteur d’une extension de contrôle de version est d’obtenir le contexte du dépôt affiché à l’utilisateur, tel que le nom, l’ID et l’URL. Pour y remédier, nous avons ajouté le service VersionControlRepositoryService en tant que service accessible par l’extension. Grâce à cela, un auteur d’extension peut interroger des informations sur le contexte de dépôt Git actuel au sein de l’interface utilisateur web. Il dispose actuellement d’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 dépôt TFVC est sélectionné ou si le service est accessible en dehors des pages Azure Repos, la valeur Null est retournée.

Voici un exemple d’extension qui utilise ce service.

Pipelines

Gérer 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 actuelles afin que vous puissiez naviguer rapidement dans les builds de votre projet pour voir leurs status. Il inclut également une préversion de l’analyse de test pour le pipeline sélectionné.

Mieux gérer les e-mails de génération et d’achèvement du déploiement à l’aide d’une mise en forme améliorée

Les e-mails de génération et d’achèvement du déploiement ont été mis à jour pour être plus filtrables par les règles de messagerie. Maintenant, la ligne d’objet comprend des informations plus pertinentes en un coup d’œil, le corps contient plus de détails et leur style a été actualisé avec la dernière 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

Dans les builds et les versions, des termes différents 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 pool d’agents et une file d’attente d’agent.

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

Terme précédent	Terme unifié	Signification
Agent hébergé	Agent hébergé par Microsoft	Un agent de génération/mise en production qui s’exécute sur une infrastructure hébergée dans le cloud gérée par Microsoft.
Agent privé	Agent autohébergé	Un agent de génération/mise en production qui s’exécute sur une machine fournie et gérée par vous.
Pool d’agents	Pool d’agents	Ensemble de organization niveau de machines d’agent qui peuvent exécuter des builds ou des versions.
File d’attente de l’agent	Pool d’agents	Ensemble au niveau du projet d’ordinateurs agent capables d’exécuter des builds ou des versions. Il est lié à un pool d’agents de niveau organization.
Définition de build	Pipeline de build	Ensemble d’étapes de génération de bout en bout pour une application.
Build	Build	Une instance d’un pipeline de build en cours d’exécution ou qui a été exécuté.
Phase	Travail	Série de tâches qui s’exécutent séquentiellement ou en parallèle sur un agent. Un pipeline de build ou de mise en production peut contenir un travail ou un graphique de plusieurs travaux.
Définition de mise en production	Pipeline de mise en production	Ensemble d’étapes de mise en production de bout en bout pour qu’une application soit déployée sur différentes étapes.
Libérer	Libérer	Une instance d’un pipeline de mise en production en cours d’exécution ou qui a été exécuté.
Environnement	Étape	Entité logique et indépendante qui représente l’emplacement où vous souhaitez déployer une version générée à partir d’un pipeline de mise en production.
Travail/pipeline simultané	Travail parallèle	Un travail parallèle vous permet d’exécuter un seul travail de build ou de mise en production à la fois dans votre organization. Avec plus de travaux parallèles disponibles, vous pouvez exécuter d’autres travaux de génération et de mise en production en même temps.
Point de terminaison de service	Connexion du service	Groupe de paramètres, tels que les informations d’identification, utilisés pour se connecter à des services externes afin d’exécuter des tâches dans une build ou une version.

Pour plus d’informations, consultez la documentation concepts .

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

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 mise en production que vous libérez souvent sur la gauche. Vous pouvez également rechercher vos pipelines et les favoris.

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

Visualiser la progression de la mise en production

La nouvelle vue progression de la mise en production vous offre des mises à jour en direct de la progression du déploiement et un accès en un clic à 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 met en évidence les détails et les actions appropriés à différentes étapes de la mise en production.

Pipeline, détails de mise en production et environnements

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

Les environnements sont modélisés de manière à aider à comprendre leur status, ainsi que la progression détaillée. À tout moment, vous pouvez accéder aux journaux en cliquant sur le lien status 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 portes. La progression des approbations et des portes s’affiche également dans l’état de l’environnement. Vous pouvez effectuer une action ou afficher d’autres détails en cliquant sur l’icône de condition de l’environnement qui se trouve 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 élément de validation ou 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, avec le focus sur ce qui est actuellement actif.

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

Impact de la mise à niveau vers Azure DevOps Server 2019 sur les tâches suivantes : Copie de fichiers d’ordinateur Windows et PoweShell 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 « Copie de fichiers d’ordinateur Windows » version 1.* et de la tâche « PowerShell sur les machines cibles » version 1.*. Pour que vos pipelines continuent de fonctionner,

• Vous devez basculer vers la tâche « Copie de fichiers de machine Windows » version 2.* et fournir le nom complet de l’ordinateur 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 complet de la machine ou de l’ordinateur, 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 de nouveaux points d’extensibilité pour permettre aux extensions de faire apparaître encore plus d’informations pour un environnement. Pour plus d’informations, consultez la documentation sur les contributions et les extensions.

Configurer des builds à l’aide de YAML

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

Pour prendre en charge plus facilement les pipelines de build basés sur YAML, 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 soient utilisables dans tous les pipelines 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). Dans ce cas, une personne autorisée à utiliser la ressource doit enregistrer explicitement le pipeline dans l’éditeur web après l’ajout d’une référence de ressource au fichier YAML.

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

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

Vous pouvez maintenant déclencher une build après l’achèvement d’une autre build. Les artefacts produits par une build 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 génération.

N’oubliez pas que dans certains cas, une seule build en plusieurs phases peut répondre à vos besoins. Toutefois, un déclencheur d’achèvement de build est utile si vos besoins incluent des paramètres de configuration différents, des options ou une autre équipe pour posséder le 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 de pipelines. Si votre Azure DevOps Server peut se connecter à Internet, les versions plus récentes sont téléchargées automatiquement. Si ce n’est pas le cas, vous devez mettre à niveau manuellement chaque agent. À partir de cette version, vous pouvez configurer votre Azure DevOps Server pour rechercher les fichiers de package de l’agent sur son disque local plutôt qu’à partir d’Internet. Cela vous offre à la fois la flexibilité et le contrôle des versions d’agent que vous mettent à disposition, sans avoir à exposer vos Azure DevOps Server à Internet.

URL de badge nouvelle génération status

Les badges de build incorporés dans la page d’accueil d’un dépôt sont un moyen courant d’afficher l’intégrité du dépôt. Bien que nous disposions de badges de génération 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 amener l’utilisateur à la dernière version 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 status par branche et peut amener les utilisateurs à la dernière version de la branche sélectionnée. Vous pouvez obtenir le Markdown de la nouvelle URL de badge status en sélectionnant l’action de menu Badge d’état dans la page Nouvelles builds.

Pour la compatibilité descendante, nous continuerons également à respecter les ANCIENNEs URL de badge de build.

Ajouter des compteurs de build personnalisés à vos builds

Les compteurs de build permettent de numéroter et d’étiqueter de manière unique les builds. Auparavant, vous pouviez utiliser la variable spéciale $(rev :r) pour ce faire. 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. Vous effectuez cette opération sous l’onglet Variables d’une définition. Cette nouvelle fonctionnalité vous offre plus de puissance des manières suivantes :

• Vous pouvez définir un compteur personnalisé et définir sa valeur initiale. Par instance 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 de numéros 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 instance, 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 les variables définies par l’utilisateur.

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

Nous voulons garantir la stabilité et la sécurité des logiciels dès le début du processus de développement, tout en associant développement, sécurité et opérations. Pour ce faire, nous avons ajouté la prise en charge de Azure Policy.

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

Pour nous conformer aux 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 échouons à la tâche de déploiement du groupe de ressources Azure avec des erreurs liées à la stratégie pertinentes en cas de violations lors du déploiement de modèles ARM.

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

Créer sur des plateformes Linux/ARM et Windows 32 bits

L’agent multiplateforme Azure Pipelines open source a toujours été pris en charge sur Windows, macOS et Linux 64 bits (x64). Avec cette version, nous introduisons 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 non moins importantes, comme le Raspberry Pi, une machine Linux/ARM.

Amélioration des expériences pour les tests dans les pipelines

L’onglet Tests dispose désormais d’une expérience moderne qui vous fournit des informations de test détaillées et contextuelles pour pipelines. La nouvelle expérience fournit une vue de test en cours, une expérience de débogage pleine page, dans l’historique des tests de contexte, un rapport d’exécution de test abandonnée et un 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 une longue période. Il est donc important de voir l’exécution des tests à un moment donné. Avec la vue test In-Progress, vous n’avez plus besoin d’attendre la fin de l’exécution du test pour connaître le résultat du test. Les résultats sont disponibles en quasi temps réel à mesure qu’ils sont exécutés, ce qui vous permet d’effectuer des actions plus rapidement. Vous pouvez déboguer un échec ou abandonner, signaler un bogue ou abandonner le pipeline. La fonctionnalité est actuellement disponible pour le pipeline de génération et de mise en production à l’aide de la tâche de test VS dans la phase Multi Agent, à l’aide de la tâche Publier les résultats des tests ou de la publication des résultats de test à l’aide d’API. À l’avenir, nous prévoyons d’étendre cette expérience pour l’exécution des tests à l’aide d’un agent unique.

La vue ci-dessous montre le résumé des tests In-Progress dans la nouvelle vue de progression de la version, rapportant le nombre total de tests et le nombre d’échecs de test à un moment donné.

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

Afficher les détails du débogage des séries de tests en pleine page

Les messages d’erreur et les traces de pile sont de nature longue et nécessitent suffisamment de biens immobiliers pour afficher les détails pendant le débogage. Pour avoir une expérience de débogage immersif, vous pouvez maintenant étendre la vue de test ou de série de tests en mode pleine page, tout en étant en mesure d’effectuer les opérations de contexte 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 Exécutions pour afficher l’historique des résultats d’un test. Avec la nouvelle expérience, nous mettons l’historique des tests en contexte dans Test Plans onglet pour la génération et la mise en production. Les informations d’historique des tests sont fournies de manière progressive en commençant par la définition ou l’environnement de build actuel pour le test sélectionné, puis par d’autres branches et environnements pour la génération et la mise en production respectivement.

Afficher les tests abandonnés

L’exécution des tests peut abandonner pour plusieurs raisons telles que le code de test incorrect, la source en cours de test et des problèmes environnementaux. Quelle que soit la raison de l’abandon, il est important de diagnostiquer le comportement et d’identifier la cause racine. Vous pouvez maintenant afficher les tests et les séries de tests abandonnés, ainsi que les exécutions terminées dans Test Plans. La fonctionnalité est actuellement disponible pour les pipelines de génération et de mise en production à l’aide de la tâche de test VS dans la phase Multi Agent ou de la publication des résultats de test à l’aide d’API ou d’API. À l’avenir, nous prévoyons d’étendre cette expérience pour l’exécution des tests à l’aide d’un agent unique.

Prise en charge de la traçabilité et des environnements de mise en production des tests 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 mise en production 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 exécutez des tests dans ces environnements, vous pouvez déterminer si un test est réussi dans l’environnement de développement, mais échoue dans l’environnement d’intégration. Vous pouvez savoir s’il passe les paramètres régionaux anglais, mais échoue dans un environnement qui a des paramètres régionaux en turc. Pour chaque environnement, vous trouverez le status du résultat du test le plus récent. Si le test a échoué sur cet environnement, vous trouverez également la version depuis laquelle le test a échoué.

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

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

Précédemment, nous avons introduit la possibilité d’exécuter à nouveau des tests ayant échoué dans la tâche VS Test . Toutefois, nous n’avons signalé que la dernière tentative de 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 du 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 résultats des tests.

Notes

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

Afficher l’analyse des tests dans Pipelines

Le suivi de la qualité des tests au fil du temps et l’amélioration de la garantie de test sont essentiels pour maintenir un pipeline sain. La fonctionnalité d’analyse de test offre une visibilité en quasi temps réel sur 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 la flakiness.

Affichez l’analyse des tests pour les builds et les versions, préversion 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 et exécutées sur le serveur. Les phases sans agent ne nécessitent pas d’agent ou d’ordinateurs cibles. Contrairement aux phases d’agent, une seule tâche peut être ajoutée à chaque phase sans agent dans les définitions. Cela signifiait que plusieurs phases devaient être ajoutées lorsqu’il y avait plusieurs tâches 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 dans une phase sans agent. Les tâches de la même phase s’exécutent de manière séquentielle, comme elles le font pour les phases d’agent. Pour plus d’informations, consultez la documentation sur les phases du serveur .

Exposer et phaser progressivement les déploiements à l’aide de portes de mise en production

À l’aide des portes de mise en production, vous pouvez spécifier les critères d’intégrité de l’application qui doivent être remplis avant qu’une version soit promue dans l’environnement suivant. Toutes les portes spécifiées sont évaluées régulièrement avant ou après tout déploiement, jusqu’à ce qu’elles réussissent toutes. Quatre types de portes sont disponibles dès le départ et vous pouvez ajouter d’autres portes à partir de la Place de marché. 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 portes de mise en production.

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

Les portes de mise en production permettent l’évaluation automatique des critères d’intégrité avant qu’une version ne soit promue dans l’environnement suivant. Par défaut, la mise en production progresse après la réception d’un exemple réussi pour toutes les portes. Même si une porte est erratique et que l’échantillon reçu est un bruit, la libération progresse. Pour éviter ces types de problèmes, vous pouvez maintenant configurer la version pour vérifier la cohérence de l’intégrité pendant une durée minimale avant de progresser. Au moment de l’exécution, la version garantit que les évaluations consécutives des portes sont réussies avant d’autoriser la promotion. La durée totale de l’évaluation dépend du « délai entre la réévaluation » et est généralement supérieure à la durée minimale configurée. Pour plus d’informations, consultez la documentation Relative au contrôle de déploiement de mise en production à l’aide de portes .

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

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

Déployer en continu des builds marquées par le traitement post-build

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

Définir une variable au moment de la publication

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

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

Passer des variables d’environnement à des tâches

Les auteurs de tâches CI/CD peuvent définir une nouvelle propriété, showEnvironmentVariables, dans task.json pour passer des variables d’environnement aux tâches. Dans ce cas, un contrôle supplémentaire est affiché sur la tâche dans l’éditeur de build. Il est disponible pour les tâches PowerShell, Cmd et Bash .

Cela permet deux scénarios :

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

Cloner des groupes de variables

Nous avons ajouté la prise en charge du clonage des groupes de variables. Chaque fois que vous souhaitez répliquer un groupe de variables et simplement mettre à jour quelques-unes des variables, vous n’avez pas besoin de 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.

Notes

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

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

Les portes de mise en production permettent l’évaluation automatique des critères d’intégrité avant qu’une mise en production ne soit promue dans l’environnement suivant. Par défaut, le pipeline de mise en production progresse uniquement lorsque toutes les portes sont saines en même temps. Dans certaines situations, comme lors de l’accélération d’une mise en production ou après une vérification manuelle de l’intégrité, un approbateur peut vouloir ignorer une porte et autoriser la mise en production à progresser même si cette porte n’a pas encore été évaluée comme saine. Pour plus d’informations, consultez la documentation relative aux portes de mise en production.

Effectuer des tests supplémentaires à l’aide d’un déclencheur de mise en production de demande de tirage

Vous avez été en mesure de déclencher une build basée sur une demande de tirage (PR) et d’obtenir ces commentaires rapides avant une fusion pendant un certain temps. Vous pouvez maintenant configurer un déclencheur de demande de tirage pour une mise en production. Les status de la version sont republées dans le référentiel de code et sont directement visibles dans la page de demande de tirage. Cela est utile si vous souhaitez effectuer des tests fonctionnels ou manuels supplémentaires dans le cadre de votre flux de travail de demande de tirage.

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

Vous pouvez maintenant définir une connexion de service Azure avec un principal de service et un certificat pour l’authentification. 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.

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

La version Azure App Service Deploy task (4.*) prend désormais en charge RunFromPackage (anciennement RunFromZip).

App Service prend en charge un certain nombre de techniques différentes pour déployer vos fichiers, telles 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 Exécuter à partir du package, il n’existe plus d’étape de déploiement qui copie les fichiers individuels dans wwwroot. Au lieu de cela, vous le 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éduction des risques de verrouillage lors de la copie de fichiers
• Déploiement possible sur une application de production (après redémarrage)
• Connaissance des fichiers qui sont exécutés dans votre application
• Améliore les performances des déploiements Azure App Service.
• Peut réduire les temps de démarrage à froid, en particulier pour les fonctions JavaScript avec des arborescences de package npm de grande taille.

Déployer des conteneurs Linux avec la tâche De déploiement App Server

La version 4.* de la tâche Azure App Service Deploy prend désormais en charge le déploiement de votre propre conteneur personnalisé pour 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 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 App Service tâche De déploiement.
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 d’une dépendance ou d’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 nouvellement publié

Coïncidant avec la version d’Apple de Xcode 10, vous pouvez maintenant définir vos projets pour générer ou être testés spécifiquement avec Xcode 10. Votre pipeline peut également exécuter des travaux en parallèle avec une matrice de versions de Xcode. Vous pouvez utiliser le pool d’agents macOS hébergé par Microsoft pour exécuter ces builds. Consultez les instructions relatives à l’utilisation de Xcode dans Azure Pipelines.

Simplifier 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 la dernière année. 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 fournir des 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 mise en production

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 chemin d’accès de l’agent (hébergé ou privé). Utilisez cette tâche pour modifier la version de Helm utilisée dans les tâches suivantes, telles que la tâche cli .NET Core . L’ajout de cette tâche avant la tâche Helm Deploy dans une définition de build ou de mise en production garantit que vous empaquetez et déployez 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 en tant que service d’Azure. Gérez vos fichiers de script MySQL dans le contrôle de version et déployez en continu dans le cadre d’un pipeline de mise en production à l’aide d’une tâche native plutôt que de scripts PowerShell.

Utiliser des tâches windows distantes PowerShell améliorées

Les tâches windows distantes PowerShell nouvelles et améliorées sont disponibles. Ces améliorations incluent plusieurs correctifs de performances et prennent en charge les journaux en direct et les commandes de sortie de console, telles que Write-Host et Write-Output.

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

Tâche de copie de fichiers Azure (version : 2.*) : fourni 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

Lors de la publication à partir de GitHub Enterprise ou de 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 vers la production.

Créer des applications écrites en Go

Utilisez la tâche Programme d’installation de l’outil Go pour installer une ou plusieurs versions de Go Tool à la volée. Cette tâche acquiert 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 ciblée de Go Tool est déjà installée sur l’agent, cette tâche ignore le processus de téléchargement et d’installation.

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 inline ou basés sur des fichiers dans votre pipeline

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

Tirer parti de la génération Xcode améliorée et de la sortie de test de xcpretty

xcpretty améliore la lisibilité de la sortie xcodebuild et génère des résultats de test au format JUnit. La tâche de génération Xcode utilise désormais automatiquement xcpretty lorsqu’elle est disponible sur l’ordinateur agent, comme 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.

Test Plans

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

Vous pouvez maintenant utiliser le client Test Runner (Azure Test Plans) pour exécuter des tests manuels pour les applications de bureau. Cela vous 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 vidéo audio. Si vous rencontrez un problème lors du test, utilisez Test Runner pour créer un bogue avec des étapes de test, des captures d’écran et des commentaires automatiquement inclus dans le bogue.

Test Runner (Azure Test Plans) nécessite un téléchargement et une installation ponctuels de l’exécuteur. Sélectionnez Exécuter pour l’application de bureau comme indiqué ci-dessous.

Artifacts

Sources amont

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

• Vous pouvez ajouter nuget.org sources amont aux flux existants créés dans les versions précédentes de TFS. Recherchez la bannière au-dessus des packages de votre flux pour plus d’informations, y compris les changements de comportement que vous devez connaître avant la mise à niveau.
• Vous pouvez ajouter d’autres flux Azure DevOps Server en tant que sources amont à votre flux, ce qui signifie que vous pouvez utiliser des packages NuGet et npm à partir de ces flux 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 amont, mais ne peut pas publier des packages directement dans le flux (par exemple, à l’aide de nuget publish). Cela vous permet de restreindre 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 provenant de vos sources amont.

Suivre les packages

Nous avons simplifié la configuration des notifications avec un nouveau bouton Suivre directement sur chaque package. Le bouton Suivre est également compatible avec les affichages de mise en production. Si vous suivez un package tout en le regardant dans une vue, vous obtiendrez uniquement les mises à jour pour les nouvelles versions promues vers cette vue.

Modifier les paramètres de 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 amont 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 des pivots de paramètres.

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

L’interaction avec les flux NuGet authentifiés s’est améliorée. Le nouveau fournisseur d’informations d’identification Azure Artifacts basé sur .NET Core fonctionne avec msbuild, dotnet et nuget(.exe) sur Windows, macOS et Linux. Chaque fois que vous souhaitez utiliser des packages à partir d’un flux Azure Artifacts, le fournisseur d’informations d’identification 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, accédez à GitHub et suivez les instructions de votre client et de votre plateforme.

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

Nous avons mis à jour la tâche Index & Publier des symboles 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 référentiel Git en tant que Wiki

Les développeurs créent une documentation pour les « API », les « SDK » et les « documents d’aide expliquant le code » dans les référentiels de code. Les lecteurs doivent ensuite passer au crible le code pour trouver la documentation appropriée. Vous pouvez désormais 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 dans un dépôt Git qui doit être promu.

Une fois que vous avez cliqué sur Publier, tous les fichiers markdown sous le dossier sélectionné sont publiés en tant que wiki. Cela mappe également le chef de la branche au wiki afin que toutes les modifications que vous apportez au dépôt Git soient immédiatement répercutées.

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

Lien vers des en-têtes dans une page

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

Joindre des fichiers et des images dans des dossiers

Lors de la modification de pages wiki hors connexion, il peut être plus facile d’ajouter des pièces jointes et des images de fichiers 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 désormais incorporer des vidéos dans une page wiki à partir de services en ligne telles que Microsoft Stream et YouTube. Vous pouvez ajouter l’URL de la vidéo incorporée à l’aide de la syntaxe suivante :

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

Renommez un wiki

Vous pouvez maintenant renommer votre wiki dans l’interface utilisateur du wiki et à l’aide des 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 appuyer simplement sur Ctrl + cliquer avec le bouton gauche sur une page wiki pour l’ouvrir dans un nouvel onglet.

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

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

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

Afficher les liens rompus

Tous les liens d’un wiki qui ne sont pas correctement lié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 toute solution de documentation. Auparavant, dans Wiki, lorsque vous déplaçaiez une page dans l’arborescence ou renommiez une page, il pouvait potentiellement interrompre les liens vers la page à partir d’autres pages et éléments de travail. À présent, vous pouvez case activée pour et corriger les liens avant qu’ils ne soient rompus.

Important

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

Lorsque vous renommez ou déplacez une page, vous êtes invité à case activée pour les liens absolus ou relatifs affectés.

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

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

Parfois, les pages wiki peuvent devenir longues, le contenu étant 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 des instructions markdown .

Métadonnées Surface pour les pages wiki et la préversion 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 à présenter du contenu significatif. Dans cette mise à jour, tout fichier qui contient un bloc YAML au début du fichier est transformé en une table de métadonnées d’une tête et d’une ligne. Le bloc YAML doit prendre la forme d’une valeur YAML valide définie entre des lignes à trois tirets. Il prend en charge tous les types de données de base, list, object as value. La syntaxe est prise en charge dans la préversion du fichier Wiki et du fichier 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 du code en tant que wiki avec des autorisations Contribute

Auparavant, seuls les utilisateurs disposant de l’autorisation Créer un dépôt sur un dépôt git pouvaient publier du code en tant que wiki. Cela a fait des administrateurs ou des créateurs de dépôt 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. Maintenant, vous pouvez publier du code en tant que wiki si vous disposez simplement de l’autorisation Contribuer sur le référentiel de code.

Rapports

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

L’extension Analytics Marketplace est désormais disponible pour Azure DevOps Server. L’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 Power BI et l’accès OData.

Pour plus d’informations, case activée Présentation de l’analytique et de la feuille de route de création de rapports. Analytics est en préversion publique. Il contient actuellement des données pour les tableaux et les résultats des tests automatisés via des pipelines. Consultez Données disponibles dans Analytics Service.

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

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 maintenant afficher un historique des builds d’une branche spécifique sur votre tableau de bord et le configurer sur un projet public pour les visiteurs anonymes.

Important

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

---

Commentaires

Nous aimerions connaître votre opinion ! Vous pouvez signaler un problème ou fournir une idée et le suivre dans Developer Community et obtenir des conseils sur Stack Overflow.

---

Haut de la page