Notes de publication d’Azure DevOps Server 2020

Communauté des développeurs | Configuration système requise | Termes de licence | Blog DevOps | Hachages SHA-1

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

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

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

---

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

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

Azure DevOps Server 2020 gère la rétention des builds différemment, en fonction des stratégies de rétention au niveau du pipeline. Certaines configurations de 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 sécurisée d’Azure DevOps Server 2019 vers Azure DevOps Server 2020.

Date de publication d’Azure DevOps Server 2020 Update 0.2 Patch 6 : 14 novembre 2023

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

• Étendue de la liste des caractères autorisés pour activer la validation des arguments des tâches de l’interpréteur de commandes.

Note

Pour implémenter des correctifs pour ce correctif, vous devez suivre plusieurs étapes pour mettre à jour manuellement les tâches.

Installer des correctifs

Important

Nous avons publié les mises à jour de l’agent Azure Pipelines avec le correctif 4 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 4, nous vous recommandons d’installer ces mises à jour avant d’installer Patch 6. La nouvelle version de l’agent après l’installation de Patch 4 sera 3.225.0.

Configurer TFX

1. Suivez les étapes décrites dans les tâches de chargement dans la documentation de collecte 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. Modifiez le répertoire dans 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 

Exigences 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 le mode classique :

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

• Exemple YAML :

variables: 
- name: AZP_75787_ENABLE_NEW_LOGIC 
  value: true 

Date de publication d’Azure DevOps Server 2020 Update 0.2 Patch 5 : 10 octobre 2023

Important

Nous avons publié les mises à jour de l’agent Azure Pipelines avec le correctif 4 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 4, nous vous recommandons d’installer ces mises à jour avant d’installer Patch 5. La nouvelle version de l’agent après l’installation de Patch 4 sera 3.225.0.

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

• Correction d’un bogue dans lequel l’identité « Propriétaire d’analyse » s’affiche comme Identité inactive sur les machines lors de la mise à jour des correctifs.

Date de publication d’Azure DevOps Server 2020 Update 0.2 Patch 4 : 12 septembre 2023

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

• CVE-2023-33136 : Vulnérabilité d’exécution de code à distance du serveur Azure DevOps.
• 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 à la production.

Note

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

Installer des correctifs

1. Téléchargez et installez azure DevOps Server 2020 Update 0.2 patch 4.

Mettre à jour l’agent Azure Pipelines

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

Note

Le AZP_AGENT_DOWNGRADE_DISABLED doit être défini sur « True » pour empêcher l’agent d’être rétrogradé. 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 les tâches de chargement dans la documentation de collecte 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. Modifiez le répertoire dans 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 

Exigences 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 le mode classique :

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

• Exemple YAML :

variables: 
- name: AZP_75787_ENABLE_NEW_LOGIC 
  value: true 

Date de publication d’Azure DevOps Server 2020 Update 0.2 Patch 3 : 8 août 2023

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

• Correction d’un bogue qui interférait avec l'envoi de packages lors de la mise à jour depuis 2018 ou une version antérieure.

Date de publication d’Azure DevOps Server 2020 Update 0.2 Patch 2 : 13 juin 2023

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

• Correction d’un bogue qui interférait avec l'envoi de packages lors de la mise à jour depuis 2018 ou une version antérieure.

Date de publication d’Azure DevOps Server 2020 Update 0.2 Patch 1 : 18 octobre 2022

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

• Résolvez le problème lié aux identités AD nouvellement ajoutées qui n’apparaissent pas dans les sélecteurs d’identité de boîte de dialogue de sécurité.
• Résolution d’un problème avec le filtre Demandé par le membre du groupe dans les paramètres de hook web.
• Corrigez l'erreur de construction de validation contrôlée lorsque les paramètres de l'organisation pour le pipeline avaient une portée d'autorisation des travaux configurée comme limitant l'autorisation des travaux au projet actuel pour les pipelines non liés à la mise en production.

Date de publication d’Azure DevOps Server 2020.0.2 : 17 mai 2022

Azure DevOps Server 2020.0.2 est un ensemble de correctifs de bogues. Vous pouvez installer directement Azure DevOps Server 2020.0.2 ou effectuer une mise à niveau à partir d’Azure DevOps Server 2020 ou Team Foundation Server 2013 ou version ultérieure.

Note

L’outil de migration de données sera disponible pour Azure DevOps Server 2020.0.2 environ trois semaines après cette version. Vous pouvez voir notre liste des versions actuellement prises en charge pour l’importation ici.

Cette version inclut des correctifs pour les éléments suivants :

• Impossible d’ignorer la file d’attente de compilation à l’aide du bouton « Exécuter le suivant ». Auparavant, le bouton « Exécuter suivant » était activé uniquement pour les administrateurs de collection de projets.

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

Date de publication d’Azure DevOps Server 2020.0.1 Patch 9 : 26 janvier 2022

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

• Les notifications par e-mail n’ont pas été envoyées lors de l’utilisation du @mention contrôle dans un élément de travail.
• Corrigez TF400813 erreur lors du changement de compte. Cette erreur s’est produite lors de la mise à niveau de TFS 2018 vers Azure DevOps Server 2020.0.1.
• Résolution d’un problème lié à la page récapitulative vue d’ensemble du projet qui ne parvient pas à se charger.
• Amélioration de la synchronisation des utilisateurs Active Directory.
• Résolution de la vulnérabilité Elasticsearch en supprimant la classe jndilookup des fichiers binaires log4j.

Étapes d’installation

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

Note

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

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

Hachage SHA-256 : B0C05A972C73F253154AEEB7605605EF2E596A96A3720AE942D7A9DDD881545E

Date de publication d’Azure DevOps Server 2020.0.1 Patch 8 : 15 décembre 2021

Le correctif 8 pour Azure DevOps Server 2020.0.1 inclut des correctifs pour les éléments suivants.

• Problème de localisation pour les états de disposition d’éléments de travail personnalisés.
• Problème de localisation dans le modèle de notification par e-mail.
• Problème avec les journaux de la console tronqués lorsqu’il existe plusieurs liens identiques dans une ligne.
• Problème avec l’évaluation des règles NOTSAMEAS lorsque plusieurs règles NOTSAMEAS ont été définies pour un champ.

Date de publication d’Azure DevOps Server 2020.0.1 Patch 7 : 26 octobre 2021

Le correctif 7 pour Azure DevOps Server 2020.0.1 inclut des correctifs pour les éléments suivants.

• Auparavant, Azure DevOps Server pouvait uniquement créer des connexions à GitHub Enterprise Server. Avec ce correctif, les administrateurs de projet peuvent créer des connexions entre Azure DevOps Server et des référentiels sur GitHub.com. Vous trouverez ce paramètre dans la page Connexions GitHub sous Paramètres du projet.
• Résolvez le problème avec le widget Plan de test. Le rapport d’exécution de test affichait un utilisateur incorrect dans les résultats.
• Résolution d’un problème lié à la page récapitulative vue d’ensemble du projet qui ne parvient pas à se charger.
• Corrigez le problème lié aux e-mails qui ne sont pas envoyés pour confirmer la mise à niveau du produit.

Date de publication d’Azure DevOps Server 2020.0.1 Patch 6 : 14 septembre 2021

Le correctif 6 pour Azure DevOps Server 2020.0.1 inclut des correctifs pour les éléments suivants.

• Résoudre l'échec de téléchargement et d'envoi des fichiers.
• Résolvez le problème lié aux données de résultats de test incohérentes.

Date de publication d’Azure DevOps Server 2020.0.1 Patch 5 : 10 août 2021

Le correctif 5 pour Azure DevOps Server 2020.0.1 inclut des correctifs pour les éléments suivants.

• Corrigez l’erreur de l’interface utilisateur de définition de build.
• Modification de l’historique de navigation pour afficher les fichiers au lieu du référentiel racine.
• Résolution du problème lié aux travaux de remise par e-mail pour certains types d’éléments de travail.

Date de publication d’Azure DevOps Server 2020.0.1 Patch 4 : 15 juin 2021

Le correctif 4 pour Azure DevOps Server 2020.0.1 inclut des correctifs pour les éléments suivants.

• Résolution du problème lié à l’importation de données. L’importation de données prenait beaucoup de temps pour les clients qui ont beaucoup de cas de test obsolètes. Cela était dû aux références qui ont augmenté la taille de la tbl_testCaseReferences table. Avec ce correctif, nous avons supprimé les références aux cas de test obsolètes pour accélérer le processus d’importation de données.

Date de publication d’Azure DevOps Server 2020.0.1 Patch 3 : 11 mai 2021

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

• Données de résultats de test incohérentes lors de l’utilisation de Microsoft.TeamFoundation.TestManagement.Client.

Si vous disposez d’Azure DevOps Server 2020.0.1, vous devez installer Azure DevOps Server 2020.0.1 Patch 3.

Vérification de l’installation

• Option 1 : Exécuter devops2020.0.1patch3.exe CheckInstall, devops2020.0.1patch3.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 2020\Application Tier\bin\Microsoft.Teamfoundation.Framework.Server.dll. Azure DevOps Server 2020.0.1 est installé sur c:\Program Files\Azure DevOps Server 2020 par défaut. Après avoir installé Azure DevOps Server 2020.0.1 Patch 3, la version sera 18.170.31228.1.

Date de publication d’Azure DevOps Server 2020.0.1 Patch 2 : 13 avril 2021

Note

Si vous disposez d’Azure DevOps Server 2020, vous devez d’abord effectuer une mise à jour vers Azure DevOps Server 2020.0.1 . Une fois sur 2020.0.1, installez Azure DevOps Server 2020.0.1 Patch 2

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

• CVE-2021-27067 : Divulgation d’informations
• CVE-2021-28459 : Élévation de privilège

Pour implémenter des correctifs pour ce correctif, vous devez suivre les étapes répertoriées ci-dessous pour l’installation générale des correctifs, les installations de tâches AzureResourceGroupDeploymentV2 et AzureResourceManagerTemplateDeploymentV3 .

Installation générale des correctifs

Si vous disposez d’Azure DevOps Server 2020.0.1, vous devez installer Azure DevOps Server 2020.0.1 Patch 2.

Vérification de l’installation

• Option 1 : Exécuter devops2020.0.1patch2.exe CheckInstall, devops2020.0.1patch2.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 2020\Application Tier\bin\Microsoft.Teamfoundation.Framework.Server.dll. Azure DevOps Server 2020.0.1 est installé sur c:\Program Files\Azure DevOps Server 2020 par défaut. Après avoir installé Azure DevOps Server 2020.0.1 Patch 2, la version sera 18.170.31123.3.

Installation de tâche AzureResourceGroupDeploymentV2

Note

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

Installez

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

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

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

npm install -g tfx-cli

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

5. Exécutez ce qui suit à partir de l’invite de commandes. Lorsque vous y êtes invité, entrez l’URL du service et le jeton d’accès personnel.

~$ tfx login
Copyright Microsoft Corporation

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

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

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

Installation de la tâche AzureResourceManagerTemplateDeploymentV3

Note

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

Installez

1. Extrayez le package AzureResourceManagerTemplateDeploymentV3.zip dans un nouveau dossier sur votre ordinateur. Par exemple :D :\tasks\AzureResourceManagerTemplateDeploymentV3.

2. Téléchargez et installez Node.js 14.15.1 et npm (inclus avec le téléchargement Node.js) selon les besoins de votre ordinateur.

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

npm install -g tfx-cli

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

5. Exécutez ce qui suit à partir de l’invite de commandes. Lorsque vous y êtes invité, entrez l’URL du service et le jeton d’accès personnel.

~$ tfx login
Copyright Microsoft Corporation

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

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

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

Date de publication d’Azure DevOps Server 2020.0.1 Patch 1 : 9 février 2021

Nous avons publié un correctif pour Azure DevOps Server 2020.0.1 qui corrige ce qui suit. Pour plus d’informations, consultez le billet de blog .

• Résoudre le problème signalé dans ce ticket de commentaires de la Communauté des développeurs | Bouton Nouveau cas de test ne fonctionne pas
• Incluez les correctifs publiés avec Azure DevOps Server 2020 Patch 2.

Date de publication d’Azure DevOps Server 2020 Patch 3 : 9 février 2021

Nous avons publié un correctif pour Azure DevOps Server 2020 qui corrige ce qui suit. Pour plus d’informations, consultez le billet de blog .

• Résoudre le problème signalé dans ce ticket de commentaires de la Communauté des développeurs | Bouton Nouveau cas de test ne fonctionne pas

Date de publication d’Azure DevOps Server 2020.0.1 : 19 janvier 2021

Azure DevOps Server 2020.0.1 est un ensemble de corrections de bogues. Vous pouvez installer directement Azure DevOps Server 2020.0.1 ou effectuer une mise à niveau à partir d’une installation existante. Les versions prises en charge pour la mise à niveau sont Azure DevOps Server 2020, Azure DevOps Server 2019 et Team Foundation Server 2012 ou version ultérieure.

Cette version inclut des correctifs pour les bogues suivants :

• Résolvez un problème de mise à niveau à partir d’Azure DevOps Server 2019 où le proxy Git peut cesser de fonctionner après la mise à niveau.
• Corrigez l’exception System.OutOfMemoryException pour les collections non-ENU antérieures à Team Foundation Server 2017 lors de la mise à niveau vers Azure DevOps Server 2020. Résout le problème signalé dans ce ticket de commentaires de la Communauté des développeurs.
• Échec de service provoqué par des fichiers Microsoft.Azure.DevOps.ServiceEndpoints.Sdk.Server.Extensions.dll manquants. Résout le problème signalé dans ce ticket de commentaires de la Communauté des développeurs.
• Corrigez l’erreur de nom de colonne non valide dans Analytics lors de la mise à niveau vers Azure DevOps Server 2020. Résout le problème signalé dans ce ticket de commentaires de la Communauté des développeurs.
• Stockage de XSS lors de l’affichage des étapes de cas de test dans les résultats de cas de test.
• Échec de l’étape de mise à niveau lors de la migration des données de résultats vers le module TCM.

Date de publication d’Azure DevOps Server 2020 Patch 2 : 12 janvier 2021

Nous avons publié un correctif pour Azure DevOps Server 2020 qui corrige ce qui suit. Pour plus d’informations, consultez le billet de blog .

• Les détails de l’exécution de test n’affichent pas les détails de l’étape de test pour les données de test migrées à l’aide d’OpsHub Migration
• Exception sur l’initialiseur pour « Microsoft.TeamFoundation.TestManagement.Server.TCMLogger »
• Les builds non conservées sont immédiatement supprimées après la migration vers Azure DevOps Server 2020
• Corriger l’exception du fournisseur de données

Azure DevOps Server 2020 Patch 1 Date : 8 décembre 2020

Nous avons publié un correctif pour Azure DevOps Server 2020 qui corrige ce qui suit. Pour plus d’informations, consultez le billet de blog .

• CVE-2020-17145 : Vulnérabilité d’usurpation d’identité Azure DevOps Server et Team Foundation Services

Date de publication d’Azure DevOps Server 2020 : 6 octobre 2020

Azure DevOps Server 2020 est un ensemble de correctifs de bogues. Elle inclut toutes les fonctionnalités d’Azure DevOps Server 2020 RC2 précédemment publiées.

Note

Azure DevOps 2020 Server a un problème lié à l’installation de l’un des assemblys utilisés par le système de fichiers virtuels Git (GVFS).

Si vous effectuez une mise à niveau à partir d’Azure DevOps 2019 (toute version) ou d’un candidat de publication Azure DevOps 2020 et que vous effectuez l’installation dans le même répertoire que la version précédente, l’assembly Microsoft.TeamFoundation.Git.dll n’est pas installé. Vous pouvez vérifier que vous avez atteint le problème en recherchant Microsoft.TeamFoundation.Git.dll dans les dossiers <Install Dir>\Version Control Proxy\Web Services\bin, <Install Dir>\Application Tier\TFSJobAgent et <Install Dir>\Tools. Si le fichier est manquant, vous pouvez exécuter une réparation pour restaurer les fichiers manquants.

Pour exécuter une réparation, accédez à Settings -> Apps & Features la machine/machine virtuelle Azure DevOps Server et exécutez une réparation sur Azure DevOps 2020 Server. Une fois la réparation terminée, vous pouvez redémarrer la machine/machine virtuelle.

Date de publication d’Azure DevOps Server 2020 RC2 : 11 août 2020

Azure DevOps Server 2020 RC2 est une compilation de corrigés de bogues. Il inclut toutes les fonctionnalités d’Azure DevOps Server 2020 RC1 précédemment publiées.

Date de republication d’Azure DevOps Server 2020 RC1 : 10 juillet 2020

Nous avons re-publié Azure DevOps Server 2020 RC1 pour corriger ce ticket de commentaires de la Communauté des développeurs.

Auparavant, après la mise à niveau d’Azure DevOps Server 2019 Update 1.1 vers Azure DevOps Server 2020 RC1, vous n’avez pas pu afficher les fichiers dans les dépôts, pipelines et wiki de l’interface utilisateur web. Un message d’erreur indique qu’une erreur inattendue s’est produite dans cette région de la page. Vous pouvez essayer de recharger ce composant ou d’actualiser la page entière. Avec cette version, nous avons résolu ce problème. Pour plus d’informations, consultez le billet de blog .

Date de publication d’Azure DevOps Server 2020 RC1 : 30 juin 2020

Résumé des nouveautés d’Azure DevOps Server 2020

Azure DevOps Server 2020 introduit de nombreuses nouvelles fonctionnalités. Voici quelques-uns des points forts :

• Pipelines à plusieurs étapes
• Déploiement continu dans YAML
• Suivre la progression des éléments parents à l’aide du backlog Rollup sur les tableaux
• Ajouter le filtre « Élément de travail parent » au tableau des tâches et au backlog sprint
• Nouvelle interface utilisateur web pour les pages d’accueil Azure Repos
• Administration des stratégies de branche inter-dépôts
• Page Nouveau plan de test
• Édition enrichie pour les pages wiki de code
• Rapports sur l'échec et la durée du pipeline

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

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

---

General

Disponibilité générale d’Azure DevOps CLI

En février, nous avons introduit l’extension Azure DevOps pour Azure CLI. L’extension vous permet d’interagir avec Azure DevOps à partir de la ligne de commande. Nous avons recueilli vos commentaires qui nous ont aidés à améliorer l’extension et à ajouter d’autres commandes. Nous sommes maintenant heureux d’annoncer que l’extension est généralement disponible.

Pour en savoir plus sur Azure DevOps CLI, consultez la documentation ici.

Utiliser le profil de publication pour déployer Azure WebApps pour Windows à partir du centre de déploiement

Vous pouvez maintenant utiliser l’authentification basée sur un profil pour déployer vos applications web Azure pour Windows à partir du Centre de déploiement. Si vous avez l’autorisation de déployer sur une application web Azure pour Windows à l’aide de son profil de publication, vous pourrez configurer le pipeline à l’aide de ce profil dans les flux de travail du Centre de déploiement.

Boards

Ajouter le filtre « Élément de travail parent » au tableau des tâches et au backlog de sprint

Nous avons ajouté un nouveau filtre à la fois au tableau Sprint et au backlog Sprint. Cela vous permet de filtrer les éléments de backlog au niveau des exigences (première colonne à gauche) par leur parent. Par exemple, dans la capture d’écran ci-dessous, nous avons filtré la vue pour afficher uniquement les récits utilisateur où le parent est « Ma grande fonctionnalité ».

Amélioration de l'expérience de gestion des erreurs -- champs obligatoires sur les bogues/tâches

Historiquement, depuis le tableau Kanban, si vous déplaciez un élément de travail d’une colonne à une autre où le changement d'état déclenche des règles de champ, la carte affichait simplement un message d’erreur rouge qui vous obligeait à ouvrir l’élément de travail pour comprendre la cause première. Dans sprint 170, nous avons amélioré l’expérience afin que vous puissiez maintenant cliquer sur le message d’erreur rouge pour afficher les détails de l’erreur sans avoir à ouvrir l’élément de travail lui-même.

Rechargement en direct des éléments de travail

Auparavant, lors de la mise à jour d’un élément de travail et qu’un deuxième membre de l’équipe apportait des modifications au même élément de travail, le deuxième utilisateur perdrait ses modifications. À présent, tant que vous modifiez des champs différents, vous verrez les mises à jour actives des modifications apportées à l’élément de travail.

Gérer les chemins d’itération et de zone à partir de la ligne de commande

Vous pouvez désormais gérer les chemins d’itération et de zone à partir de la ligne de commande à l’aide des az boards iteration commandes et az boards area des commandes. Par exemple, vous pouvez configurer et gérer les chemins d’itération et de zone de manière interactive à partir de l’interface CLI, ou automatiser l’ensemble de l’installation à l’aide d’un script. Pour plus d’informations sur les commandes et la syntaxe, consultez la documentation ici.

Colonne parent d’élément de travail en tant qu’option de colonne

Vous avez maintenant la possibilité de voir le parent de chaque élément de travail dans votre backlog de produit ou le backlog sprint. Pour activer cette fonctionnalité, accédez à Options de colonne sur le backlog souhaité, puis ajoutez la colonne Parent.

Changer le processus utilisé par un projet

Vos outils doivent changer à mesure que votre équipe le fait, vous pouvez désormais basculer vos projets de n’importe quel modèle de processus prête à l’emploi vers n’importe quel autre processus prête à l’emploi. Par exemple, vous pouvez modifier votre projet de l’utilisation d’Agile à Scrum, ou de base en Agile. Vous trouverez ici une documentation détaillée complète.

Masquer les champs personnalisés de la mise en page

Vous pouvez maintenant masquer les champs personnalisés de la disposition du formulaire lors de la personnalisation de votre processus. Le champ sera toujours disponible à partir de requêtes et d’API REST. Cela est pratique pour suivre des champs supplémentaires lorsque vous intégrez à d’autres systèmes.

Obtenir des insights sur l’intégrité de votre équipe avec trois nouveaux rapports Azure Boards

Vous ne pouvez pas corriger ce que vous ne pouvez pas voir. Par conséquent, vous souhaitez garder un œil étroit sur l’état et l’intégrité de leurs processus de travail. Avec ces rapports, nous vous rendons plus faciles à suivre les métriques importantes avec un effort minimal dans Azure Boards.

Les trois nouveaux rapports interactifs sont : Burndown, Cumulative Flow Diagram (CFD) et Velocity. Vous pouvez voir les rapports dans le nouvel onglet Analytique.

Les métriques telles que le sprint burndown, le flux de travail et la vélocité de l’équipe vous donnent la visibilité sur la progression de votre équipe et vous aident à répondre aux questions telles que :

• Combien de travail avons-nous laissé dans ce sprint ? Sommes-nous en voie de le terminer ?
• Quelle étape du processus de développement prend la plus longue ? Pouvons-nous faire quelque chose à ce sujet ?
• En fonction des itérations précédentes, combien de travail devons-nous planifier pour le sprint suivant ?

Note

Les graphiques précédemment affichés dans les en-têtes ont été remplacés par ces rapports améliorés.

Les nouveaux rapports sont entièrement interactifs et vous permettent de les ajuster à vos besoins. Vous trouverez les nouveaux rapports sous l’onglet Analytique dans chaque hub.

• Le graphique de burndown se trouve sous l'onglet Sprints.

  

• Les rapports CFD et Vélocité sont accessibles à partir de l’onglet Analytique sous Tableaux et Backlogs en cliquant sur la carte appropriée.

  

Avec les nouveaux rapports, vous avez plus de contrôle et d’informations sur votre équipe. Voici quelques exemples :

• Les rapports Sprint Burndown et Vélocité peuvent être définis pour utiliser le nombre d’éléments de travail ou la somme du travail restant.
• Vous pouvez ajuster la période d’avancement du sprint sans affecter les dates du projet. Par conséquent, si votre équipe passe généralement le premier jour de chaque planification de sprint, vous pouvez maintenant faire correspondre le graphique pour refléter cela.
• Le graphique Burndown présente désormais un filigrane affichant les week-ends.
• Le rapport CFD vous permet de supprimer des colonnes de tableau telles que La conception pour obtenir plus de focus sur le flux sur lequel les équipes ont le contrôle.

Voici un exemple de rapport CFD montrant le flux sur les 30 derniers jours de l'arriéré des Stories.

Le graphique de vélocité peut maintenant être suivi pour tous les niveaux de backlog. Par exemple, vous pouvez maintenant ajouter des fonctionnalités et des épiques, alors qu'auparavant le graphique précédent supportait uniquement les exigences. Voici un exemple de rapport de vélocité pour les 6 dernières itérations du backlog des fonctionnalités.

Personnaliser les colonnes du tableau des tâches

Nous sommes heureux d’annoncer que nous avons ajouté une option pour vous permettre de personnaliser les colonnes dans le tableau des tâches. Vous pouvez maintenant ajouter, supprimer, renommer et réorganiser les colonnes.

Pour configurer les colonnes de votre tableau des tâches, accédez aux options de colonne.

Cette fonctionnalité a été hiérarchisée en fonction d’une suggestion de la Communauté des développeurs.

Afficher ou masquer les éléments de travail enfants terminés dans le backlog

Plusieurs fois, lors de l’affinement du backlog, vous ne souhaitez voir que les éléments qui n’ont pas été terminés. À présent, vous avez la possibilité d’afficher ou de masquer les éléments enfants terminés sur le backlog.

Si l'interrupteur est activé, vous voyez tous les éléments enfants dans un état terminé. Lorsque l'interrupteur est désactivé, tous les éléments enfants ayant été complétés sont masqués dans le backlog.

Affichage des catégories les plus récentes lors de la catégorisation d’un élément de travail

Lors de l’étiquetage d’un élément de travail, l’option de saisie semi-automatique affiche désormais jusqu’à cinq de vos balises les plus récemment utilisées. Cela facilite l’ajout des informations appropriées à vos éléments de travail.

Règles de champ en lecture seule ou obligatoire pour l’appartenance aux groupes

Les règles d’élément de travail vous permettent de définir des actions spécifiques sur les champs d’élément de travail pour automatiser leur comportement. Vous pouvez créer une règle pour définir un champ en lecture seule ou obligatoire en fonction de l’appartenance au groupe. Par exemple, vous pouvez accorder aux propriétaires de produits la possibilité de définir la priorité de vos fonctionnalités tout en le rendant en lecture seule pour tous les autres utilisateurs.

Personnaliser les valeurs de la liste de sélection du système

Vous pouvez désormais personnaliser les valeurs de n’importe quelle liste de choix système (à l’exception du champ raison) telle que Gravité, Activité, Priorité, etc. Les personnalisations de la liste de choix sont définies de manière à ce que vous puissiez gérer différentes valeurs pour le même champ pour chaque type d’élément de travail.

Nouveau paramètre d’URL d’élément de travail

Partagez des liens vers des éléments de travail avec le contexte de votre tableau ou de votre backlog avec notre nouveau paramètre d’URL d’élément de travail. Vous pouvez maintenant ouvrir une boîte de dialogue d’élément de travail sur votre carte, votre Backlog ou votre expérience de sprint en ajoutant le paramètre ?workitem=[ID] à l’URL.

Toute personne avec laquelle vous partagez le lien atterrira alors avec le même contexte que celui que vous aviez lorsque vous avez partagé le lien !

Mentionner des personnes, des éléments de travail et des demandes de tirage dans des champs de texte

Comme nous avons écouté vos commentaires, nous avons entendu dire que vous vouliez pouvoir mentionner des personnes, des éléments de travail et des demandes de tirage dans la zone de description de l’élément de travail (et d’autres champs HTML) sur l’élément de travail et pas seulement dans les commentaires. Parfois, vous collaborez avec quelqu'un sur un élément de travail ou souhaitez mettre en évidence une pull request dans la description de votre élément de travail, mais vous n'aviez aucun moyen d'ajouter cette information. Vous pouvez maintenant mentionner des personnes, des éléments de travail et des demandes de tirage dans tous les champs de texte longs de l’élément de travail.

Vous pouvez voir un exemple ici.

• Pour utiliser des mentions de personnes, tapez le @ signe et le nom de la personne que vous souhaitez mentionner. @mentions dans les champs des éléments de travail génère des notifications par e-mail comme cela se fait pour les commentaires.
• Pour utiliser des mentions d’élément de travail, tapez le # signe suivi de l’ID ou du titre de l’élément de travail. #mentions crée un lien entre les deux éléments de travail.
• Pour utiliser des mentions de PR, ajoutez un ! suivi de l'ID ou du nom de votre PR.

Réactions sur les commentaires de discussion

L’un de nos principaux objectifs est de rendre les éléments de travail plus collaboratifs pour les équipes. Récemment, nous avons mené un sondage sur Twitter pour savoir quelles fonctionnalités de collaboration vous voulez dans les discussions sur l’élément de travail. L'ajout de réactions aux commentaires a remporté le sondage, donc nous les ajoutons ! Voici les résultats du sondage Twitter.

Vous pouvez ajouter des réactions à n’importe quel commentaire, et il existe deux façons d’ajouter vos réactions : l’icône de sourire en haut à droite de n’importe quel commentaire, ainsi qu’au bas d’un commentaire en regard de toutes les réactions existantes. Vous pouvez ajouter les six réactions si vous le souhaitez, ou seulement un ou deux. Pour supprimer votre réaction, cliquez sur la réaction en bas de votre commentaire et elle sera supprimée. Vous pouvez voir ci-dessous l’expérience d’ajouter une réaction, ainsi que l'apparence des réactions sur un commentaire.

Épingler des rapports Azure Boards sur le tableau de bord

Dans la mise à jour Sprint 155, nous avons inclus des versions mises à jour des rapports CFD et Vélocité. Ces rapports sont disponibles sous l’onglet Analytique des tableaux et des backlogs. Vous pouvez désormais épingler les rapports directement à votre tableau de bord. Pour épingler les rapports, survolez le rapport, sélectionnez le menu de points de suspension « ... », puis copiez dans le tableau de bord.

Suivre la progression des éléments parents à l’aide de la la fonctionnalité Rollup (Cumul) sur un backlog Boards

Les colonnes de cumul affichent des barres de progression et/ou des totaux de champs numériques ou d’éléments descendants au sein d’une hiérarchie. Les éléments descendants correspondent à tous les éléments enfants de la hiérarchie. Une ou plusieurs colonnes de cumul peuvent être ajoutées à un backlog de produits ou de portefeuille.

Par exemple, ici, nous affichons progression par éléments de travail qui affiche des barres de progression pour les éléments de travail ascendants en fonction du pourcentage d’éléments descendants qui ont été fermés. Les éléments descendants pour Epics incluent toutes les fonctionnalités enfants et leurs éléments de travail enfants ou petits enfants. Les éléments descendants pour fonctionnalités incluent tous les récits utilisateur enfants et leurs éléments de travail enfants.

Mises à jour automatiques des tableaux de tâches

Votre tableau des tâches s’actualise automatiquement lorsque des modifications se produisent ! À mesure que d’autres membres de l’équipe déplacent ou réorganisent des cartes dans le tableau des tâches, votre tableau est automatiquement mis à jour avec ces modifications. Vous n’avez plus besoin d’appuyer sur F5 pour voir les dernières modifications.

Prise en charge des champs personnalisés dans les colonnes du Rollup

Le cumul peut maintenant être effectué sur n’importe quel champ, y compris les champs personnalisés. Lors de l’ajout d’une colonne de cumul, vous pouvez toujours choisir une colonne dans la liste rapide. Toutefois, si vous souhaitez cumuler des champs numériques qui ne font pas partie du modèle de processus standard, vous pouvez configurer vos propres éléments comme suit :

1. Dans votre backlog, cliquez sur « Options de colonne ». Ensuite, dans le panneau, cliquez sur « Ajouter une colonne rollup » et configurez le cumul personnalisé.

   

2. Choisissez entre la barre de progression et le total.
3. Sélectionnez un type d’élément de travail ou un niveau Backlog (généralement les backlogs agrègent plusieurs types d’éléments de travail).
4. Sélectionnez le type d’agrégation. Nombre d’éléments de travail ou Somme. Pour Sum, vous devez sélectionner le champ à résumer.
5. Le bouton OK vous ramènera au volet d’options de colonne dans lequel vous pouvez réorganiser votre nouvelle colonne personnalisée.

Notez que vous ne pouvez pas modifier votre colonne personnalisée après avoir cliqué sur OK. Si vous avez besoin d’apporter une modification, supprimez la colonne personnalisée et ajoutez-en une autre comme vous le souhaitez.

Nouvelle règle pour masquer les champs d’un formulaire d’élément de travail en fonction d’une condition

Nous avons ajouté une nouvelle règle au moteur de règles hérité pour vous permettre de masquer les champs dans un formulaire d’élément de travail. Cette règle masque les champs en fonction de l’appartenance au groupe d’utilisateurs. Par exemple, si l’utilisateur appartient au groupe « propriétaire du produit », vous pouvez masquer un champ spécifique au développeur. Pour plus d’informations, consultez la documentation ici.

Paramètres de notification d’élément de travail personnalisés

Rester à jour sur les éléments de travail pertinents pour vous ou votre équipe est incroyablement important. Il aide les équipes à collaborer et à suivre les projets et à s’assurer que toutes les parties appropriées sont impliquées. Toutefois, différentes parties prenantes ont différents niveaux d’investissement dans différents efforts, et nous pensons que cela devrait être reflété dans votre capacité à suivre l’état d’un élément de travail.

Auparavant, si vous souhaitiez suivre un élément de travail et recevoir des notifications sur les modifications apportées, vous obtiendriez des notifications par e-mail pour toutes les modifications apportées à l’élément de travail. Après avoir examiné vos commentaires, nous rendons le suivi d’un élément de travail plus flexible pour toutes les parties prenantes. À présent, vous verrez un nouveau bouton de paramètres en regard du bouton Suivre dans le coin supérieur droit de l’élément de travail. Vous accédez ainsi à une fenêtre contextuelle qui vous permettra de configurer vos options de suivi.

Dans les paramètres de notification, vous pouvez choisir parmi trois options de notification. Premièrement, vous pouvez être entièrement supprimé de la liste. Deuxièmement, vous pouvez bénéficier d'un abonnement complet et ainsi recevoir des notifications pour toutes les modifications des éléments de travail. Enfin, vous pouvez choisir d’être averti pour certains événements de modification des éléments de travail principaux et essentiels. Vous ne pouvez sélectionner qu’une ou les trois options. Cela permet aux membres de l’équipe de suivre les éléments de travail à un niveau supérieur et de ne pas être distrait par chaque modification unique qui est apportée. Avec cette fonctionnalité, nous allons éliminer les e-mails inutiles et vous permettre de vous concentrer sur les tâches cruciales à portée de main.

Lier des éléments de travail à des déploiements

Nous sommes heureux de libérer le contrôle de déploiement sur le formulaire d’élément de travail. Cet outil relie vos tâches à une distribution et vous permet de suivre facilement l'état de déploiement de votre tâche. Pour en savoir plus, consultez la documentation ici.

Importer des éléments de travail à partir d’un fichier CSV

Jusqu’à présent, l’importation d’éléments de travail à partir d’un fichier CSV dépendait de l’utilisation du plug-in Excel. Dans cette mise à jour, nous proposons une expérience d’importation de première classe directement à partir d’Azure Boards pour vous permettre d’importer des éléments de travail nouveaux ou de mettre à jour des éléments de travail existants. Pour en savoir plus, consultez la documentation ici.

Ajouter un champ parent à des cartes d’élément de travail

Le contexte parent est désormais disponible dans votre tableau Kanban comme nouveau champ pour les cartes de tâches de travail. Vous pouvez maintenant ajouter le champ Parent à vos cartes, en contournant la nécessité d’utiliser des solutions de contournement telles que des balises et des préfixes.

Ajouter un champ parent à des backlog et requêtes

Le champ parent est désormais disponible lors de l’affichage des backlogs et des résultats de requête. Pour ajouter le champ parent, utilisez la vue Options de colonne .

Repos

Métriques de couverture de code et stratégie de branche pour les demandes de tirage

Vous pouvez maintenant voir les métriques de couverture du code pour les modifications dans la vue de pull request. Cela garantit que vous avez correctement testé vos modifications via des tests automatisés. L'état de la couverture s'affiche sous forme de commentaire dans la vue d'ensemble du PR. Vous pouvez afficher les détails des informations de couverture pour chaque ligne de code modifiée dans la vue des différences de fichiers.

En outre, les propriétaires de référentiels peuvent désormais définir des stratégies de couverture du code et empêcher la fusion de modifications volumineuses et non testées dans une branche. Les seuils de couverture souhaités peuvent être définis dans un azurepipelines-coverage.yml fichier de paramètres validé à la racine du référentiel, et la stratégie de couverture peut être définie en utilisant la capacité existante de configurer une stratégie de branche pour des services supplémentaires dans Azure Repos.

Filtrer les notifications de commentaires dans les demandes de tirage

Les commentaires dans les pull requests peuvent souvent générer beaucoup de bruit en raison des notifications. Nous avons ajouté un abonnement personnalisé qui vous permet de filtrer les notifications de commentaires auxquelles vous vous abonnez en fonction de l'âge du commentaire, de l'auteur du commentaire, du commentaire supprimé, des utilisateurs mentionnés, de l'auteur de la demande de fusion, de la branche cible et des participants à la discussion. Vous pouvez créer ces abonnements de notification en cliquant sur l’icône de l’utilisateur dans le coin supérieur droit et en accédant aux paramètres utilisateur.

Crochets de service pour les commentaires des demandes de tirage

Vous pouvez maintenant créer des webhooks pour les commentaires dans une pull request en fonction du référentiel et de la branche cible.

Stratégie de blocage des fichiers avec des modèles spécifiés

Les administrateurs peuvent désormais définir une stratégie pour empêcher les validations d’être envoyées à un référentiel en fonction des types de fichiers et des chemins d’accès. La stratégie de validation de nom de fichier bloque les envois (push) qui correspondent au modèle fourni.

Résoudre des éléments de travail via des validations à l’aide de mots clés

Vous pouvez maintenant résoudre les éléments de travail via des validations effectuées dans la branche par défaut à l’aide de mots clés tels que correctif, correctifs ou corrections. Par exemple, vous pouvez écrire : « cette modification fixe #476 » dans votre message de validation et l’élément de travail #476 sont terminés lorsque la validation est envoyée (push) ou fusionnée dans la branche par défaut. Pour plus d’informations, consultez la documentation ici.

Granularité pour les relecteurs automatiques

Auparavant, lors de l’ajout de réviseurs au niveau du groupe à une demande de tirage, une seule approbation était requise à partir du groupe qui a été ajouté. Vous pouvez maintenant définir des stratégies qui nécessitent plusieurs réviseurs d’une équipe pour approuver une demande de tirage lors de l’ajout de réviseurs automatiques. En outre, vous pouvez ajouter une stratégie pour empêcher les demandeurs d’approuver leurs propres modifications.

Utiliser l’authentification basée sur un compte de service pour se connecter à AKS

Auparavant, lors de la configuration d’Azure Pipelines à partir du Centre de déploiement AKS, nous avons utilisé une connexion Azure Resource Manager. Cette connexion avait accès à l’ensemble du cluster et pas seulement à l’espace de noms pour lequel le pipeline a été configuré. Avec cette mise à jour, nos pipelines utilisent l’authentification basée sur un compte de service pour se connecter au cluster afin qu’il ait uniquement accès à l’espace de noms associé au pipeline.

Préversion des fichiers Markdown dans les demandes de tirage Diffusion côte à côte

Vous pouvez maintenant voir un aperçu de l’apparence d’un fichier Markdown à l’aide du nouveau bouton Aperçu . En outre, vous pouvez voir le contenu complet du fichier depuis la comparaison côte à côte en sélectionnant le bouton Affichage.

Expiration de la stratégie de build pour les builds manuels

Les stratégies appliquent les standards de qualité du code et de gestion des modifications de votre équipe. Auparavant, vous pouviez définir des stratégies d’expiration de build pour les builds automatisées. Vous pouvez maintenant définir des stratégies d’expiration de build pour vos builds manuels.

Ajouter une stratégie pour bloquer les validations en fonction de l’e-mail de l’auteur de validation

Les administrateurs peuvent désormais définir une stratégie Push pour empêcher les validations d’être envoyées vers un référentiel pour lequel l’e-mail de l’auteur de validation ne correspond pas au modèle fourni.

Cette fonctionnalité a été hiérarchisée en fonction d’une suggestion de la Communauté des développeurs pour offrir une expérience similaire. Nous continuerons à ouvrir le ticket et à encourager les utilisateurs à nous dire quels autres types de stratégies push vous souhaitez voir.

Marquer les fichiers comme étant révisés dans une demande de tirage

Parfois, vous devez examiner les demandes de tirage qui contiennent des modifications apportées à un grand nombre de fichiers et il peut être difficile de suivre les fichiers que vous avez déjà examinés. Vous pouvez maintenant marquer les fichiers comme examinés dans une pull request.

Vous pouvez marquer un fichier comme révisé à l’aide du menu déroulant en regard d’un nom de fichier ou en pointant et en cliquant sur le nom du fichier.

Note

Cette fonctionnalité est destinée uniquement à suivre votre avancement lorsque vous révisez une pull request. Il ne représente pas le vote sur les pull requests, donc ces marques ne seront visibles que pour le réviseur.

Cette fonctionnalité a été hiérarchisée en fonction d’une suggestion de la Communauté des développeurs.

Nouvelle interface utilisateur web pour les pages d’accueil Azure Repos

Vous pouvez maintenant tester nos nouvelles pages d’accueil modernes, rapides et mobiles dans Azure Repos. Ces pages sont disponibles en tant que pages d’accueil New Repos. Les pages de destination incluent toutes les pages, à l’exception des détails de pull request, des détails de commit et de la comparaison des branches.

Le Web

Téléphone mobile

Administration de stratégie de branche interdépôt

Les stratégies de branche sont l’une des fonctionnalités puissantes d’Azure Repos qui vous aident à protéger les branches importantes. Bien que la possibilité de définir des stratégies au niveau du projet existe dans l’API REST, il n’y avait pas d’interface utilisateur pour celle-ci. À présent, les administrateurs peuvent définir des stratégies sur une branche spécifique ou la branche par défaut sur tous les référentiels de leur projet. Par exemple, un administrateur peut exiger au minimum deux réviseurs pour toutes les pull requests effectuées dans la branche principale de chaque référentiel de leur projet. Vous trouverez la fonctionnalité Ajouter une protection de branche dans les paramètres du projet Repos.

Nouvelles pages de destination pour la conversion de plateforme web

Nous avons mis à jour l’expérience utilisateur des pages d’accueil Repos pour la rendre moderne, rapide et mobile. Voici deux exemples de pages qui ont été mises à jour, nous continuerons à mettre à jour d’autres pages dans les prochaines mises à jour.

Expérience web :

Expérience mobile :

Prise en charge du langage Kotlin

Nous sommes heureux d’annoncer que nous prenons désormais en charge la mise en surbrillance de la langue Kotlin dans l’éditeur de fichiers. La mise en surbrillance améliore la lisibilité de votre fichier texte Kotlin et vous aide à analyser rapidement les erreurs. Nous avons hiérarchisé cette fonctionnalité en fonction d’une suggestion de la Communauté des développeurs.

Abonnement aux notifications personnalisées pour les brouillons de demandes de tirage

Pour réduire le nombre de notifications par e-mail des demandes de tirage, vous pouvez désormais créer un abonnement de notification personnalisé pour les demandes de tirage qui sont créées ou mises à jour dans un état brouillon. Vous pouvez recevoir des e-mails spécifiquement pour les pull requests en draft ou filtrer les e-mails des pull requests en draft afin que votre équipe ne soit pas notifiée avant que la pull request soit prête à être examinée.

Amélioration de l’action des requêtes d’extraction

Lorsque vous avez de nombreuses pull requests à examiner, il peut être difficile de déterminer où agir en premier. Pour améliorer l’actionnabilité des requêtes de tirage, vous pouvez désormais créer plusieurs requêtes personnalisées sur la page de liste des requêtes de tirage avec plusieurs nouvelles options de filtrage, telles que l’état brouillon. Ces requêtes créent des sections distinctes et repliables sur votre page de pull request, en plus de « Créé par moi » et « Assigné à moi ». Vous pouvez également refuser d’examiner une demande de tirage (pull request) à laquelle vous avez été ajouté via le menu Vote ou le menu contextuel de la page de liste des demandes de tirage. Dans les sections personnalisées, vous verrez maintenant des onglets distincts pour les requêtes de tirage que vous avez examinées ou que vous avez refusé d'examiner. Ces requêtes personnalisées fonctionnent entre les référentiels sous l’onglet « Mes demandes de tirage » de la page d’accueil de la collection. Si vous souhaitez revenir à une requête de tirage, vous pouvez la marquer et elle s’affichera en haut de votre liste. Enfin, les requêtes de tirage qui ont été définies pour la finalisation automatique seront marquées d'une étiquette indiquant « Finalisation automatique » dans la liste.

Pipelines

Pipelines à plusieurs étapes

Nous avons travaillé sur une expérience utilisateur mise à jour pour gérer vos pipelines. Ces mises à jour rendent les pipelines modernes et cohérents avec la direction d’Azure DevOps. De plus, ces mises à jour rassemblent des pipelines de build classiques et des pipelines YAML à plusieurs étapes en une seule expérience. Il est convivial pour les mobiles et apporte diverses améliorations à la façon dont vous gérez vos pipelines. Vous pouvez approfondir et afficher les détails du pipeline, les détails de l’exécution, les analyses du pipeline, les détails des tâches, les journaux, et bien plus encore.

Les fonctionnalités suivantes sont incluses dans la nouvelle expérience :

• affichage et gestion de plusieurs étapes
• approbation des exécutions de pipelines
• Faites défiler jusqu'au début des journaux pendant qu'un pipeline est en cours d'exécution.
• état par branche d’un pipeline.

Déploiement continu dans YAML

Nous sommes heureux de déployer les fonctionnalités de CD YAML d'Azure Pipelines. Nous offrons désormais une expérience YAML unifiée, vous permettant de configurer chacun de vos pipelines pour effectuer CI, CD, ou CI et CD ensemble. Les fonctionnalités YAML CD introduisent plusieurs nouvelles fonctionnalités avancées pour toutes les collections disponibles en utilisant des pipelines YAML à plusieurs étapes. Voici quelques-uns des points forts :

• Pipelines YAML à plusieurs étapes (pour CI et CD)
• Approbations et vérifications sur les ressources
• Environnements et stratégies de déploiement
• Ressources Kubernetes et machines virtuelles dans l’environnement
• Passer en revue les applications pour la collaboration
• Expérience utilisateur actualisée pour les connexions de service
• Ressources dans des pipelines YAML

Si vous êtes prêt à commencer à créer, consultez la documentation ou le blog pour la création de pipelines CI/CD multi-étapes.

Gérer des variables de pipeline dans l’éditeur YAML

Nous avons mis à jour l’expérience de gestion des variables de pipeline dans l’éditeur YAML. Vous n’avez plus besoin d’accéder à l’éditeur classique pour ajouter ou mettre à jour des variables dans vos pipelines YAML.

Approuver les versions directement à partir du hub Versions

La gestion des approbations en attente a été simplifiée. Avant, il était possible d’approuver une publication depuis la page de détails de cette publication. Vous pouvez maintenant approuver des versions directement à partir du hub Releases.

Améliorations apportées à la prise en main des pipelines

Une demande courante avec l'Assistant démarrage, c'est la possibilité de renommer le fichier généré. Actuellement, il est archivé comme azure-pipelines.yml à la racine de votre référentiel. Vous pouvez maintenant le mettre à jour vers un autre nom de fichier ou emplacement avant d’enregistrer le pipeline.

Enfin, vous aurez plus de contrôle lors de l’enregistrement du fichier azure-pipelines.yml dans une autre branche, car vous pouvez choisir de ne pas créer de pull request à partir de cette branche.

Afficher un aperçu complet du document YAML totalement analysé sans le committer ni exécuter le pipeline

Nous avons ajouté un mode d'aperçu mais sans exécution pour les pipelines YAML. À présent, vous pouvez essayer un pipeline YAML sans le valider dans un dépôt ou l’exécuter. Étant donné un pipeline existant et une nouvelle charge utile YAML facultative, cette nouvelle API vous donnera le pipeline YAML complet. Dans les prochaines mises à jour, cette API sera utilisée dans une nouvelle fonctionnalité d’éditeur.

Pour les développeurs : envoyez une requête POST vers dev.azure.com/<org>/<project>/_apis/pipelines/<pipelineId>/runs?api-version=5.1-preview avec un corps JSON comme suit :

{
  "PreviewRun": true,
  "YamlOverride": "
# your new YAML here, optionally
"
}

La réponse contiendra le YAML rendu.

Planifications cron dans le YAML

Auparavant, vous pouvez utiliser l’éditeur d’interface utilisateur pour spécifier un déclencheur planifié pour les pipelines YAML. Avec cette version, vous pouvez planifier des builds à l’aide de la syntaxe cron dans votre fichier YAML et tirer parti des avantages suivants :

1. Configuration en tant que code : vous pouvez suivre les horaires avec votre pipeline en tant que partie du code.
2. Expressif : Vous avez plus de puissance expressive dans la définition des planifications que ce que vous avez pu utiliser avec l’interface utilisateur. Par exemple, il est plus facile de spécifier une planification unique qui démarre une exécution toutes les heures.
3. Standard du secteur : de nombreux développeurs et administrateurs connaissent déjà la syntaxe cron.

schedules:
- cron: "0 0 * * *"
 displayName: Daily midnight build
 branches:
  include:
  - main
  - releases/*
  exclude:
  - releases/ancient/*
 always: true

Nous avons également facilité le diagnostic des problèmes liés aux planifications cron. Les exécutions planifiées dans le menu Exécuter le pipeline vous donnent un aperçu des prochaines exécutions planifiées pour votre pipeline pour vous aider à diagnostiquer les erreurs avec vos planifications cron.

Mises à jour de l’IU des connexions de service

Nous avons travaillé sur une expérience utilisateur mise à jour pour gérer vos connexions de service. Ces mises à jour rendent l’expérience de connexion de service moderne et cohérente avec la direction d’Azure DevOps. Nous avons introduit la nouvelle interface utilisateur pour les connexions de service en tant que fonctionnalité en préversion plus tôt cette année. Merci à tous ceux qui ont essayé la nouvelle expérience et nous ont fait part de leurs précieux commentaires.

Outre l’actualisation de l’expérience utilisateur, nous avons également ajouté deux fonctionnalités qui sont essentielles pour consommer des connexions de service dans des pipelines YAML : les autorisations et approbations de pipeline et les vérifications.

La nouvelle expérience utilisateur est activée par défaut avec cette mise à jour. Vous aurez toujours la possibilité de vous désinscrire de l'aperçu.

Note

Nous prévoyons d’introduire le partage entre projets de connexions de service en tant que nouvelle fonctionnalité. Vous trouverez plus d’informations sur l’expérience de partage et les rôles de sécurité ici.

Saut d’étapes dans un pipeline YAML

Lorsque vous démarrez une exécution manuelle, il se peut que vous souhaitiez parfois ignorer certaines étapes de votre pipeline. Par exemple, si vous ne souhaitez pas déployer en production, ou si vous souhaitez sauter le déploiement sur certains environnements en production. Vous pouvez maintenant effectuer cette opération avec vos pipelines YAML.

Le panneau de pipeline d’exécution mis à jour présente une liste d’étapes à partir du fichier YAML et vous avez la possibilité d’ignorer une ou plusieurs de ces phases. Vous devez faire preuve de prudence lorsque vous sautez des étapes. Par exemple, si votre première étape produit certains artefacts nécessaires pour les phases suivantes, vous ne devez pas ignorer la première étape. Le panneau d’exécution affiche un avertissement générique chaque fois que vous ignorez les étapes qui ont des dépendances en aval. Il vous reste à déterminer si ces dépendances sont de véritables dépendances d’artefact ou s’ils sont simplement présents pour le séquencement des déploiements.

Ignorer une étape équivaut à reconfigurer les dépendances entre les étapes. Toutes les dépendances en aval immédiates de l’étape ignorée sont faites pour dépendre du parent en amont de l’étape ignorée. Si l’exécution échoue et que vous tentez de réexécuter une étape ayant échoué, cette tentative présentera également le même comportement de saut. Pour modifier les étapes ignorées, vous devez lancer une nouvelle exécution.

Nouvelle interface utilisateur pour les connexions de service comme expérience par défaut

Il existe une nouvelle interface utilisateur des connexions de service. Cette nouvelle interface utilisateur est basée sur des normes de conception modernes et elle est fournie avec différentes fonctionnalités critiques pour prendre en charge les pipelines YAML CD multi-phases, tels que les approbations, les autorisations et le partage entre projets.

En savoir plus sur les connexions de service ici.

Sélecteur de version de ressource de pipeline dans la boîte de dialogue Créer une exécution

Nous avons ajouté la possibilité de sélectionner manuellement les versions de ressources de pipeline dans la boîte de dialogue de création de tâche. Si vous consommez un pipeline en tant que ressource dans un autre pipeline, vous pouvez désormais choisir la version de ce pipeline lors de la création d’une exécution.

az Améliorations de l’interface CLI pour Azure Pipelines

Groupe de variables Pipeline et commandes de gestion des variables

Il peut être difficile de porter des pipelines YAML d’un projet à un autre, car vous devez configurer manuellement les variables de pipeline et les groupes de variables. Toutefois, avec les commandes de gestion des variableset du groupe de variables de pipeline, vous pouvez maintenant créer un script pour configurer et gérer des variables de pipeline et des groupes de variables qui peuvent à leur tour être contrôlés par la version, ce qui vous permet de partager facilement les instructions permettant de déplacer et de configurer des pipelines d’un projet à un autre.

Exécution d’un pipeline pour une branche PR

Lors de la création d'une pull request, il peut être difficile de s'assurer que les modifications ne risquent pas de perturber le déroulement du pipeline sur la branche cible. Toutefois, avec la possibilité de déclencher l'exécution du pipeline ou de mettre en file d’attente une version pour une branche de PR, vous pouvez maintenant valider et visualiser les modifications en cours en les exécutant sur le pipeline cible. Pour plus d’informations, reportez-vous à la documentation des commandes az pipelines run et az pipelines build queue.

Ignorer la première exécution de pipeline

Lors de la création de pipelines, vous souhaitez parfois créer et valider un fichier YAML et ne pas déclencher l’exécution du pipeline, car cela peut entraîner une exécution défectueuse en raison de diverses raisons : l’infrastructure n’est pas prête ou n’a pas besoin de créer et de mettre à jour des groupes de variables/variables, etc. Avec Azure DevOps CLI, vous pouvez désormais ignorer la première exécution automatisée du pipeline lors de la création d’un pipeline en incluant le paramètre --skip-first-run. Pour plus d’informations, reportez-vous à az pipeline create command documentation .

Amélioration de la commande de point de terminaison de service

Les commandes CLI de point de terminaison de service ne prennent en charge que la configuration et la gestion des points de terminaison AzureRM et GitHub. Toutefois, avec cette version, les commandes de point de terminaison de service vous permettent de créer n’importe quel point de terminaison de service en fournissant la configuration via le fichier et fournit des commandes optimisées : az devops service-endpoint github et az devops service-endpoint azurerm, qui fournissent une prise en charge de première classe pour créer des points de terminaison de service de ces types. Pour plus d’informations, reportez-vous à la documentation de la commande .

Travaux de déploiement

Un travail de déploiement est un type spécial de travail utilisé pour déployer votre application dans un environnement. Avec cette mise à jour, nous avons ajouté la prise en charge des références d’étape dans un travail de déploiement. Par exemple, vous pouvez définir un ensemble d’étapes dans un fichier et y faire référence dans un travail de déploiement.

Nous avons également ajouté la prise en charge des propriétés supplémentaires au travail de déploiement. Par exemple, voici quelques propriétés d’un travail de déploiement que vous pouvez maintenant définir,

• timeoutInMinutes : durée d’exécution du travail avant l’annulation automatique
• cancelTimeoutInMinutes : durée d’exécution toujours même si les tâches annulées ont été annulées avant de les terminer
• condition : exécuter le travail de manière conditionnelle
• variables : les valeurs codées en dur peuvent être ajoutées directement, ou des groupes de variables, un groupe de variables soutenu par un coffre de clés Azure peut être référencé ou vous pouvez faire référence à un ensemble de variables définies dans un fichier.
• continueOnError : si les travaux futurs doivent s’exécuter même si ce travail de déploiement échoue ; la valeur par défaut est « false »

Pour plus d’informations sur les travaux de déploiement et la syntaxe complète pour spécifier un travail de déploiement, consultez Tâche de déploiement.

Affichage des informations sur les pipelines CD associés dans les pipelines CI

Nous avons ajouté le support pour les détails des pipelines YAML de CD, où les pipelines CI sont appelés ressources de pipeline. Dans la vue d’exécution de votre pipeline CI, vous verrez maintenant un nouvel onglet « Pipelines associés » dans lequel vous trouverez toutes les exécutions de pipeline qui consomment votre pipeline et les artefacts associés.

Prise en charge des packages GitHub dans des pipelines YAML

Nous avons récemment introduit un nouveau type de ressource appelé packages qui ajoute la prise en charge de l’utilisation de packages NuGet et npm à partir de GitHub en tant que ressource dans les pipelines YAML. Dans le cadre de cette ressource, vous pouvez maintenant spécifier le type de package (NuGet ou npm) que vous souhaitez consommer à partir de GitHub. Vous pouvez également activer les déclencheurs de pipeline automatisés lors de la publication d’une nouvelle version de package. Aujourd’hui, la prise en charge est disponible uniquement pour consommer des packages à partir de GitHub, mais nous prévoyons d’étendre la prise en charge pour consommer des packages à partir d’autres référentiels de packages tels que NuGet, npm, AzureArtifacts et bien plus encore. Pour plus d’informations, reportez-vous à l’exemple ci-dessous :

resources:
  packages:
    - package: myPackageAlias # alias for the package resource
      type: Npm # type of the package NuGet/npm
      connection: GitHubConn # Github service connection of type PAT
      name: nugetTest/nodeapp # <Repository>/<Name of the package>
      version: 1.0.9 # Version of the packge to consume; Optional; Defaults to latest
      trigger: true # To enable automated triggers (true/false); Optional; Defaults to no triggers

Note

Aujourd’hui, les packages GitHub prennent uniquement en charge l’authentification basée sur pat, ce qui signifie que la connexion de service GitHub dans la ressource de package doit être de type PAT. Une fois cette limitation levée, nous allons prendre en charge d’autres types d’authentification.

Par défaut, les packages ne sont pas téléchargés automatiquement dans vos travaux. Par conséquent, nous avons introduit une macro getPackage qui vous permet d’utiliser le package défini dans la ressource. Pour plus d’informations, reportez-vous à l’exemple ci-dessous :

- job: job1
  pool: default
  steps:
    - getPackage: myPackageAlias # Alias of the package resource

Lien vers le cluster Azure Kubernetes Service dans la vue des ressources des environnements Kubernetes

Nous avons ajouté un lien vers la vue des ressources des environnements Kubernetes afin de pouvoir accéder au panneau Azure du cluster correspondant. Cela s’applique aux environnements mappés à des espaces de noms dans des clusters Azure Kubernetes Service.

Filtres de dossier de mises en production dans les abonnements aux notifications

Les dossiers permettent d’organiser les pipelines pour faciliter la découverte et le contrôle de sécurité. Vous pouvez souvent configurer des notifications par e-mail personnalisées pour tous les pipelines de mise en production, qui sont représentées par tous les pipelines sous un dossier. Auparavant, vous deviez configurer plusieurs abonnements ou avoir une requête complexe dans les abonnements pour obtenir des e-mails ciblés. Avec cette mise à jour, vous pouvez maintenant ajouter une clause de dossier de mise en production au déploiement terminé et approuvé en attente d’événements et simplifier les abonnements.

Lier des éléments de travail avec des pipelines YAML à plusieurs étapes

Actuellement, vous pouvez lier automatiquement des éléments de travail avec des builds classiques. Toutefois, cela n’était pas possible avec les pipelines YAML. Avec cette mise à jour, nous avons résolu cet écart. Lorsque vous exécutez un pipeline avec succès à l’aide de code à partir d’une branche spécifiée, Azure Pipelines associe automatiquement l’exécution à tous les éléments de travail (qui sont déduits par le biais des validations dans ce code). Lorsque vous ouvrez l’élément de travail, vous pouvez voir les exécutions dans lesquelles le code de cet élément de travail a été généré. Pour configurer cela, utilisez le panneau paramètres d’un pipeline.

Annuler une phase dans une exécution de pipeline YAML à plusieurs phases

Lors de l’exécution d’un pipeline YAML à plusieurs étapes, vous pouvez maintenant annuler l’exécution d’une étape pendant qu’elle est en cours. Cela est utile si vous savez que l'étape va échouer ou si vous avez une autre exécution que vous souhaitez lancer.

Réessayer les étapes ayant échoué

L’une des fonctionnalités les plus demandées dans les pipelines à plusieurs étapes est la possibilité de réessayer une étape ayant échoué sans avoir à commencer à partir du début. Avec cette mise à jour, nous ajoutons une grande partie de cette fonctionnalité.

Vous pouvez maintenant réessayer une étape de pipeline en cas d’échec de l’exécution. Tous les travaux ayant échoué lors de la première tentative et ceux qui dépendent transitivement de ces travaux ayant échoué sont tous re-tentés.

Cela peut vous aider à gagner du temps de plusieurs façons. Par exemple, lorsque vous exécutez plusieurs travaux dans une phase, vous souhaiterez peut-être que chaque étape exécute des tests sur une autre plateforme. Si les tests sur une plateforme échouent alors que d’autres réussissent, vous pouvez gagner du temps en ne réexécutant pas les travaux qui ont réussi. Dans un autre exemple, une étape de déploiement peut avoir échoué à cause d’une connexion réseau instable. Une nouvelle tentative de cette étape vous aidera à gagner du temps en n’ayant pas à produire une autre build.

Il existe quelques lacunes connues dans cette fonctionnalité. Par exemple, vous ne pouvez pas réessayer une étape que vous annulez explicitement. Nous travaillons à combler ces lacunes dans les prochaines mises à jour.

Approbations dans les pipelines YAML à plusieurs phases

Vos pipelines YAML de CD peuvent inclure des approbations manuelles. Les propriétaires d'infrastructure peuvent protéger leurs environnements et demander des approbations manuelles avant qu'un stade dans n'importe quel pipeline ne soit déployé vers eux. Avec la séparation complète des rôles entre les propriétaires d’infrastructure (environnement) et d’application (pipeline), vous allez vous assurer de la validation manuelle du déploiement dans un pipeline particulier et obtenir un contrôle central pour appliquer les mêmes contrôles sur tous les déploiements dans l'environnement.

Le pipeline déployé vers l'environnement de développement s'arrête pour approbation au début de la phase.

Augmentation de la limite de délai d'expiration et de la fréquence des entrées

Auparavant, la limite de délai d’expiration du point de contrôle dans les pipelines de déploiement était de trois jours. Avec cette mise à jour, la limite de délai d’expiration a été augmentée à 15 jours pour autoriser les portes avec des durées plus longues. Nous avons également augmenté la fréquence d'accès à la porte à 30 minutes.

Nouveau modèle d’image de build pour Dockerfile

Auparavant, lors de la création d'un nouveau pipeline pour un Dockerfile, le modèle recommandait de pousser l'image vers un Registre de Conteneurs Azure et de la déployer sur un Azure Kubernetes Service. Nous avons ajouté un nouveau modèle pour vous permettre de générer une image à l'aide de l'agent sans avoir besoin de la pousser vers un registre de conteneurs.

Nouvelle tâche pour la configuration des paramètres d’application Azure App Service

Azure App Service autorise la configuration via différents paramètres tels que les paramètres d’application, les chaînes de connexion et d’autres paramètres de configuration généraux. Nous disposons maintenant d’une nouvelle tâche Azure Pipelines , Azure App Service Settings qui prend en charge la configuration de ces paramètres en bloc à l’aide de la syntaxe JSON sur votre application web ou l’un de ses emplacements de déploiement. Cette tâche peut être utilisée avec d’autres tâches App Service pour déployer, gérer et configurer vos applications web, applications de fonction ou tout autre app Services conteneurisé.

Azure App Service prend à présent en charge l’Échange avec aperçu

Azure App Service prend désormais en charge l’échange avec la préversion sur ses emplacements de déploiement. Il s’agit d’un bon moyen de valider l’application avec la configuration de production avant que l’application ne soit réellement permutée d’un emplacement intermédiaire en emplacement de production. Cela garantit également que l’emplacement cible/production ne subit pas de temps d’arrêt.

La tâche Azure App Service prend désormais en charge cette permutation multiphase via les nouvelles actions suivantes :

• Démarrez l’échange avec la préversion : lance un échange avec un aperçu (échange multiphase) et applique la configuration de l’emplacement cible (par exemple, l’emplacement de production) à l’emplacement source.
• Terminer l’échange avec la préversion : lorsque vous êtes prêt à terminer l’échange en attente, sélectionnez l’action Terminer l’échange avec préversion.
• Annuler l’échange avec la préversion : pour annuler un échange en attente, sélectionnez Annuler l’échange avec la préversion.

Filtre au niveau de l’étape pour les artefacts Azure Container Registry et Docker Hub

Auparavant, les filtres d’expressions régulières pour les artefacts Azure Container Registry et Docker Hub n’étaient disponibles qu’au niveau du pipeline de mise en production. Ils ont maintenant été ajoutés au niveau de l’étape.

Amélioration des approbations dans les pipelines YAML

Nous avons activé la configuration des approbations sur les connexions de service et les pools d’agents. Pour les approbations, nous suivons la séparation des rôles entre les propriétaires d’infrastructure et les développeurs. En configurant des approbations sur vos ressources telles que les environnements, les connexions de service et les pools d’agents, vous serez assuré que toutes les exécutions de pipeline qui utilisent des ressources nécessitent d’abord l’approbation.

L’expérience est similaire à la configuration des approbations pour les environnements. Lorsqu’une approbation est en attente sur une ressource référencée à une étape, l’exécution du pipeline attend que le pipeline soit approuvé manuellement.

Prise en charge des tests de structure de conteneur dans Azure Pipelines

L’utilisation des conteneurs dans les applications augmente et donc la nécessité de tests et de validations robustes. Azure Pipelines prend désormais en charge les tests de structure de conteneur. Cette infrastructure offre un moyen pratique et puissant de vérifier le contenu et la structure de vos conteneurs.

Vous pouvez valider la structure d’une image en fonction de quatre catégories de tests qui peuvent être exécutés ensemble : tests de commande, tests d’existence de fichiers, tests de contenu de fichier et tests de métadonnées. Vous pouvez utiliser les résultats dans le flux de travail pour prendre des décisions d'avancement ou de non-avancement. Les données de test sont disponibles dans le cadre de l'exécution du pipeline, accompagnées d'un message d'erreur pour vous aider à mieux identifier les échecs.

Entrer les détails du fichier de configuration et de l’image

Données de test et résumé

Éléments décoratifs de pipeline pour les pipelines de mise en production

Les décorateurs de pipeline permettent d’ajouter des étapes au début et à la fin de chaque tâche. Cela diffère de l’ajout d’étapes à une définition unique, car elle s’applique à tous les pipelines d’une collection.

Nous avons pris en charge les décorateurs pour les builds et les pipelines YAML, que les clients utilisent pour contrôler de manière centralisée les étapes de leurs tâches. Nous étendons maintenant la prise en charge des pipelines de mise en production. Vous pouvez créer des extensions pour ajouter des étapes ciblant le nouveau point de contribution et elles seront ajoutées à tous les travaux d’agent dans les pipelines de déploiement.

Déployer Azure Resource Manager (ARM) au niveau du groupe d’administration et de l’abonnement

Auparavant, nous avons pris en charge les déploiements uniquement au niveau du groupe de ressources. Avec cette mise à jour, nous avons ajouté la prise en charge du déploiement de modèles ARM aux niveaux d’abonnement et de groupe d’administration. Cela vous aidera lors du déploiement d’un ensemble de ressources, mais placez-les dans différents groupes de ressources ou abonnements. Par exemple, le déploiement de la machine virtuelle de sauvegarde pour Azure Site Recovery sur un groupe de ressources et un emplacement distincts.

Fonctionnalités de déploiement continu pour les pipelines YAML à plusieurs phases

Vous pouvez désormais consommer des artefacts publiés par votre pipeline CI et activer les déclencheurs d’achèvement du pipeline. Dans les pipelines YAML à plusieurs étapes, nous introduisons pipelines en tant que ressource. Dans votre YAML, vous pouvez maintenant faire référence à un autre pipeline et activer également des déclencheurs CD.

Voici le schéma YAML détaillé pour la ressource de pipelines.

resources: 
  pipelines:
  - pipeline: MyAppCI  # identifier for the pipeline resource
    project:  DevOpsProject # project for the build pipeline; optional input for current project
    source: MyCIPipeline  # source pipeline definition name
    branch: releases/M159  # branch to pick the artifact, optional; defaults to all branches
    version: 20190718.2 # pipeline run number to pick artifact; optional; defaults to last successfully completed run
    trigger:     # Optional; Triggers are not enabled by default.
      branches:  
        include:  # branches to consider the trigger events, optional; defaults to all branches.
        - main
        - releases/*
        exclude:   # branches to discard the trigger events, optional; defaults to none.
        - users/*  

En outre, vous pouvez télécharger les artéfacts publiés par votre ressource de pipeline en utilisant la tâche - download.

steps: 
- download: MyAppCI  # pipeline resource identifier
    artifact:  A1 # name of the artifact to download; optional; defaults to all artifacts

Pour plus d’informations, consultez la documentation sur le téléchargement des artefacts ici.

Orchestration de stratégie de déploiement avec contrôle de validité pour Kubernetes

L’un des principaux avantages de la livraison continue des mises à jour des applications est la possibilité d’envoyer rapidement des mises à jour en production pour des microservices spécifiques. Cela vous donne la possibilité de répondre rapidement aux changements apportés aux besoins de l’entreprise. L’environnement a été introduit en tant que concept de première classe permettant l’orchestration des stratégies de déploiement et facilitant les mises en production sans temps d’arrêt. Auparavant, nous avons pris en charge la stratégie runOnce qui a exécuté les étapes une fois séquentiellement. Grâce à la prise en charge de la stratégie canary dans les pipelines à plusieurs étapes, vous pouvez désormais réduire le risque en déployant lentement la modification vers un petit sous-ensemble. À mesure que vous gagnez en confiance dans la nouvelle version, vous pouvez commencer à le déployer sur davantage de serveurs dans votre infrastructure et acheminer davantage d’utilisateurs vers celui-ci.

jobs:
- deployment:
  environment: musicCarnivalProd
  pool:
    name: musicCarnivalProdPool 
  strategy:                 
    canary:     
      increments: [10,20] 
      preDeploy:                                    
        steps:          
        - script: initialize, cleanup....  
      deploy:            
        steps:
        - script: echo deploy updates...
        - task: KubernetesManifest@0
          inputs:
            action: $(strategy.action)      
            namespace: 'default'
            strategy: $(strategy.name)
            percentage: $(strategy.increment)
            manifests: 'manifest.yml'
      postRouteTaffic:
        pool: server
        steps:          
        - script: echo monitor application health...  
      on:
        failure:
          steps:
	  - script: echo clean-up, rollback...  
        success:
          steps:
          - script: echo checks passed, notify...

La stratégie canari pour Kubernetes déploiera d’abord les modifications avec 10 % de pods puis 20 %, tout en surveillant l’intégrité pendant postRouteTraffic. Si tout va bien, il atteindra les 100%.

Nous recherchons des commentaires précoces sur la prise en charge des ressources de machine virtuelle dans les environnements et l’exécution d’une stratégie de déploiement propagée sur plusieurs machines. Contactez-nous pour vous inscrire.

Stratégies d’approbation pour pipelines YAML

Dans les pipelines YAML, nous suivons une configuration d’approbation contrôlée par le propriétaire des ressources. Les propriétaires de ressources configurent des approbations sur la ressource, et tous les pipelines qui utilisent la ressource s’arrêtent pour les approbations avant le début de l’étape qui consomme la ressource. Il est courant pour les propriétaires d’applications dont les processus sont conformes à SOX de restreindre le demandeur du déploiement afin qu'il n'approuve pas ses propres déploiements.

Vous pouvez désormais utiliser des options d’approbation avancées pour configurer des stratégies d’approbation telles que le demandeur ne doit pas approuver, exiger l’approbation d’un sous-ensemble d’utilisateurs et d’un délai d’expiration d’approbation.

ACR en tant que ressource de pipeline de premier ordre

Si vous devez utiliser une image conteneur publiée dans ACR (Azure Container Registry) dans le cadre de votre pipeline et déclencher votre pipeline chaque fois qu’une nouvelle image a été publiée, vous pouvez utiliser la ressource de conteneur ACR.

resources:
  containers:
  - container: MyACR  #container resource alias
    type: ACR
    azureSubscription: RMPM  #ARM service connection
    resourceGroup: contosoRG
    registry: contosodemo
    repository: alphaworkz
    trigger: 
      tags:
        include: 
        - production 

De plus, les métadonnées d’image ACR sont accessibles à l’aide de variables prédéfinies. La liste suivante inclut les variables ACR disponibles pour définir une ressource de conteneur ACR dans votre pipeline.

resources.container.<Alias>.type
resources.container.<Alias>.registry
resources.container.<Alias>.repository
resources.container.<Alias>.tag 
resources.container.<Alias>.digest
resources.container.<Alias>.URI
resources.container.<Alias>.location

Améliorations apportées à l’évaluation de la stratégie de vérification des artefacts dans les pipelines

Nous avons amélioré la vérification de l’artefact d’évaluation pour faciliter l’ajout de stratégies à partir d’une liste des définitions de stratégie prêtes à l’emploi. La définition de stratégie est générée automatiquement et ajoutée à la configuration de vérification qui peut être mise à jour si nécessaire.

Prise en charge des variables de sortie dans un travail de déploiement

Vous pouvez maintenant définir des variables de sortie dans les hooks de cycle de vie d’un travail de déploiement et les consommer dans d’autres étapes et travaux en aval au sein de la même étape.

Lors de l’exécution de stratégies de déploiement, vous pouvez accéder aux variables de sortie entre les travaux à l’aide de la syntaxe suivante.

• Pour la stratégie RunOnce : $[dependencies.<job-name>.outputs['<lifecycle-hookname>.<step-name>.<variable-name>']]
• Pour la stratégie canary : $[dependencies.<job-name>.outputs['<lifecycle-hookname>_<increment-value>.<step-name>.<variable-name>']]
• Pour la stratégie de déploiement continu : $[dependencies.<job-name>.outputs['<lifecycle-hookname>_<resource-name>.<step-name>.<variable-name>']]

// Set an output variable in a lifecycle hook of a deployment job executing canary strategy
- deployment: A
  pool:
    vmImage: 'ubuntu-16.04'
  environment: staging
  strategy:                  
    canary:      
      increments: [10,20]  # creates multiple jobs, one for each increment. Output variable can be referenced with this.
      deploy:
        steps:
        - script: echo "##vso[task.setvariable variable=myOutputVar;isOutput=true]this is the deployment variable value"
          name: setvarStep
        - script: echo $(setvarStep.myOutputVar)
          name: echovar

 // Map the variable from the job
- job: B
  dependsOn: A
  pool:
    vmImage: 'ubuntu-16.04'
  variables:
    myVarFromDeploymentJob: $[ dependencies.A.outputs['deploy_10.setvarStep.myOutputVar'] ]
  steps:
  - script: "echo $(myVarFromDeploymentJob)"
    name: echovar

En savoir plus sur la configuration d’une variable de sortie multi-tâches

Éviter la restauration de changements critiques

Dans les pipelines de mise en production classiques, il est courant de s’appuyer sur des déploiements planifiés pour les mises à jour régulières. Toutefois, lorsque vous avez un correctif critique, vous pouvez choisir de démarrer un déploiement manuel hors bande. Dans ce cas, les versions antérieures continuent à être programmées. Cela posait un défi, car le déploiement manuel serait annulé lorsque les déploiements reprendraient selon le calendrier. Beaucoup d’entre vous ont signalé ce problème et nous l’avons maintenant résolu. Avec le correctif, tous les déploiements planifiés plus anciens sur l’environnement sont annulés lorsque vous démarrez manuellement un déploiement. Cela s’applique uniquement lorsque l’option de mise en file d’attente est sélectionnée comme « Déployer la dernière version et annuler d’autres personnes ».

Autorisation de ressources simplifiée dans les pipelines YAML

Une ressource est tout élément utilisé par un pipeline, mais qui se trouve à l'extérieur de celui-ci. Les ressources doivent être autorisées avant de pouvoir être utilisées. Auparavant, lors de l’utilisation de ressources non autorisées dans un pipeline YAML, elle a échoué avec une erreur d’autorisation de ressource. Vous deviez autoriser les ressources depuis la page récapitulative de l'exécution échouée. En outre, le pipeline échouait s’il utilisait une variable qui référençait une ressource non autorisée.

Nous allons maintenant faciliter la gestion des autorisations de ressources. Au lieu que l'exécution échoue, celle-ci attendra d'obtenir les autorisations d'accès aux ressources au début de l'étape qui consomme ces ressources. Un propriétaire de ressource peut afficher le pipeline et autoriser la ressource à partir de la page Sécurité.

Évaluation de contrôle d’artefact

Vous pouvez maintenant définir un ensemble de stratégies et ajouter l’évaluation de la stratégie en tant que vérification d’un environnement pour les artefacts d’image conteneur. Lorsqu’un pipeline s’exécute, l’exécution s’interrompt avant de démarrer une phase qui utilise l’environnement. La stratégie spécifiée est évaluée par rapport aux métadonnées disponibles pour l’image déployée. La vérification réussit si la politique est appliquée avec succès et, en cas d’échec de la vérification, l’étape est marquée comme échouée.

Mises à jour de la tâche de déploiement de modèle ARM

Auparavant, nous n’avons pas filtré les connexions de service dans la tâche de déploiement de modèle ARM. Cela peut entraîner l’échec du déploiement si vous sélectionnez une connexion de service d’étendue inférieure pour effectuer des déploiements de modèles ARM dans une étendue plus large. À présent, nous avons ajouté le filtrage des connexions de service pour filtrer les connexions de service à étendue inférieure en fonction de l’étendue de déploiement que vous choisissez.

ReviewApp dans environnement

ReviewApp déploie chaque pull request de votre dépôt Git vers une ressource d’environnement dynamique. Les réviseurs peuvent voir comment ces modifications s’affichent et fonctionnent avec d’autres services dépendants avant qu’elles ne soient fusionnées dans la branche principale et déployées en production. Cela vous permet de créer et de gérer facilement les ressources reviewApp et de tirer parti de toutes les fonctionnalités de traçabilité et de diagnostic des fonctionnalités d’environnement. En utilisant le mot clé reviewApp , vous pouvez créer un clone d’une ressource (créer dynamiquement une ressource basée sur une ressource existante dans un environnement) et ajouter la nouvelle ressource à l’environnement.

Voici un exemple d’extrait de code YAML d’utilisation de reviewApp sous les environnements.

jobs:
- deployment:
  environment: 
     name: smarthotel-dev      
     resourceName: $(System.PullRequest.PullRequestId) 
  pool:
    name: 'ubuntu-latest'
  strategy:                 
    runOnce:            
      pre-deploy: 
        steps:       
        - reviewApp: MainNamespace

Collecter des métadonnées automatiques et spécifiées par l’utilisateur à partir d’un pipeline

Vous pouvez maintenant activer la collecte automatique et spécifiée de métadonnées à partir de tâches de pipeline. Vous pouvez utiliser des métadonnées pour appliquer la politique d’artefact sur un environnement à l’aide de la vérification de l'évaluation de l’artefact.

Déploiements de machines virtuelles avec Environnements

L’une des fonctionnalités les plus demandées dans les environnements était les déploiements de machines virtuelles. Avec cette mise à jour, nous activons la ressource de machine virtuelle dans les environnements. Vous pouvez désormais orchestrer les déploiements sur plusieurs machines et effectuer des mises à jour successives à l’aide de pipelines YAML. Vous pouvez également installer l’agent sur chacun de vos serveurs cibles directement et piloter le déploiement propagé sur ces serveurs. En outre, vous pouvez utiliser le catalogue de tâches complet sur vos machines cibles.

Un déploiement progressif remplace les instances de la version précédente d’une application par des instances de la nouvelle version de l’application sur un ensemble progressif de machines à chaque itération.

Par exemple, un déploiement progressif met à jour jusqu'à cinq cibles à chaque itération. maxParallel détermine le nombre de cibles qui peuvent être déployées en parallèle. La sélection tient compte du nombre de cibles qui doivent rester disponibles à tout moment, à l’exclusion des cibles sur lesquelles le déploiement est en cours. Il est également utilisé pour déterminer les conditions de réussite et d’échec pendant le déploiement.

jobs:
- deployment:
  displayName: web
  environment:
    name: musicCarnivalProd
    resourceType: VirtualMachine
  strategy:                 
    rolling:
      maxParallel: 5 #for percentages, mention as x%
      preDeploy:
        steps:
        - script: echo initialize, cleanup, backup, install certs...
      deploy:              
        steps:                                     
        - script: echo deploy ...      
      routeTraffic:
        steps:
        - script: echo routing traffic...   
      postRouteTaffic:
        steps:          
        - script: echo health check post routing traffic...  
      on:
        failure:
          steps:
          - script: echo restore from backup ..     
        success:
          steps:
          - script: echo notify passed...

Note

Avec cette mise à jour, tous les artefacts disponibles à partir du pipeline actuel et des ressources de pipeline associées sont téléchargés uniquement dans deploy le hook de cycle de vie. Toutefois, vous pouvez choisir de télécharger en spécifiant la tâche Download Pipeline Artifact. Il existe quelques lacunes connues dans cette fonctionnalité. Par exemple, lorsque vous réessayez une étape, il réexécutera le déploiement sur toutes les machines virtuelles, pas seulement les cibles ayant échoué. Nous travaillons à combler ces lacunes dans les prochaines mises à jour.

Contrôle supplémentaire de vos déploiements

Azure Pipelines a pris en charge les déploiements contrôlés avec des approbations manuelles depuis un certain temps. Avec les dernières améliorations, vous disposez maintenant d’un contrôle supplémentaire sur vos déploiements. Outre les approbations, les propriétaires de ressources peuvent désormais ajouter automatiquement checks pour vérifier les stratégies de sécurité et de qualité. Ces vérifications peuvent être utilisées pour déclencher des opérations, puis attendre qu’elles se terminent. À l’aide des vérifications supplémentaires, vous pouvez maintenant définir des critères d’intégrité basés sur plusieurs sources et être assuré que tous les déploiements ciblant vos ressources sont sécurisés, quel que soit le pipeline YAML effectuant le déploiement. L’évaluation de chaque vérification peut être répétée régulièrement en fonction de l’intervalle de nouvelle tentative spécifié pour la vérification. Les vérifications supplémentaires suivantes sont désormais disponibles :

• Appeler n’importe quelle API REST et effectuer une validation en fonction du corps de la réponse ou d’un rappel à partir du service externe
• Appeler une fonction Azure et effectuer une validation en fonction de la réponse ou d’un rappel de la fonction
• Interroger les règles de surveillance Azure pour les alertes actives
• Vérifier que le pipeline étend un ou plusieurs modèles YAML

Notification d’approbation

Lorsque vous ajoutez une approbation à un environnement ou à une connexion de service, tous les pipelines à plusieurs étapes qui utilisent la ressource attendent automatiquement l’approbation au début de l’étape. Les approbateurs désignés doivent terminer l’approbation avant que le pipeline puisse continuer.

Avec cette mise à jour, les approbateurs sont envoyés une notification par e-mail pour l’approbation en attente. Les utilisateurs et les propriétaires d’équipe peuvent refuser ou configurer des abonnements personnalisés à l’aide des paramètres de notification.

Configurez les stratégies de déploiement à partir du portail Azure

Avec cette fonctionnalité, nous avons simplifié la configuration des pipelines qui utilisent la stratégie de déploiement de votre choix, par exemple Rolling, Canary ou Blue-Green. À l’aide de ces stratégies prêtes à l’emploi, vous pouvez déployer des mises à jour de manière sécurisée et atténuer les risques de déploiement associés. Pour y accéder, cliquez sur le paramètre « Livraison continue » dans une machine virtuelle Azure. Dans le volet de configuration, vous serez invité à sélectionner des détails sur le projet Azure DevOps dans lequel le pipeline sera créé, le groupe de déploiement, le pipeline de build qui publie le package à déployer et la stratégie de déploiement de votre choix. En continuant, vous allez configurer un pipeline entièrement fonctionnel qui déploie le package sélectionné sur cette Machine Virtuelle.

Pour plus d’informations, consultez notre documentation sur la configuration des stratégies de déploiement.

Paramètres de runtime

Les paramètres d’exécution vous permettent d’avoir plus de contrôle sur les valeurs qui peuvent être passées à un pipeline. Contrairement aux variables, les paramètres d’exécution ont des types de données et ne deviennent pas automatiquement des variables d’environnement. Avec les paramètres d’exécution, vous pouvez :

• Fournir différentes valeurs aux scripts et aux tâches au moment de l’exécution
• Types de paramètres de contrôle, plages autorisées et valeurs par défaut
• Sélectionner dynamiquement les tâches et les étapes avec l’expression de modèle

Pour en savoir plus sur les paramètres d’exécution, consultez la documentation ici.

Utiliser le mot clé extends dans des pipelines

Actuellement, les pipelines peuvent être extraits dans des gabarits, en favorisant la réutilisation et la réduction du code répétitif. La structure globale du pipeline a toujours été définie par le fichier YAML racine. Avec cette mise à jour, nous avons ajouté un moyen plus structuré d’utiliser des modèles de pipeline. Un fichier YAML racine peut désormais utiliser le mot clé s’étend pour indiquer que la structure de pipeline principale est disponible dans un autre fichier. Cela vous permet de contrôler quels segments peuvent être étendus ou modifiés et quels segments sont inchangeables. Nous avons également amélioré les paramètres de pipeline avec des types de données pour clarifier les points d'accroche que vous pouvez fournir.

Cet exemple montre comment vous pouvez fournir des crochets simples pour l'utilisation par l'auteur du pipeline. Le modèle exécute toujours une build, exécute éventuellement des étapes supplémentaires fournies par le pipeline, puis exécute une étape de test facultative.

# azure-pipelines.yml
extends:
  template: build-template.yml
  parameters:
    runTests: true
    postBuildSteps:
    - script: echo This step runs after the build!
    - script: echo This step does too!

# build-template.yml
parameters:
- name: runTests
  type: boolean
  default: false
- name: postBuildSteps
  type: stepList
  default: []
steps:
- task: MSBuild@1   # this task always runs
- ${{ if eq(parameters.runTests, true) }}:
  - task: VSTest@2  # this task is injected only when runTests is true
- ${{ each step in parameters.postBuildSteps }}:
  - ${{ step }}

Contrôler les variables pouvant être remplacées au moment de l’attente

Auparavant, vous pouvez utiliser l’interface utilisateur ou l’API REST pour mettre à jour les valeurs d’une variable avant de démarrer une nouvelle exécution. Bien que l’auteur du pipeline puisse marquer certaines variables comme _settable at queue time_, le système n’a pas appliqué cela, ni empêché d’autres variables d’être définies. En d’autres termes, le paramètre n’a été utilisé que pour demander des entrées supplémentaires lors du démarrage d’une nouvelle exécution.

Nous avons ajouté un nouveau paramètre de collection qui applique le _settable at queue time_ paramètre. Cela vous permet de contrôler les variables qui peuvent être modifiées lors du démarrage d’une nouvelle exécution. À l’avenir, vous ne pouvez pas modifier une variable qui n’est pas marquée par l’auteur comme _settable at queue time_.

Note

Ce paramètre est désactivé par défaut dans les collections existantes, mais il est activé par défaut lorsque vous créez une collection Azure DevOps.

Nouvelles variables prédéfinies dans le pipeline YAML

Les variables vous permettent d’entrer éléments de données clés dans différentes parties de votre pipeline. Avec cette mise à jour, nous avons ajouté quelques variables prédéfinies à un travail de déploiement. Ces variables sont automatiquement définies par le système, délimitées au travail de déploiement spécifique et sont en lecture seule.

• Environment.Id : ID de l’environnement.
• Environment.Name : nom de l’environnement ciblé par le travail de déploiement.
• Environment.ResourceId : ID de la ressource dans l’environnement ciblé par le travail de déploiement.
• Environment.ResourceName : nom de la ressource dans l’environnement ciblé par le travail de déploiement.

Extraction de plusieurs référentiels

Les pipelines s’appuient souvent sur plusieurs référentiels. Vous pouvez avoir différents référentiels avec des sources, des outils, des scripts ou d’autres éléments dont vous avez besoin pour générer votre code. Auparavant, vous deviez ajouter ces référentiels en tant que sous-modules ou en tant que scripts manuels pour exécuter git checkout. Vous pouvez maintenant récupérer et extraire d'autres dépôts, en plus de celui que vous utilisez pour stocker votre pipeline YAML.

Par exemple, si vous avez un référentiel appelé MyCode avec un pipeline YAML et un deuxième référentiel appelé Tools, votre pipeline YAML se présente comme suit :

resources:
  repositories:
  - repository: tools
    name: Tools
    type: git

steps:
- checkout: self
- checkout: tools
- script: dir $(Build.SourcesDirectory)

La troisième étape affiche deux répertoires, MyCode et Tools dans le répertoire sources.

Les référentiels Git Azure Repos sont pris en charge. Pour plus d’informations, consultez l’extraction de référentiels multiples.

Obtention de détails au moment de l’exécution concernant plusieurs référentiels

Lorsqu’un pipeline est en cours d’exécution, Azure Pipelines ajoute des informations sur le dépôt, la branche et la validation qui a déclenché l’exécution. Maintenant que les pipelines YAML prennent en charge l’extraction de plusieurs référentiels, vous pouvez également connaître le dépôt, la branche et le commit que vous avez extraits pour d’autres référentiels. Ces données sont disponibles via une expression runtime, que vous pouvez désormais mapper dans une variable. Par exemple:

resources:
  repositories:
  - repository: other
    type: git
    name: MyProject/OtherTools

variables:
  tools.ref: $[ resources.repositories['other'].ref ]

steps:
- checkout: self
- checkout: other
- bash: echo "Tools version: $TOOLS_REF"

Autoriser les références de référentiel à d’autres collections Azure Repos

Auparavant, lorsque vous référencez des référentiels dans un pipeline YAML, tous les référentiels Azure Repos devaient se trouver dans la même collection que le pipeline. À présent, vous pouvez pointer vers des référentiels dans d’autres collections à l’aide d’une connexion de service. Par exemple:

resources:
  repositories:
  - repository: otherrepo
    name: ProjectName/RepoName
    endpoint: MyServiceConnection
steps:
- checkout: self
- checkout: otherrepo

MyServiceConnection pointe vers une autre collection Azure DevOps et possède des informations d’identification qui peuvent accéder au référentiel dans un autre projet. Les deux dépôts, self et otherrepo, seront bien extraits.

Important

MyServiceConnection doit être une connexion de service Azure Repos / Team Foundation Server, consultez l’image ci-dessous.

Métadonnées de ressources de pipeline en tant que variables prédéfinies

Nous avons ajouté des variables prédéfinies pour les ressources de pipelines YAML dans le pipeline. Voici la liste des variables de ressource de pipeline disponibles.

resources.pipeline.<Alias>.projectName 
resources.pipeline.<Alias>.projectID 
resources.pipeline.<Alias>.pipelineName 
resources.pipeline.<Alias>.pipelineID 
resources.pipeline.<Alias>.runName 
resources.pipeline.<Alias>.runID
resources.pipeline.<Alias>.runURI
resources.pipeline.<Alias>.sourceBranch 
resources.pipeline.<Alias>.sourceCommit
resources.pipeline.<Alias>.sourceProvider 
resources.pipeline.<Alias>.requestedFor
resources.pipeline.<Alias>.requestedForID

kustomize et kompose en tant qu’options de bake dans la tâche KubernetesManifest

Kustomize (partie de Kubernetes sig-cli) vous permet de personnaliser des fichiers YAML bruts sans modèle à plusieurs fins et de laisser l’original YAML intact. Une option pour kustomize a été ajoutée sous l’action bake de la tâche KubernetesManifest afin que tout dossier contenant des fichiers kustomization.yaml puisse être utilisé pour générer les fichiers manifestes utilisés dans l’action de déploiement de la tâche KubernetesManifest.

steps:
- task: KubernetesManifest@0
  name: bake
  displayName: Bake K8s manifests from Helm chart
  inputs:
    action: bake
    renderType: kustomize
    kustomizationPath: folderContainingKustomizationFile

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

kompose transforme un fichier Docker Compose en ressource Kubernetes.

steps:
- task: KubernetesManifest@0
  name: bake
  displayName: Bake K8s manifests from Helm chart
  inputs:
    action: bake
    renderType: kompose
    dockerComposeFile: docker-compose.yaml

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

Prise en charge des informations d’identification d’administrateur de cluster dans une tâche HelmDeploy

Auparavant, la tâche HelmDeploy utilisait les informations d’identification de l’utilisateur du cluster pour les déploiements. Cela a entraîné des invites de connexion interactives et des pipelines défaillants pour un cluster RBAC basé sur Azure Active Directory. Pour résoudre ce problème, nous avons ajouté une case à cocher qui vous permet d’utiliser des informations d’identification d’administrateur de cluster au lieu d’informations d’identification d’utilisateur de cluster.

Saisie des arguments dans la tâche Docker Compose

Un nouveau champ a été introduit dans la tâche Docker Compose pour vous permettre d’ajouter des arguments tels que --no-cache. L’argument est transmis par la tâche lors de l’exécution de commandes telles que la compilation.

Amélioration des tâches de mise en production GitHub

Nous avons apporté plusieurs améliorations à la tâche GitHub Release. Vous pouvez maintenant avoir un meilleur contrôle sur la création de mise en production à l’aide du champ de modèle d’étiquette en spécifiant une expression régulière de balise et la mise en production sera créée uniquement lorsque la validation de déclenchement est marquée avec une chaîne correspondante.

Nous avons également ajouté des fonctionnalités pour personnaliser la création et la mise en forme du journal des modifications. Dans la nouvelle section de la configuration du journal des modifications, vous pouvez maintenant spécifier la version par rapport à laquelle la version actuelle doit être comparée. La comparaison à la version peut être la dernière version complète (exclut les préversions), la dernière version non préliminaire ou toute version précédente correspondant à votre balise de mise en production fournie. En outre, la tâche fournit un champ de type de journal de modification pour mettre en forme le journal des modifications. En fonction de la sélection, le journal des modifications affiche une liste de validations ou une liste de problèmes/demandes de tirage classés en fonction des étiquettes.

Tâche du programme d’installation de Open Policy Agent

Open Policy Agent est un moteur de stratégie open source à usage général qui permet l’application unifiée de la stratégie prenant en compte le contexte. Nous avons ajouté la tâche d’installation de l’agent Open Policy. Il est particulièrement utile pour l'application des règles en pipeline concernant les fournisseurs d'Infrastructure as Code.

Par exemple, l'Open Policy Agent peut évaluer les fichiers de stratégie Rego et les plans Terraform dans une pipeline.

task: OpenPolicyAgentInstaller@0
    inputs:
          opaVersion: '0.13.5'

Prise en charge des scripts PowerShell dans la tâche Azure CLI

Auparavant, vous pouvez exécuter des scripts batch et bash dans le cadre d’une tâche Azure CLI. Avec cette mise à jour, nous avons ajouté la prise en charge des scripts PowerShell et PowerShell Core à la tâche.

Déploiements avec contrôle de validité basés sur SMI (Service Mesh Interface) dans la tâche KubernetesManifest

Auparavant, lorsque la stratégie de canari était spécifiée dans la tâche KubernetesManifest, la tâche créait des charges de travail de base et de canari dont les réplicas étaient égaux à un pourcentage des réplicas utilisés pour les charges de travail stables. Ce n’était pas exactement le même que le fractionnement du trafic jusqu’au pourcentage souhaité au niveau de la requête. Pour résoudre ce problème, nous avons ajouté la prise en charge des déploiements canary basés sur l’interface Service Mesh à la tâche KubernetesManifest.

L’abstraction de l’interface Service Mesh permet une configuration plug-and-play avec des fournisseurs de maillage de services tels que Linkerd et Istio. Maintenant, la tâche KubernetesManifest supprime la complexité du mappage des objets TrafficSplit de SMI aux services stables, de base et de canari tout au long du cycle de vie de la stratégie de déploiement. Le fractionnement en pourcentage souhaité du trafic entre les versions stable, ligne de base et canary est plus précis, car ce fractionnement est contrôlé sur les requêtes dans le plan de maillage de service.

Voici un exemple d’exécution des déploiements canary basés sur SMI de manière progressive.

- deployment: Deployment
    displayName: Deployment
    pool:
      vmImage: $(vmImage)
    environment: ignite.smi
    strategy:
      canary:
        increments: [25, 50]
        preDeploy:
          steps:
          - task: KubernetesManifest@0
            displayName: Create/update secret
            inputs:
              action: createSecret
              namespace: smi
              secretName: $(secretName)
              dockerRegistryEndpoint: $(dockerRegistryServiceConnection)
        deploy:
          steps:
          - checkout: self
          - task: KubernetesManifest@0
            displayName: Deploy canary
            inputs:
              action: $(strategy.action)
              namespace: smi
              strategy: $(strategy.name)
              trafficSplitMethod: smi
              percentage: $(strategy.increment)
              baselineAndCanaryReplicas: 1
              manifests: |
                manifests/deployment.yml
                manifests/service.yml
              imagePullSecrets: $(secretName)
              containers: '$(containerRegistry)/$(imageRepository):$(Build.BuildId)'
        postRouteTraffic:
          pool: server
          steps:
            - task: Delay@1
              inputs:
                delayForMinutes: '2'

La tâche Azure File Copy prend désormais en charge AzCopy V10

La tâche de copie de fichiers Azure peut être utilisée dans un pipeline de build ou de mise en production pour copier des fichiers vers des objets blob de stockage Microsoft ou des machines virtuelles. La tâche utilise AzCopy, la build de l’utilitaire de ligne de commande pour copier rapidement des données depuis et dans des comptes de stockage Azure. Avec cette mise à jour, nous avons ajouté la prise en charge d’AzCopy V10, qui est la dernière version d’AzCopy.

La azcopy copy commande prend uniquement en charge les arguments associés. En raison de la modification de la syntaxe d’AzCopy, certaines des fonctionnalités existantes ne sont pas disponibles dans AzCopy V10. Voici quelques-uns des éléments suivants :

• Spécification de l’emplacement du fichier journal
• Nettoyage des fichiers de journal et de plan après la copie
• Reprendre la copie en cas d’échec du travail

Les fonctionnalités supplémentaires prises en charge dans cette version de la tâche sont les suivantes :

• Symboles génériques dans le nom de fichier/chemin d’accès de la source
• Inférence du type de contenu en fonction de l’extension de fichier lorsqu’aucun argument n’est fourni
• Définition du niveau de verbosité du journal pour le fichier de journal en définissant un argument

Amélioration de la sécurité des pipelines en limitant l’étendue des jetons d’accès

Chaque travail qui s’exécute dans Azure Pipelines obtient un jeton d’accès. Le jeton d'accès est utilisé par les tâches et par vos scripts pour interagir avec Azure DevOps. Par exemple, nous utilisons le jeton d’accès pour obtenir du code source, charger des journaux, des résultats de test, des artefacts ou effectuer des appels REST dans Azure DevOps. Un nouveau jeton d’accès est généré pour chaque travail et expire une fois le travail terminé. Avec cette mise à jour, nous avons ajouté les améliorations suivantes.

• Empêcher le jeton d’accéder aux ressources en dehors d’un projet d’équipe

  Jusqu’à présent, l’étendue par défaut de tous les pipelines était la collection de projets d’équipe. Vous pouvez modifier la portée pour qu'elle soit le projet de l'équipe dans les pipelines de build classiques. Cependant, vous n'aviez pas ce contrôle pour les pipelines de publication classiques ou YAML. Avec cette mise à jour, nous introduisons un paramètre de collection pour forcer chaque travail à obtenir un jeton à l'échelle du projet, indépendamment du paramètre configuré dans le pipeline. Nous avons également ajouté le paramètre au niveau du projet. À présent, chaque nouveau projet et collection que vous créez aura automatiquement activé ce paramètre.

  Note

  Le paramètre de collection remplace le paramètre de projet.

  L’activation de ce paramètre dans les projets et collections existants peut entraîner l’échec de certains pipelines si vos pipelines accèdent aux ressources qui se trouvent en dehors du projet d’équipe à l’aide de jetons d’accès. Pour atténuer les échecs de pipeline, vous pouvez explicitement accorder l’accès au compte de service de build du projet à la ressource souhaitée. Nous vous recommandons vivement d’activer ces paramètres de sécurité.

• Limiter l'accès à l'étendue des dépôts du service de build

  En s’appuyant sur l’amélioration de la sécurité du pipeline en limitant l’étendue du jeton d’accès, Azure Pipelines peut désormais étendre son accès au référentiel uniquement aux dépôts requis pour un pipeline YAML. Cela signifie que si le jeton d’accès des pipelines venait à fuiter, il ne pourrait voir que les référentiels utilisés dans le pipeline. Auparavant, le jeton d’accès était adapté à n’importe quel dépôt Azure Repos dans le projet, ou potentiellement à l’ensemble de la collection.

  Cette fonctionnalité sera activée par défaut pour les nouveaux projets et collections. Pour les collections existantes, vous devez l’activer dans les Paramètres des collections>Pipelines>Paramètres. Lorsque vous utilisez cette fonctionnalité, tous les référentiels nécessaires à la build (même ceux que vous clonez à l’aide d’un script) doivent être inclus dans les ressources de référentiel du pipeline.

• Supprimer certaines autorisations pour le jeton d’accès

  Par défaut, nous accordons un certain nombre d’autorisations au jeton d’accès, dont l'une est Lancer des builds. Avec cette mise à jour, nous avons supprimé cette autorisation pour le jeton d’accès. Si vos pipelines ont besoin de cette autorisation, vous pouvez l’accorder explicitement au compte de service de génération de projet ou au compte de service de génération de regroupement de projets, en fonction du jeton que vous utilisez.

sécurité au niveau du projet pour les connexions de service

Nous avons ajouté la sécurité au niveau du hub pour les connexions de service. À présent, vous pouvez ajouter/supprimer des utilisateurs, attribuer des rôles et gérer l’accès à un emplacement centralisé pour toutes les connexions de service.

Ciblage des étapes et isolation des commandes

Azure Pipelines prend en charge l’exécution de travaux dans des conteneurs ou sur l’hôte de l’agent. Auparavant, une tâche entière était attribuée à l’une de ces deux cibles. À présent, les étapes individuelles (tâches ou scripts) peuvent s’exécuter sur la cible que vous choisissez. Les étapes peuvent également cibler d’autres conteneurs, afin qu’un pipeline puisse exécuter chaque étape dans un conteneur spécialisé et conçu à usage unique.

Les conteneurs peuvent agir comme des limites d’isolation, ce qui empêche le code d’apporter des modifications inattendues sur l’ordinateur hôte. La façon dont les étapes communiquent avec et accèdent aux services de l’agent n’est pas affectée par l’isolation des étapes dans un conteneur. Par conséquent, nous introduisons également un mode de restriction de commande que vous pouvez utiliser avec des cibles d’étape. L’activation de cette option limite les services qu’une étape peut demander à l’agent. Il ne sera plus en mesure d’attacher des journaux, de téléverser des artefacts et d'effectuer certaines autres opérations.

Voici un exemple complet démontrant la manière dont les étapes sont exécutées sur l'hôte dans un conteneur de tâche, et dans un autre conteneur :

resources:
  containers:
  - container: python
    image: python:3.8
  - container: node
    image: node:13.2

jobs:
- job: example
  container: python

  steps:
  - script: echo Running in the job container

  - script: echo Running on the host
    target: host

  - script: echo Running in another container, in restricted commands mode
    target:
      container: node
      commands: restricted

Variables en lecture seule

Les variables système ont été documentées comme étant immuables, mais dans la pratique, elles pourraient être remplacées par une tâche et les tâches en aval récupèrent la nouvelle valeur. Avec cette mise à jour, nous resserrons la sécurité autour des variables de pipeline pour rendre les variables système et de temps d’attente en lecture seule. En outre, vous pouvez créer une variable YAML en lecture seule en la marquant comme suit.

variables:
- name: myVar
  value: myValue
  readonly: true

Accès en fonction du rôle pour les connexions de service

Nous avons ajouté l’accès en fonction du rôle pour les connexions de service. Auparavant, la sécurité des connexions de service ne pouvait être gérée que par le biais de groupes Azure DevOps prédéfinis tels que les administrateurs de point de terminaison et les créateurs de points de terminaison.

Dans le cadre de ce travail, nous avons introduit les nouveaux rôles de lecteur, d’utilisateur, de créateur et d’administrateur. Vous pouvez définir ces rôles via la page connexions de service de votre projet et celles-ci sont héritées par les connexions individuelles. Dans chaque connexion de service, vous avez la possibilité d’activer/désactiver l’héritage et de substituer les rôles au sein de la connexion de service.

En savoir plus sur la sécurité des connexions de service ici.

Partage entre projets des connexions de service

Nous avons activé la prise en charge du partage de connexion de service entre les projets. Vous pouvez désormais partager vos connexions de service avec vos projets en toute sécurité.

En savoir plus sur le partage des connexions de service ici.

Traçabilité pour les pipelines et les ressources ACR

Nous assurons une traçabilité E2E complète lorsque les pipelines et les ressources de conteneur ACR sont utilisés dans un pipeline. Pour chaque ressource consommée par votre pipeline YAML, vous pouvez effectuer le suivi des validations, des éléments de travail et des artefacts.

Dans la vue récapitulative de l’exécution du pipeline, vous pouvez voir :

• Version de ressource qui a déclenché l’exécution. À présent, votre pipeline peut être déclenché à la fin d’une autre exécution de pipeline Azure ou lorsqu’une image conteneur est envoyée à ACR.

  

• Les commits consommés par le pipeline. Vous pouvez également trouver la répartition des validations par chaque ressource consommée par le pipeline.

  

• Éléments de travail associés à chaque ressource consommée par le pipeline.

• Artefacts disponibles pour être utilisés lors du processus d'exécution.

  

Dans la vue des déploiements de l’environnement, vous pouvez voir les commits et les éléments de travail pour chaque ressource déployée dans l’environnement.

Prise en charge des pièces jointes de test volumineuses

La tâche de publication des résultats des tests dans Azure Pipelines vous permet de publier les résultats des tests lorsque des tests sont exécutés pour fournir une expérience complète de création de rapports et d’analytique de test. Jusqu’à présent, il y avait une limite de 100 Mo pour les pièces jointes de test pour l’exécution de test et les résultats des tests. Cela a limité le chargement de fichiers volumineux, tels que les vidages sur incident ou les vidéos. Avec cette mise à jour, nous avons ajouté la prise en charge des pièces jointes de test volumineuses, ce qui vous permet de disposer de toutes les données disponibles pour résoudre vos échecs de tests.

Vous pourriez voir la tâche VSTest ou la tâche de publication des résultats de test renvoyant une erreur 403 ou 407 dans les journaux. Si vous utilisez des builds auto-hébergées ou des agents de mise en production derrière un pare-feu qui filtre les demandes sortantes, vous devez apporter des modifications de configuration pour pouvoir utiliser cette fonctionnalité. ​

Pour résoudre ce problème, nous vous recommandons de mettre à jour le pare-feu pour les demandes sortantes vers https://*.vstmrblob.vsassets.io. Vous trouverez des informations de dépannage dans la documentation ici. ​

Note

Cela n’est nécessaire que si vous utilisez des agents Azure Pipelines auto-hébergés et que vous êtes derrière un pare-feu qui filtre le trafic sortant. Si vous utilisez des agents hébergés par Microsoft dans le cloud ou qui ne filtrent pas le trafic réseau sortant, vous n’avez pas besoin d’effectuer d’action.

Afficher les informations de pool correctes pour chaque travail

Auparavant, lorsque vous utilisiez une matrice pour étendre des tâches ou une variable pour identifier un pool, nous avons parfois obtenu des informations de pool incorrectes dans les pages des logs. Ces problèmes ont été résolus.

Déclencheurs CI pour les nouvelles branches

Il s'agit d'une demande en attente depuis longtemps pour ne pas déclencher les builds CI lorsqu’une nouvelle branche est créée et lorsque cette branche ne contient pas de modifications. Prenons les exemples suivants :

• Vous utilisez l’interface web pour créer une branche basée sur une branche existante. Cela déclenche immédiatement une nouvelle build CI si votre filtre de branche correspond au nom de la nouvelle branche. Cela est indésirable, car le contenu de la nouvelle branche est identique par rapport à la branche existante.
• Vous disposez d’un référentiel avec deux dossiers : l’application et la documentation. Vous configurez un filtre de chemin pour que CI corresponde à « app ». En d’autres termes, vous ne souhaitez pas créer de build si une modification a été envoyée à la documentation. Vous créez une branche localement, apportez des modifications à la documentation, puis envoyez cette branche au serveur. Nous déclenchions une nouvelle compilation d'intégration continue (CI). Ceci est indésirable, car vous avez explicitement demandé de ne pas rechercher de modifications dans le dossier docs. Toutefois, en raison de la façon dont nous avons géré un nouvel événement de branche, il semblerait qu’une modification ait également été apportée au dossier de l’application.

Maintenant, nous avons un meilleur moyen de gérer l'intégration continue pour les nouvelles branches afin de traiter ces problèmes. Lorsque vous publiez une nouvelle branche, nous recherchons explicitement de nouveaux commits dans cette branche et vérifions s'ils correspondent aux filtres de chemin d’accès.

Les travaux peuvent accéder aux variables de sortie des étapes précédentes

Les variables de sortie peuvent désormais être utilisées à plusieurs étapes dans un pipeline YAML. Cela vous permet de transmettre des informations utiles, telles qu’une décision go/no-go ou l’ID d’une sortie générée, d’une étape à l’autre. Le résultat (état) d'une étape précédente et ses tâches sont également disponibles.

Les variables de sortie sont toujours produites par les étapes à l’intérieur des travaux. Au lieu de faire référence à dependencies.jobName.outputs['stepName.variableName'], les phases font référence à stageDependencies.stageName.jobName.outputs['stepName.variableName'].

Note

Par défaut, chaque index d’un pipeline dépend de celui qui se trouve juste avant lui dans le fichier YAML. Par conséquent, chaque index peut utiliser des variables de sortie issues de l’index précédent. Vous pouvez modifier le graphique de dépendances, qui modifie également les variables de sortie disponibles. Par exemple, si l’étape 3 a besoin d’une variable de l’étape 1, elle doit déclarer une dépendance explicite à l’étape 1.

Désactiver les mises à niveau automatiques des agents au niveau du pool

Actuellement, les agents de pipelines sont automatiquement mis à jour vers la dernière version si nécessaire. Cela se produit généralement lorsqu’il existe une nouvelle fonctionnalité ou une tâche qui nécessite une version d’agent plus récente pour fonctionner correctement. Avec cette mise à jour, nous ajoutons la possibilité de désactiver les mises à niveau automatiques au niveau d’un pool. Dans ce mode, si aucun agent de la version correcte n’est connecté au pool, les pipelines échouent avec un message d’erreur clair au lieu de demander aux agents de mettre à jour. Cette fonctionnalité est principalement intéressante pour les clients avec des pools auto-hébergés et des exigences de contrôle des modifications très strictes. Les mises à jour automatiques sont activées par défaut et nous vous déconseillons la plupart des clients de les désactiver.

Diagnostics de l’agent

Nous avons ajouté des diagnostics pour de nombreux problèmes courants liés à l’agent, tels que de nombreux problèmes réseau et causes courantes des défaillances de mise à niveau. Pour commencer à utiliser les diagnostics, utilisez run.sh --diagnostics ou run.cmd --diagnostics sur Windows.

Crochets de service pour les pipelines YAML

L’intégration de services avec des pipelines YAML s’est simplement facilitée. À l’aide d’événements de hooks de service pour les pipelines YAML, vous pouvez désormais générer des activités dans des applications ou des services personnalisés en fonction de la progression des exécutions du pipeline. Par exemple, vous pouvez créer un ticket de support technique lorsqu’une approbation est requise, lancer un flux de travail de surveillance une fois qu’une étape est terminée ou envoyer une notification Push aux appareils mobiles de votre équipe en cas d’échec d’une phase.

Le filtrage sur le nom du pipeline et le nom d’étape est pris en charge pour tous les événements. Les événements d’approbation peuvent également être filtrés pour des environnements spécifiques. De même, les événements de modification d’état peuvent être filtrés par un nouvel état de l’exécution du pipeline ou par l’étape.

Intégration d’Optimizely

Optimizely est une puissante plateforme de test A/B et d’indicateur de fonctionnalités pour les équipes de produits. L’intégration d’Azure Pipelines à la plateforme d’expérimentation Optimizely permet aux équipes de produits de tester, d’apprendre et de déployer à un rythme accéléré, tout en obtenant tous les avantages devOps d’Azure Pipelines.

L’extension Optimizely pour Azure DevOps ajoute des étapes de déploiement d’expérimentation et d’indicateur de fonctionnalité aux pipelines de génération et de mise en production. Vous pouvez donc itérer en continu, déployer des fonctionnalités et les restaurer à l’aide d’Azure Pipelines.

En savoir plus sur l’extension Azure DevOps Optimizely ici.

Ajouter une mise en production GitHub en tant que source d’artefact

Vous pouvez maintenant lier vos versions GitHub en tant que source d’artefact dans les pipelines de mise en production Azure DevOps. Cela vous permet d’utiliser la version GitHub dans le cadre de vos déploiements.

Lorsque vous cliquez sur Ajouter un artefact dans la définition du pipeline de mise en production, vous trouverez le nouveau type de source GitHub Release . Vous pouvez fournir la connexion de service et le dépôt GitHub pour utiliser la version GitHub. Vous pouvez également choisir une version par défaut pour la version GitHub à consommer comme version de balise la plus récente, spécifique ou sélectionner au moment de la création de la version. Une fois qu’une version GitHub est liée, elle est automatiquement téléchargée et mise à disposition dans vos travaux de mise en production.

Intégration de Terraform à Azure Pipelines

Terraform est un outil open source pour développer, modifier et versionner l'infrastructure de manière sûre et efficace. Terraform codifie les API dans des fichiers de configuration déclaratifs, ce qui vous permet de définir et de provisionner une infrastructure à l’aide d’un langage de configuration de haut niveau. Vous pouvez utiliser l’extension Terraform pour créer des ressources dans tous les principaux fournisseurs d’infrastructure : Azure, Amazon Web Services (AWS) et Google Cloud Platform (GCP).

Pour en savoir plus sur l’extension Terraform, consultez la documentation ici.

Intégration à Google Analytics

L’infrastructure d’expériences Google Analytics vous permet de tester presque toutes les modifications ou variantes d’un site web ou d’une application pour mesurer son impact sur un objectif spécifique. Par exemple, vous pouvez avoir des activités que vous souhaitez que vos utilisateurs se terminent (par exemple, effectuer un achat, s’inscrire à un bulletin d’informations) et/ou des métriques que vous souhaitez améliorer (par exemple, chiffre d’affaires, durée de session, taux de rebond). Ces activités vous permettent d’identifier les modifications qui méritent d’être implémentées en fonction de l’impact direct qu’elles ont sur les performances de votre fonctionnalité.

L’extension d’expériences Google Analytics pour Azure DevOps ajoute des étapes d’expérimentation aux pipelines de génération et de mise en production. Vous pouvez donc itérer, apprendre et déployer à un rythme accéléré en gérant les expériences en continu tout en obtenant tous les avantages DevOps d’Azure Pipelines.

Vous pouvez télécharger l’extension d’expériences Google Analytics à partir de la Place de marché.

Mise à jour de l'intégration de ServiceNow à Azure Pipelines

L’application Azure Pipelines pour ServiceNow permet d’intégrer Azure Pipelines et ServiceNow Change Management. Avec cette mise à jour, vous pouvez intégrer la version new-yorkaise de ServiceNow. L’authentification entre les deux services peut désormais être effectuée à l’aide d’OAuth et de l’authentification de base. En outre, vous pouvez maintenant configurer des critères de réussite avancés, vous permettant d'utiliser n'importe quelle propriété de changement pour déterminer le résultat du processus.

Créer Azure Pipelines à partir de VSCode

Nous avons ajouté une nouvelle fonctionnalité à l’extension Azure Pipelines pour VSCode. À présent, vous pourrez créer Azure Pipelines directement à partir de VSCode sans quitter l’IDE.

Gestion et résolution des bugs instables

Nous avons introduit la gestion des tests flaky pour prendre en charge le cycle de vie de bout en bout avec la détection, la création de rapports et la résolution. Pour l’améliorer encore, nous ajoutons la gestion et la résolution des bogues de tests instables.

Lors de l’examen du test flaky, vous pouvez créer un bogue à l’aide de l’action Bogue qui peut ensuite être affectée à un développeur pour approfondir l’examen de la cause racine du test flaky. Le rapport de bogue inclut des informations sur le pipeline, comme le message d’erreur, la trace de pile et d’autres informations associées au test.

Lorsqu’un rapport de bogue est résolu ou fermé, nous dé-marquerons automatiquement le test comme étant non instable.

Configurer l'échec de tâches VSTest si un nombre minimal de tests n'est pas exécuté

La tâche VSTest découvre et exécute des tests à l’aide d’entrées utilisateur (fichiers de test, critères de filtre, etc.) ainsi qu’un adaptateur de test spécifique à l’infrastructure de test utilisée. Les modifications apportées aux entrées utilisateur ou à l’adaptateur de test peuvent entraîner des cas où les tests ne sont pas découverts et qu’un sous-ensemble des tests attendus est exécuté. Cela peut entraîner des situations où les pipelines réussissent parce que les tests sont ignorés plutôt que parce que le code est suffisamment de haute qualité. Pour éviter cette situation, nous avons ajouté une nouvelle option dans la tâche VSTest qui vous permet de spécifier le nombre minimal de tests qui doivent être exécutés pour que la tâche réussisse.

L’option VSTest TestResultsDirectory est disponible dans l’IU de tâche

La tâche VSTest stocke les résultats des tests et les fichiers associés dans le $(Agent.TempDirectory)\TestResults dossier. Nous avons ajouté une option à l’interface utilisateur de tâche pour vous permettre de configurer un autre dossier pour stocker les résultats des tests. À présent, toutes les tâches suivantes qui ont besoin des fichiers dans un emplacement particulier peuvent les utiliser.

Prise en charge de markdown dans les messages d’erreur de test automatisé

Nous avons ajouté la prise en charge du markdown aux messages d’erreur pour les tests automatisés. Vous pouvez désormais facilement mettre en forme des messages d’erreur pour l’exécution de test et le résultat de test afin d’améliorer la lisibilité et de faciliter l’expérience de résolution des problèmes d’échec de test dans Azure Pipelines. La syntaxe markdown prise en charge est disponible ici.

Utilisation d’éléments décoratifs de pipeline pour injecter automatiquement des étapes dans un travail de déploiement

Vous pouvez maintenant ajouter des décorateurs de pipeline aux travaux de déploiement. Vous pouvez avoir n’importe quelle étape personnalisée (par exemple, analyseur de vulnérabilités) injectée automatiquement à chaque exécution de hook de cycle de vie de chaque tâche de déploiement. Étant donné que les décorateurs de pipeline peuvent être appliqués à tous les pipelines d'une collection, cela peut être exploité pour imposer des pratiques de déploiement sécurisées.

En outre, les travaux de déploiement peuvent être exécutés en tant que tâche de conteneur avec les services auxiliaires s’ils sont définis.

Test Plans

Page Nouveau plan de test

Une nouvelle page Plans de test (Plans de test *) est disponible pour toutes les collections Azure DevOps. La nouvelle page fournit des vues simplifiées pour vous aider à vous concentrer sur la tâche en main : planification des tests, création ou exécution. Il est également sans encombrement et cohérent avec le reste de l’offre Azure DevOps.

Aidez-moi à comprendre la nouvelle page

La nouvelle page Plans de test comporte au total 6 sections dont les 4 premières sont nouvelles, tandis que les sections Graphiques et Extensibilité sont les fonctionnalités existantes.

1. En-tête du plan de test : utilisez-le pour localiser, favori, modifier, copier ou cloner un plan de test.
2. Arborescence des suites de test : utilisez cette option pour ajouter, gérer, exporter ou commander des suites de test. Tirez parti de cela pour affecter également des configurations et effectuer des tests d’acceptation des utilisateurs.
3. Définir l’onglet : Collez, ajoutez et gérez des cas de test dans une suite de tests de choix via cet onglet.
4. Onglet Exécuter : affectez et exécutez des tests via cet onglet ou recherchez un résultat de test à explorer.
5. Onglet Graphique : effectuez le suivi de l’exécution et de l’état des tests via des graphiques qui peuvent également être épinglés aux tableaux de bord.
6. Extensibilité : prend en charge les points d’extensibilité actuels dans le produit.

Prenons un aperçu général de ces nouvelles sections ci-dessous.

1. En-tête de plan de test

Tâches

L’en-tête Plan de test vous permet d’effectuer les tâches suivantes :

• Marquer un plan de test comme favori
• Démarquer un plan de test marqué comme favori
• Naviguer facilement entre vos plans de test favoris
• Afficher le chemin d’itération du plan de test, qui indique clairement si le plan de test est actif ou passé
• Afficher le résumé rapide du rapport de progression des tests avec un lien pour accéder au rapport
• Revenez à la page Plans de test all/Mine

Options du menu contextuel

Le menu contextuel de l’en-tête Plan de test fournit les options suivantes :

• Plan de test de copie : il s’agit d’une nouvelle option qui vous permet de copier rapidement le plan de test actuel. Plus d’informations ci-dessous.
• Modifier le plan de test : cette option vous permet de modifier le formulaire d’élément de travail plan de test pour gérer les champs de l’élément de travail.
• Paramètres du plan de test : cette option vous permet de configurer les paramètres d’exécution de test (pour associer des pipelines de génération ou de mise en production) et les paramètres de résultat du test

Plan de test de copie (nouvelle fonctionnalité)

Nous vous recommandons de créer un plan de test par sprint/mise en production. Dans ce cas, le plan de test pour le cycle précédent peut généralement être copié et, avec quelques modifications, le plan de test copié est prêt pour le nouveau cycle. Pour faciliter ce processus, nous avons activé une fonctionnalité « Copier un plan de test » sur la nouvelle page. En tirant parti de celui-ci, vous pouvez copier ou cloner des plans de test. Son API REST de stockage est abordée ici et l’API vous permet également de copier/cloner un plan de test entre les projets.
Pour plus d’instructions sur l’utilisation des plans de test, reportez-vous ici.

2. Arborescence des suites de test

Tâches

L’en-tête test suite vous permet d’effectuer les tâches suivantes :

• Développer/réduire : ces options de barre d’outils vous permettent de développer ou de réduire l’arborescence de hiérarchie de suite.
• Afficher les points de test des suites enfants : cette option de barre d’outils est visible uniquement lorsque vous êtes dans l’onglet « Exécuter ». Cela vous permet d’afficher tous les points de test pour la suite donnée et ses enfants dans une vue pour faciliter la gestion des points de test sans avoir à accéder à des suites individuelles un par un.
• Suites d’ordre : vous pouvez faire glisser/déplacer des suites pour réorganiser la hiérarchie des suites ou les déplacer d’une hiérarchie de suite vers une autre dans le plan de test.

Options du menu contextuel

Le menu contextuel de l’arborescence Suites de tests fournit les options suivantes :

• Créer des suites : vous pouvez créer 3 types de suites différents comme suit :
  • Utilisez la suite statique ou la suite de dossiers pour organiser vos tests.
  • Utilisez la suite basée sur les exigences pour lier directement les exigences ou récits utilisateur, assurant ainsi une traçabilité transparente.
  • Utilisez la fonction basée sur une requête pour organiser dynamiquement les cas de test qui répondent à un critère de requête.
• Attribuer des configurations : vous pouvez affecter des configurations pour la suite (par exemple, Chrome, Firefox, EdgeChromium), et celles-ci s’appliquent ensuite à tous les cas de test existants ou aux nouveaux cas de test que vous ajoutez ultérieurement à cette suite.
• Exporter en tant que pdf/e-mail : exportez les propriétés du plan de test, les propriétés de la suite de tests ainsi que les détails des cas de test et des points de test comme « e-mail » ou « imprimer au format pdf ».
• Ouvrir l’élément de travail de suite de test : cette option vous permet de modifier le formulaire d’élément de travail de la suite de tests pour gérer les champs de l’élément de travail.
• Attribuez des testeurs pour exécuter tous les tests : cette option est très utile pour les scénarios de test d’acceptation de l’utilisateur (UAT) où le même test doit être exécuté/exécuté par plusieurs testeurs, généralement appartenant à différents services.
• Renommer/supprimer : ces options vous permettent de gérer le nom de la suite ou de supprimer la suite et son contenu du plan de test.

3. Définissez l’onglet

L’onglet Définir vous permet de rassembler, d’ajouter et de gérer des cas de test pour une suite de tests. Alors que l’onglet d’exécution consiste à affecter des points de test et à les exécuter.

L’onglet Définir et certaines opérations sont uniquement disponibles pour les utilisateurs disposant d’un niveau d’accès Basic + Test Plans ou équivalent. Tout le reste doit être exercé par un utilisateur avec le niveau d’accès « De base ».

Tâches

L’onglet Définir vous permet d’effectuer les tâches suivantes :

• Ajouter un nouveau cas de test à l’aide d’un formulaire d’élément de travail : cette option vous permet de créer un cas de test à l’aide du formulaire d’élément de travail. Le cas de test créé sera automatiquement ajouté à la suite.
• Ajouter un nouveau cas de test à l’aide de la grille : cette option vous permet de créer un ou plusieurs cas de test à l’aide de la vue grille des cas de test. Les cas de test créés seront automatiquement ajoutés à la suite.
• Ajouter des cas de test existants à l’aide d’une requête : cette option vous permet d’ajouter des cas de test existants à la suite en spécifiant une requête.
• Réorganisez les cas de test par glisser-déplacer : vous pouvez réorganiser les cas de test en faisant glisser et déplacer un ou plusieurs cas de test au sein d'une suite de tests donnée. L’ordre des cas de test s’applique uniquement aux cas de test manuels et non aux tests automatisés.
• Déplacer des cas de test d’une suite à l’autre : à l’aide d’un glisser-déplacer, vous pouvez déplacer des cas de test d’une suite de tests vers une autre.
• Afficher la grille : vous pouvez utiliser le mode grille pour afficher/modifier les cas de test, ainsi que les étapes de test.
• Mode Plein écran : vous pouvez afficher le contenu de l’onglet Définir dans un mode plein écran à l’aide de cette option.
• Filtrage : à l’aide de la barre de filtre, vous pouvez filtrer la liste des cas de test à l’aide des champs « titre du cas de test », « affecté à » et « state ». Vous pouvez également trier la liste en cliquant sur les en-têtes de colonne.
• Options de colonne : vous pouvez gérer la liste des colonnes visibles sous l’onglet Définir à l’aide des options de colonne. La liste des colonnes disponibles pour sélection sont principalement les champs du formulaire d'élément de travail de cas de test.

Options du menu contextuel

Le menu contextuel du nœud De cas de test dans l’onglet Définir fournit les options suivantes :

• Ouvrir/modifier le formulaire d’élément de travail de cas de test : cette option vous permet de modifier un cas de test à l’aide du formulaire élément de travail dans lequel vous modifiez les champs de l’élément de travail, y compris les étapes de test.
• Modifier les cas de test : cette option vous permet de modifier en bloc les champs d’élément de travail de cas de test. Toutefois, vous ne pouvez pas utiliser cette option pour modifier en bloc les étapes de test.
• Modifier les cas de test dans la grille : cette option vous permet de modifier en bloc les cas de test sélectionnés, y compris les étapes de test à l’aide de l’affichage grille.
• Attribuer des configurations : cette option vous permet de remplacer les configurations au niveau de la suite avec les configurations au niveau du cas de test.
• Supprimer les cas de test : cette option vous permet de supprimer les cas de test de la suite donnée. Elle ne modifie pas l’élément de travail sous-jacent du cas de test.
• Créer une copie/clone de cas de test : cette option vous permet de créer une copie/clone de cas de test sélectionnés. Voir ci-dessous pour plus de détails.
• Afficher les éléments liés : cette option vous permet d’examiner les éléments liés pour un cas de test donné. Voir ci-dessous pour plus de détails.

Copier/cloner des cas de test (nouvelle fonctionnalité)

Pour les scénarios où vous souhaitez copier/cloner un cas de test, vous pouvez utiliser l’option « Copier le cas de test ». Vous pouvez spécifier le projet de destination, le plan de test de destination et la suite de tests de destination dans lequel créer le cas de test copié/cloné. En outre, vous pouvez également spécifier si vous souhaitez inclure des liens/pièces jointes existants à transmettre dans la copie cloné.

Afficher les éléments liés (nouvelle fonctionnalité)

La traçabilité entre les artefacts de test, les exigences et les bogues est une proposition de valeur critique du produit Plans de test. À l’aide de l’option « Afficher les éléments liés », vous pouvez facilement examiner toutes les exigences liées auxquelles ce cas de test est lié, toutes les suites de tests/plans de test où ce cas de test a été utilisé et tous les bogues qui ont été déposés dans le cadre de l’exécution du test.

4. Onglet Exécuter

L’onglet Définir vous permet de rassembler, d’ajouter et de gérer des cas de test pour une suite de tests. Alors que l’onglet d’exécution consiste à affecter des points de test et à les exécuter.

Qu’est-ce qu’un point de test ? Les cas de test eux-mêmes ne sont pas exécutables. Lorsque vous ajoutez un cas de test à une suite de tests, le ou les points de test sont générés. Un point de test est une combinaison unique de cas de test, de suite de tests, de configuration et de testeur. Exemple : si vous avez un cas de test comme « Fonctionnalité de connexion de test » et que vous ajoutez 2 configurations à celui-ci en tant que Edge et Chrome, cela entraîne 2 points de test. À présent, ces points de test peuvent être exécutés. Lors de l’exécution, les résultats des tests sont générés. Grâce à la vue des résultats des tests (historique d’exécution), vous pouvez voir toutes les exécutions d’un point de test. La dernière exécution du point de test est ce que vous voyez dans l’onglet d’exécution.
Par conséquent, les cas de test sont des entités réutilisables. En les incluant dans un plan de test ou une suite, les points de test sont générés. En exécutant des points de test, vous déterminez la qualité du produit ou du service en cours de développement.

L’un des principaux avantages de la nouvelle page est pour les utilisateurs qui effectuent principalement des tests d’exécution/suivi (doivent avoir uniquement le niveau d’accès « De base »), ils ne sont pas submergés par la complexité de la gestion de la suite (l’onglet définir est masqué pour ces utilisateurs).

L’onglet Définir et certaines opérations sont uniquement disponibles pour les utilisateurs disposant d’un niveau d’accès Basic + Test Plans ou équivalent. Tout le reste, y compris l’onglet « Exécuter » doit être exercé par un utilisateur avec le niveau d’accès « De base ».

Tâches

L’onglet Exécuter vous permet d’effectuer les tâches suivantes :

• Marquer les points de test en bloc : cette option vous permet de marquer rapidement le résultat des points de test - réussis, échoués, bloqués ou non applicables, sans avoir à exécuter le cas de test via l'outil d'exécution des tests. Le résultat peut être marqué pour un ou plusieurs points de test en une seule fois.
• Exécuter des points de test : cette option vous permet d’exécuter les cas de test en parcourant individuellement chaque étape de test et en les marquant à l’aide d’un exécuteur de test. Selon l’application que vous testez, vous pouvez utiliser « Web Runner » pour tester une « application web » ou l'« exécuteur de bureau » pour tester les applications de bureau et/ou web. Vous pouvez également appeler « Exécuter avec des options » pour spécifier une build sur laquelle les tests que vous souhaitez effectuer.
• Options de colonne : vous pouvez gérer la liste des colonnes visibles sous l’onglet Exécuter à l’aide des options de colonne. La liste des colonnes disponibles pour la sélection est associée à des points de test, tels que Run by, Assigned Tester, Configuration, etc.
• Mode Plein écran : vous pouvez afficher le contenu de l’onglet Exécuter dans un mode plein écran à l’aide de cette option.
• Filtrage : à l’aide de la barre de filtre, vous pouvez filtrer la liste des points de test à l’aide des champs « titre du cas de test », « affecté à », « state », « résultat du test », « Testeur » et « Configuration ». Vous pouvez également trier la liste en cliquant sur les en-têtes de colonne.

Options du menu contextuel

Le menu contextuel du nœud de point de test dans l’onglet Exécuter fournit les options suivantes :

• Marquer le résultat du test : identique à ce qui précède, vous permet de marquer rapidement le résultat des points de test : réussi, échoué, bloqué ou non applicable.
• Exécuter des points de test : identique à ce qui précède, vous permet d’exécuter les cas de test via l’exécuteur de test.
• Réinitialiser le test sur actif : cette option vous permet de réinitialiser le résultat du test sur actif, ignorant ainsi le dernier résultat du point de test.
• Ouvrir/modifier le formulaire d’élément de travail de cas de test : cette option vous permet de modifier un cas de test à l’aide du formulaire élément de travail dans lequel vous modifiez les champs de l’élément de travail, y compris les étapes de test.
• Affecter un testeur : cette option vous permet d’affecter les points de test aux testeurs pour l’exécution des tests.
• Afficher le résultat du test : cette option vous permet d’afficher les derniers détails du résultat du test, y compris le résultat de chaque étape de test, les commentaires ajoutés ou les bogues déposés.
• Afficher l’historique d’exécution : cette option vous permet d’afficher l’intégralité de l’historique d’exécution du point de test sélectionné. Il ouvre une nouvelle page dans laquelle vous pouvez ajuster les filtres pour afficher l’historique d’exécution non seulement le point de test sélectionné, mais également pour l’ensemble du cas de test.

Rapport de progression des plans de test

Ce rapport prête à l’emploi vous permet de suivre l’exécution et l’état d’un ou plusieurs plans de test dans un projet. Consultez le rapport de progression > des plans de test* pour commencer à l'utiliser.

Les trois sections du rapport incluent les suivantes :

1. Résumé : affiche une vue consolidée pour les plans de test sélectionnés.
2. Tendance des résultats : affiche un instantané quotidien pour vous donner une courbe de tendance d’exécution et d’état. Il peut afficher les données pendant 14 jours (par défaut), 30 jours ou une plage personnalisée.
3. Détails : cette section vous permet d’explorer chaque plan de test et de vous donner des analyses importantes pour chaque suite de tests.

Artifacts

Note

Azure DevOps Server 2020 n’importe pas de flux qui se trouvent dans la corbeille pendant l’importation de données. Si vous souhaitez importer des flux qui se trouvent dans la corbeille, veuillez d'abord les restaurer depuis la corbeille avant de commencer l'importation des données.

Expressions de licence et licences incorporées

Vous pouvez maintenant voir les détails des informations de licence pour les packages NuGet stockés dans Azure Artifacts lors de la navigation dans Visual Studio. Cela s’applique aux licences représentées à l’aide d’expressions de licence ou de licences incorporées. Vous pouvez maintenant voir un lien vers les informations de licence dans la page de détails du package Visual Studio (flèche rouge dans l’image ci-dessous).

En cliquant sur le lien, vous accédez à une page web dans laquelle vous pouvez afficher les détails de la licence. Cette expérience est identique pour les expressions de licence et les licences incorporées. Vous pouvez donc voir les détails de licence pour les packages stockés dans Azure Artifacts à un emplacement unique (pour les packages qui spécifient les informations de licence et sont pris en charge par Visual Studio).

Tâches d’authentification légères

Vous pouvez désormais vous authentifier auprès des gestionnaires de packages populaires à partir d’Azure Pipelines à l’aide de tâches d’authentification légères. Cela inclut NuGet, npm, PIP, Twine et Maven. Auparavant, vous pouvez vous authentifier auprès de ces gestionnaires de packages à l’aide de tâches qui ont fourni une grande quantité de fonctionnalités, notamment la possibilité de publier et de télécharger des packages. Toutefois, cela nécessite l’utilisation de ces tâches pour toutes les activités qui interagissent avec les gestionnaires de package. Si vous aviez vos propres scripts à exécuter pour effectuer des tâches telles que la publication ou le téléchargement de packages, vous ne pourrez pas les utiliser dans votre pipeline. À présent, vous pouvez utiliser des scripts de votre propre conception dans votre pipeline YAML et effectuer l’authentification avec ces nouvelles tâches légères. Exemple utilisant npm :

L’utilisation de la commande « ci » et « publish » dans cette illustration est arbitraire, vous pouvez utiliser toutes les commandes prises en charge par Azure Pipelines YAML. Cela vous permet d’avoir un contrôle complet de l’appel de commandes et facilite l’utilisation de scripts partagés dans votre configuration de pipeline. Pour plus d’informations, consultez la documentation de la tâche d’authentification NuGet, npm, PIP, Twine et Maven .

Améliorations apportées au temps de chargement d’une page de flux

Nous sommes heureux d’annoncer que nous avons amélioré le temps de chargement de la page de flux. En moyenne, les temps de chargement des pages de flux ont diminué de 10 %. Les flux les plus importants ont connu la plus grande amélioration du temps de chargement des pages de flux de 99e centile (temps de chargement dans les 99 % les plus élevés de tous les flux) ont diminué de 75 %.

Partager vos packages publiquement avec des flux publics

Vous pouvez maintenant créer et stocker vos packages dans des flux publics. Les packages stockés dans des flux publics sont disponibles pour tous sur Internet sans authentification, qu’ils se trouvent ou non dans votre collection, ou même connectés à une collection Azure DevOps. Apprenez-en davantage sur les flux publics dans notre documentation sur les flux ou accédez directement à notre tutoriel pour partager des packages publiquement.

Configurer des upstreams dans différentes collections au sein d’un locataire AAD

Vous pouvez maintenant ajouter un flux dans une autre collection associée à votre locataire Azure Active Directory (AAD) en tant que source en amont de votre flux Artifacts. Votre flux peut rechercher et utiliser des packages à partir des flux configurés en tant que sources en amont, ce qui permet aux packages d’être partagés facilement entre les collections associées à votre locataire AAD. Découvrez comment configurer ce paramètre dans la documentation.

Utiliser le fournisseur d’informations d’identification Python pour authentifier pip et twine avec les flux Azure Artifacts

Vous pouvez maintenant installer et utiliser le fournisseur d’informations d’identification Python (artefacts-keyring) pour configurer automatiquement l’authentification pour publier ou consommer des packages Python vers ou à partir d’un flux Azure Artifacts. Avec le fournisseur d'identifiants, vous n'avez pas à configurer de fichiers de configuration (pip.ini/pip.conf/.pypirc), vous serez simplement dirigé via un flux d'authentification dans votre navigateur web lors de votre première utilisation de pip ou twine. Consultez plus d’informations dans la documentation.

Flux Azure Artifacts dans le Gestionnaire de package Visual Studio

Nous affichons maintenant des icônes de package, des descriptions et des auteurs dans le Gestionnaire de package NuGet Visual Studio pour les packages servis à partir des flux Azure Artifacts. Auparavant, la plupart de ces métadonnées n’étaient pas fournies à VS.

Expérience de connexion à un flux mise à jour

La boîte de dialogue Se connecter au flux est l’entrée à l’aide d’Azure Artifacts ; il contient des informations sur la configuration des clients et des référentiels pour envoyer et extraire des packages à partir de flux dans Azure DevOps. Nous avons mis à jour la boîte de dialogue pour ajouter des informations détaillées sur la configuration et élargi la gamme d'outils pour lesquels nous fournissons des instructions.

Flux publics désormais généralement disponibles avec prise en charge en amont

L'aperçu public des flux publics a été largement adopté et a reçu de nombreux retours. Dans cette version, nous avons étendu des fonctionnalités supplémentaires à la disponibilité générale. À présent, vous pouvez définir un flux public en tant que source en amont à partir d’un flux privé. Vous pouvez simplifier vos fichiers de configuration en échangeant des données à la fois vers et depuis des flux de données privés et des flux spécifiquement liés au projet.

Création de flux ayant pour étendue un projet à partir du portail

Lorsque nous avons publié des flux publics, nous avons également publié des flux délimités par projet. Jusqu’à présent, les flux délimités par le projet peuvent être créés via des API REST ou en créant un flux public, puis en tournant le projet privé. À présent, vous pouvez créer des flux dans l’étendue du projet directement dans le portail à partir d’un projet si vous disposez des autorisations requises. Vous pouvez également voir quels flux sont associés à un projet et lesquels sont délimités au périmètre de la collection dans le sélecteur de flux.

Amélioration des performances npm

Nous avons apporté des modifications à notre conception principale pour améliorer la façon dont nous stockons et fournissons des packages npm dans les flux Azure Artifacts. Cela nous a aidés à atteindre jusqu’à 10 réductions de la latence pour certaines des API les plus utilisées pour npm.

Améliorations de l’accessibilité

Nous avons déployé des correctifs pour résoudre les problèmes d’accessibilité sur notre page de flux. Les correctifs sont les suivants :

• Créer une expérience de flux
• Expérience de configuration des paramètres de flux mondiaux
• Accéder à l'expérience du flux de données

Wiki

Édition enrichie pour les pages wiki de code

Auparavant, lors de la modification d’une page wiki de code, vous êtes redirigé vers le hub Azure Repos pour modification. Actuellement, le hub de dépôt n’est pas optimisé pour la modification markdown.

Vous pouvez maintenant modifier une page wiki de codes dans l’éditeur côte à côte à l’intérieur du wiki. Cela vous permet d’utiliser la barre d’outils markdown enrichie pour créer votre contenu à l’aide de l’expérience d’édition identique à celle du wiki du projet. Vous pouvez toujours choisir de modifier les dépôts en sélectionnant l’option Modifier dans les dépôts dans le menu contextuel.

Créer et incorporer des éléments de travail à partir d’une page de wiki

Comme nous avons écouté vos commentaires, nous avons entendu que vous utilisez wiki pour capturer des documents de brainstorming, des documents de planification, des idées sur les fonctionnalités, des documents de spécification, des minutes de réunion. Vous pouvez désormais facilement créer des fonctionnalités et des récits utilisateur directement à partir d’un document de planification sans quitter la page wiki.

Pour créer un élément de travail, sélectionnez le texte dans la page wiki où vous souhaitez incorporer l’élément de travail et sélectionner Nouvel élément de travail. Cela vous permet de gagner du temps, car vous n’avez pas besoin de créer l’élément de travail en premier, accédez à modifier, puis recherchez l’élément de travail à incorporer. Cela réduit également le changement de contexte lorsque vous ne sortez pas de l’étendue du wiki.

Pour en savoir plus sur la création et l’incorporation d’un élément de travail à partir du wiki, consultez notre documentation ici.

Commentaires dans les pages wiki

Auparavant, vous n’aviez pas de moyen d’interagir avec d’autres utilisateurs wiki à l’intérieur du wiki. Rendre la collaboration sur le contenu et obtenir des réponses aux questions était un défi, car les conversations devaient avoir lieu par mails ou messageries instantanées. Avec des commentaires, vous pouvez maintenant collaborer avec d’autres personnes directement dans le wiki. Vous pouvez tirer parti des @mention fonctionnalités des utilisateurs dans les commentaires pour attirer l’attention des autres membres de l’équipe. Cette fonctionnalité a été hiérarchisée en fonction de ce ticket de suggestion. Pour plus d’informations sur les commentaires, consultez notre documentation ici.

Masquer les dossiers et les fichiers à partir de « ». dans l’arborescence wiki

Jusqu’à présent, l’arborescence wiki affichait tous les dossiers et fichiers commençant par un point (.) dans l’arborescence wiki. Dans les scénarios wiki de code, cela a entraîné l'affichage de dossiers comme .vscode, qui sont censés être masqués, dans l'arborescence wiki. À présent, tous les fichiers et dossiers commençant par un point restent masqués dans l’arborescence wiki, ce qui réduit l’encombrement inutile.

Cette fonctionnalité a été hiérarchisée en fonction de ce ticket de suggestion.

URL de pages Wiki courtes et lisibles

Vous n’avez plus besoin d’utiliser une URL multiligne pour partager des liens de page wiki. Nous tirons parti des ID de page dans l’URL pour supprimer les paramètres, ce qui rend l’URL plus courte et plus facile à lire.

La nouvelle structure d’URL se présente comme suit :

https://dev.azure.com/{accountName}/{projectName}/_wiki/wikis/{wikiName}/{pageId}/{readableWiki PageName}

Voici un exemple de la nouvelle URL d’une page De bienvenue dans Le Wiki Azure DevOps :

https://dev.azure.com/microsoft/ AzureDevOps/_wiki/wikis/AzureDevOps.wiki/1/Welcome-to-Azure-DevOps-Wiki

Cela a été hiérarchisé en fonction de ce ticket de suggestion de fonctionnalité de la Communauté des développeurs.

Défilement synchrone pour l’édition des pages wiki

La modification des pages wiki est désormais plus facile avec le défilement synchrone entre la modification et le volet d’aperçu. Le défilement d’un côté fait défiler automatiquement l’autre côté pour mapper les sections correspondantes. Vous pouvez désactiver le défilement synchrone avec le bouton bascule.

Note

L’état du bouton bascule de défilement synchrone est enregistré par utilisateur et par compte.

Visites de page pour les pages wiki

Vous pouvez maintenant obtenir des informations sur les visites de pages pour les pages wiki. L’API REST vous permet d’accéder aux informations de visite de page au cours des 30 derniers jours. Vous pouvez utiliser ces données pour créer des rapports pour vos pages wiki. En outre, vous pouvez stocker ces données dans votre source de données et créer des tableaux de bord pour obtenir des insights spécifiques comme les pages les plus consultées.

Vous verrez également un nombre de visites de pages agrégées pour les 30 derniers jours dans chaque page.

Note

Une visite de page est définie en tant qu’affichage de page par un utilisateur donné dans un intervalle de 15 minutes.

Rapports

Rapports d’échec et de durée du pipeline

Les métriques et les insights vous aident à améliorer en permanence le débit et la stabilité de vos pipelines. Nous avons ajouté deux nouveaux rapports pour vous fournir des informations sur vos pipelines.

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

2. Le rapport de durée du pipeline indique la tendance du temps nécessaire à l’exécution d’un pipeline. Il montre également quelles tâches du pipeline prennent le plus de temps.

Amélioration du widget de résultats de la requête

Le widget de résultats de la requête est l’un de nos widgets les plus populaires et pour de bonnes raisons. Le widget affiche les résultats d’une requête directement sur votre tableau de bord et est utile dans de nombreuses situations.

Avec cette mise à jour, nous avons inclus de nombreuses améliorations attendues de longue date :

• Vous pouvez maintenant sélectionner autant de colonnes que vous souhaitez afficher dans le widget. Pas plus de limite de 5 colonnes !
• Le widget prend en charge toutes les tailles, de 1x1 à 10 x 10.
• Lorsque vous redimensionnez une colonne, la largeur de colonne est enregistrée.
• Vous pouvez développer le widget en mode plein écran. Lorsqu’elle est développée, elle affiche toutes les colonnes retournées par la requête.

Filtrage avancé des widgets Durée de cycle et Délai

Le temps de prospect et de cycle est utilisé par les équipes pour voir combien de temps il faut pour que le travail passe par leurs pipelines de développement et, en fin de compte, fournissent de la valeur à leurs clients.

Jusqu’à présent, les widgets de temps de prospect et de cycle ne prenaient pas en charge les critères de filtre avancés pour poser des questions telles que : « Combien de temps mon équipe prend-elle pour fermer les éléments de priorité supérieure ? »

Avec cette mise à jour, vous pouvez répondre à des questions telles que celles-ci en filtrant sur le couloir de bord.

Nous avons également inclus des filtres d’éléments de travail pour limiter les éléments de travail qui apparaissent dans le graphique.

Burndown de sprint inline à l’aide de story points

Votre Sprint Burndown peut maintenant être réduit par Histoires utilisateur. Cela répond à vos commentaires de la Communauté des développeurs.

Dans le hub Sprint, sélectionnez l’onglet Analytique. Configurez ensuite votre rapport comme suit :

1. Sélectionner le backlog de récits
2. Sélectionner le burndown sur Sum of Story Points

Un widget Sprint Burndown avec tout ce que vous avez demandé

Le nouveau widget Sprint Burndown permet la réduction par points d’histoire, par nombre de tâches ou en additionnant les valeurs des champs personnalisés. Vous pouvez même créer un burndown sprint pour fonctionnalités ou épopées. Le widget affiche le burndown moyen, le pourcentage de réalisation et l'augmentation de la portée. Vous pouvez configurer les paramètres de l’équipe, vous permettant d’afficher le graphique de burndown de sprint pour plusieurs équipes sur le même tableau de bord. Avec toutes ces informations importantes à afficher, nous vous permettons de redimensionner jusqu’à 10 x 10 sur le tableau de bord.

Pour l’essayer, vous pouvez l’ajouter à partir du catalogue de widgets ou en modifiant la configuration du widget Sprint Burndown existant et en cochant la case Essayer la nouvelle version maintenant .

Note

Le nouveau widget utilise Analytics. Nous avons conservé l’ancien Sprint Burndown au cas où vous n’avez pas accès à Analytics.

Miniature de burndown du sprint incluse

Le Sprint Burndown est de retour ! Il y a quelques sprints de cela, nous avons supprimé le burndown de sprint contextuel des en-têtes Sprint Burndown et Taskboard. En fonction de vos commentaires, nous avons amélioré et réintroduis la miniature de burndown sprint.

Cliquer sur la miniature affiche immédiatement une version plus grande du graphique avec une option permettant d’afficher le rapport complet sous l’onglet Analytique. Toutes les modifications apportées au rapport complet sont reflétées dans le graphique affiché dans l’en-tête. Vous pouvez donc désormais la configurer pour qu'elle se décompose en fonction des récits utilisateur, des points d'histoire ou du nombre de tâches, plutôt qu'en fonction de la quantité de travail restante.

Créer un tableau de bord sans équipe

Vous pouvez maintenant créer un tableau de bord sans l’associer à une équipe. Lorsque vous créez un tableau de bord, sélectionnez le type de tableau de bord du projet .

Un tableau de bord de projet est semblable à un tableau de bord d’équipe, sauf qu’il n’est pas associé à une équipe et que vous pouvez décider qui peut modifier/gérer le tableau de bord. Tout comme un tableau de bord d’équipe, il est visible pour tout le monde dans le projet.

Tous les widgets Azure DevOps qui nécessitent un contexte d’équipe ont été mis à jour pour vous permettre de sélectionner une équipe dans sa configuration. Vous pouvez ajouter ces widgets aux tableaux de bord de projet et sélectionner l’équipe spécifique souhaitée.

Note

Pour les widgets personnalisés ou tiers, un tableau de bord de projet transmet le contexte de l’équipe par défaut à ces widgets. Si vous disposez d’un widget personnalisé qui s’appuie sur le contexte d’équipe, vous devez mettre à jour la configuration pour vous permettre de sélectionner une équipe.

---

Retours d'expérience

Nous aimerions connaître votre opinion ! Vous pouvez signaler un problème ou fournir une idée et le suivre via la Communauté des développeurs et obtenir des conseils sur Stack Overflow.

---

Haut de page