Notes de publication d’Azure DevOpsServer 2020 Update 1

| Developer Community Exigences du système Termes | du contrat de licence | DevOps Blog | SHA-1 Hachages

Dans cet article, vous trouverez des informations sur la dernière version pour Azure DevOps Server.

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

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


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

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

Azure DevOps Server 2020 gère différemment la rétention des build, 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 de Azure DevOps Server 2019 à Azure DevOps Server 2020.

Azure DevOps Server 2020 Update 1.2 Patch 13 Date de publication : 12 mars 2024

Fichier Hachage SHA-256
devops2020.1.2patch13.exe 55B0A30EABD66EB22AA6093B7750EF3CFEFE79423018E304503CE728158F56F6

Nous avons publié le correctif 13 pour Azure DevOps Server mise à jour 2020 1.2 qui inclut des correctifs pour les éléments suivants :

  • Résolution d’un problème dans lequel le serveur proxy a cessé de fonctionner après l’installation du correctif 12.

Azure DevOps Server 2020 Update 1.2 Patch 12 Date de publication : 13 février 2024

Fichier Hachage SHA-256
devops2020.1.2patch12.exe C4C9EEBBDD3B07C36658C9F78AEA57A980AA633F99DF2A3AD5036F957F095E53

Nous avons publié le correctif 12 pour Azure DevOps Server mise à jour 2020 1.2 qui inclut des correctifs pour les éléments suivants :

  • Correction d’un bogue dans lequel l’espace disque utilisé par le dossier de cache proxy n’était pas calculé correctement et le dossier n’était pas correctement nettoyé.
  • CVE-2024-20667 : Azure DevOps Server vulnérabilité d’exécution de code à distance.

Azure DevOps Server 2020 Update 1.2 Patch 11 Date de publication : 12 décembre 2023

Fichier Hachage SHA-256
devops2020.1.2patch11.exe C47B9C898C2E08527F1DDC3E7A5E67F1A11C3AFF860DE9B5FF3DD8718C3AAE87

Nous avons publié le correctif 11 pour Azure DevOps Server mise à jour 2020 1.2 qui inclut des correctifs pour les éléments suivants :

  • Correction d’un bogue dans lequel l’héritage de sécurité avant l’approbation du déploiement ne fonctionnait pas dans les phases de pipelines.

Azure DevOps Server 2020 Update 1.2 Patch 10 Date de publication : 14 novembre 2023

Nous avons publié un correctif pour Azure DevOps Server 2020 Update 1.2 qui inclut les correctifs suivants.

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

Notes

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

Installer les correctifs

Important

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

Configurer TFX

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

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

Fichier Hachage SHA-256
Tasks20231103.zip 389BA66EEBC32622FB83402E21373CE20AE040F70461B9F9AF9EFCED5034D2E5
  1. Téléchargez et extrayezTasks20231103.zip.
  2. Remplacez le répertoire par les fichiers extraits.
  3. Exécutez les commandes suivantes pour charger les tâches :
tfx build tasks upload --task-zip-path AzureFileCopyV1.1.230.0.zip
tfx build tasks upload --task-zip-path AzureFileCopyV2.2.230.0.zip 
tfx build tasks upload --task-zip-path AzureFileCopyV3.3.230.0.zip 
tfx build tasks upload --task-zip-path AzureFileCopyV4.4.230.0.zip 
tfx build tasks upload --task-zip-path AzureFileCopyV5.5.230.0.zip 
tfx build tasks upload --task-zip-path BashV3.3.226.2.zip 
tfx build tasks upload --task-zip-path BatchScriptV1.1.226.0.zip 
tfx build tasks upload --task-zip-path PowerShellV2.2.230.0.zip 
tfx build tasks upload --task-zip-path SSHV0.0.226.1.zip 
tfx build tasks upload --task-zip-path WindowsMachineFileCopyV1.1.230.0.zip 
tfx build tasks upload --task-zip-path WindowsMachineFileCopyV2.2.230.0.zip 

Configuration requise du pipeline

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

  • Sur classique :

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

  • Exemple YAML :

variables: 
- name: AZP_75787_ENABLE_NEW_LOGIC 
  value: true 

Azure DevOps Server 2020 Update 1.2 Patch 9 Date de publication : 10 octobre 2023

Important

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

Nous avons publié un correctif. pour Azure DevOps Server 2020 Update 1.2 qui inclut les correctifs suivants.

  • Correction d’un bogue où l’identité « Propriétaire de l’analyse » s’affiche en tant qu’identité inactive sur les machines de mise à niveau corrective.

Azure DevOps Server 2020 Update 1.2 Patch 8 Date de publication : 12 septembre 2023

Nous avons publié un correctif pour Azure DevOps Server 2020 Update 1.2 qui inclut les correctifs suivants.

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

Important

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

Notes

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

Installer les correctifs

  1. Téléchargez et installez Azure DevOps Server 2020 Update 1.2 patch 8.

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.  

Notes

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

Configurer TFX

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

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

  1. Téléchargez et extrayezTasks_20230825.zip.
  2. Remplacez le répertoire par les fichiers extraits.
  3. Exécutez les commandes suivantes pour charger les tâches :
tfx build tasks upload --task-zip-path AzureFileCopyV1.1.226.3.zip
tfx build tasks upload --task-zip-path AzureFileCopyV2.2.226.2.zip 
tfx build tasks upload --task-zip-path AzureFileCopyV3.3.226.2.zip 
tfx build tasks upload --task-zip-path AzureFileCopyV4.4.226.2.zip 
tfx build tasks upload --task-zip-path AzureFileCopyV5.5.226.2.zip 
tfx build tasks upload --task-zip-path BashV3.3.226.2.zip 
tfx build tasks upload --task-zip-path BatchScriptV1.1.226.0.zip 
tfx build tasks upload --task-zip-path PowerShellV2.2.226.1.zip 
tfx build tasks upload --task-zip-path SSHV0.0.226.1.zip 
tfx build tasks upload --task-zip-path WindowsMachineFileCopyV1.1.226.2.zip 
tfx build tasks upload --task-zip-path WindowsMachineFileCopyV2.2.226.2.zip 

Configuration requise du pipeline

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

  • Sur classique :

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

  • Exemple YAML :

variables: 
- name: AZP_75787_ENABLE_NEW_LOGIC 
  value: true 

Azure DevOps Server 2020 Update 1.2 Patch 7 Date de publication : 8 août 2023

Nous avons publié un correctif pour Azure DevOps Server 2020 Update 1.2 qui inclut les correctifs suivants.

  • CVE-2023-36869 : Azure DevOps Server vulnérabilité d’usurpation d’identité.
  • Mettez à jour le service SSH pour prendre en charge SHA2-256 et SHA2-512. Si vous avez des fichiers de configuration SSH codés en dur pour utiliser RSA, vous devez mettre à jour vers SHA2 ou supprimer l’entrée.
  • Résolution du problème lié aux liens relatifs qui ne fonctionnent pas dans les fichiers markdown.
  • Correction d’un bogue avec la navigation dans les commentaires sur une page de validation.
  • Correction d’un bogue où l’identité du propriétaire de l’analyse s’affichait comme identité inactive.
  • Correction d’un bogue de boucle infinie sur CronScheduleJobExtension.

Azure DevOps Server 2020 Update 1.2 Patch 6 Date de publication : 13 juin 2023

Nous avons publié un correctif pour Azure DevOps Server 2020 Update 1.2 qui inclut les correctifs suivants.

  • CVE-2023-21565 : Azure DevOps Server vulnérabilité d’usurpation d’identité.
  • CVE-2023-21569 : Azure DevOps Server vulnérabilité d’usurpation d’identité.
  • Correction d’un bogue qui interfère avec l’envoi de packages lors de la mise à niveau à partir de 2018 ou d’une version antérieure.
  • Correction d’un bogue dans lequel le détachement ou l’attachement de la collecte ne parvient pas à signaler l’erreur suivante : « TF246018 : L’opération de base de données a dépassé la limite de délai d’attente et a été annulée.

Azure DevOps Server 2020 Update 1.2 Patch 5 Date de publication : 14 février 2023

Nous avons publié un correctif pour Azure DevOps Server 2020 Update 1.2 qui inclut les correctifs suivants.

  • CVE-2023-21553 : vulnérabilité d’exécution de code à distance Azure DevOps Server
  • Résolution du problème d’accessibilité des étagères via l’interface utilisateur web
  • Les clients doivent redémarrer le service tfsjobagent et Azure DevOps Server pool d’applications après la mise à jour du paramètre SMTP dans la console de gestion Azure DevOps Server.

Azure DevOps Server 2020 Update 1.2 Patch 4 Date de publication : 13 décembre 2022

Nous avons publié un correctif pour Azure DevOps Server 2020 Update 1.2 qui inclut les correctifs suivants.

  • Correction de l’affichage de caractères spéciaux dans IdentityPicker.

Gif pour faire la démonstration de caractères spéciaux dans IndetityPicker.

  • Les données de test n’ont pas été supprimées, ce qui a entraîné la croissance de la base de données. Avec ce correctif, nous avons mis à jour la rétention de build pour empêcher la création de nouvelles données de test orphelines.

Azure DevOps Server 2020 Update 1.2 Patch 3 Date de publication : 18 octobre 2022

Nous avons publié un correctif pour Azure DevOps Server 2020 Update 1.2 qui inclut les correctifs 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é.
  • Correction d’un problème avec le filtre Demandé par membre du groupe dans les paramètres du web hook.
  • Corrigez l’erreur de génération de case activée-in gated lorsque les paramètres d’organisation du pipeline avaient une étendue d’autorisation de travail configurée comme Limiter l’étendue de l’autorisation de travail au projet actuel pour les pipelines sans mise en production.
  • Correction de la récupération du jeton d’accès à partir d’Azure lors de l’établissement d’une connexion de service derrière un proxy authentifié.

Azure DevOps Server 2020 Update 1.2 Patch 2 Date de publication : 9 août 2022

Nous avons publié un correctif pour Azure DevOps Server 2020 Update 1.2 qui inclut les correctifs suivants.

  • Corrigez l’erreur de valeur d’identité lors de l’attribution d’un élément de travail à une identité qui apparaît dans différents domaines.

Azure DevOps Server 2020 Update 1.2 Patch 1 Date de publication : 12 juillet 2022

Nous avons publié un correctif pour Azure DevOps Server 2020 Update 1.2 qui inclut les correctifs suivants.

  • Dans les API d’exécution de test, le jeton de continuation retourné était supérieur à la valeur « maxLastUpdatedDate » spécifiée.

Azure DevOps Server 2020 Update 1.2 Date de publication : 17 mai 2022

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

Notes

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

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

  • Azure DevOps Server 2020.1.2 désactive le nouveau modèle de rétention (introduit dans Azure DevOps Server 2020), afin d’éviter la perte d’exécutions de pipeline (builds). Cela signifie que le système :

    • Créer des baux pour les 3 builds les plus récentes générées lors de l’exécution de Server 2020
    • Pour les pipelines YAML et les pipelines classiques sans stratégies de rétention par pipeline, les builds sont conservées en fonction des paramètres de rétention maximale au niveau de la collection
    • Pour les pipelines classiques avec des stratégies de rétention personnalisées par pipeline, les builds sont conservées en fonction de la stratégie de rétention spécifique au pipeline.
    • Les builds avec baux ne comptent pas dans le paramètre Minimum à conserver
  • Les liens des commentaires de l’ensemble de modifications et de l’ensemble de rayons n’étaient pas redirigés correctement. Lorsque des commentaires ont été ajoutés à des fichiers dans des ensembles de modifications ou des ensembles de tablettes, la sélection de ces commentaires ne redirige pas vers l’emplacement approprié dans l’affichage de fichiers.

  • Impossible d’ignorer la file d’attente de build à l’aide du bouton « Exécuter ensuite ». Auparavant, le bouton « Exécuter ensuite » é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.

Azure DevOps Server 2020.1.1 Patch 4 Date de publication : 26 janvier 2022

Nous avons publié un correctif pour Azure DevOps Server 2020.1.1 qui inclut les correctifs suivants.

  • Email notifications n’ont pas été envoyées lors de l’utilisation du @mention contrôle dans un élément de travail.
  • L’adresse e-mail préférée n’était pas mise à jour dans le profil utilisateur. Cela a entraîné l’envoi d’e-mails à l’adresse e-mail précédente.
  • L’en-tête n’était pas affiché dans la page Résumé du projet. L’en-tête a été affiché pendant quelques millisecondes, puis il a disparu.
  • 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.

Procédure d’installation :

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

Notes

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 le correctif 4.
  2. Vérifiez la valeur du Registre sur HKLM:\Software\Elasticsearch\Version. Si la valeur de Registre n’existe 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 dans C:\Program Files\{TFS Version Folder}\Search\zip le dossier de fichiers distants Elasticsearch.
  4. Exécutez Configure-TFSSearch.ps1 -Operation update sur l’ordinateur serveur Elasticsearch.

Hachage SHA-256 : 451F0BB73132EFCD2B3D2922F0040DBF2BCF2808C35D3C37CA5A3CD8F65F29D6

Azure DevOps Server 2020.1.1 Patch 3 Date de publication : 15 décembre 2021

Le correctif 3 pour Azure DevOps Server 2020.1.1 inclut les correctifs suivants.

  • Correction de la macro d’élément de travail pour les requêtes avec « Contient des mots ». Auparavant, les requêtes renvoyaient des résultats incorrects pour les valeurs qui contenaient un saut de ligne.
  • Augmentez les limites pour la longueur des caractères de version du package Maven.
  • Problème de localisation pour les états de disposition des éléments de travail personnalisés.
  • Problème de localisation dans le modèle de notification par e-mail.
  • Problème avec l’évaluation des règles NOTSAMEAS lorsque plusieurs règles NOTSAMEAS ont été définies pour un champ.

Azure DevOps Server 2020.1.1 Patch 2 Date de publication : 26 octobre 2021

Le correctif 2 pour Azure DevOps Server 2020.1.1 inclut les correctifs 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 les Azure DevOps Server et les dépôts sur GitHub.com. Vous trouverez ce paramètre dans la page connexions GitHub sous Paramètres du projet.
  • Résoudre le problème lié au widget Plan de test. Le rapport d’exécution du test affichait un utilisateur incorrect sur les résultats.
  • Correction du problème lié à l’échec du chargement de la page de résumé de la vue d’ensemble du projet.
  • Correction du problème lié à l’envoi d’e-mails pour confirmer la mise à niveau du produit.

Azure DevOps Server 2020.1.1 Patch 1 Date de publication : 14 septembre 2021

Le correctif 1 pour Azure DevOps Server 2020.1.1 inclut les correctifs suivants.

  • Correction de l’échec de téléchargement/chargement des artefacts.
  • Résoudre le problème lié aux données de résultats de test incohérentes.

Azure DevOps Server 2020 Update 1.1 Date de publication : 17 août 2021

Azure DevOps Server 2020 Update 1.1 est un cumul de correctifs de bogues. Vous pouvez installer directement Azure DevOps Server 2020 Update 1.1 ou mettre à niveau à partir du Azure DevOps Server 2020 ou de Team Foundation Server 2013 ou ultérieur.

Notes

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

Cette version inclut les corrections des bugs suivants :

Azure Boards

  • Le lien hypertexte « Afficher l’élément de travail » dans les e-mails de notification n’utilise pas l’URL publique.

Azure Repos

  • Correction de l’affichage des cases à cocher d’héritage des types de fusion limités pour activer la modification des types de fusion limités après avoir défini des stratégies de conservation croisée.

Azure Pipelines

  • Lors de la modification du paramètre de mise à jour de l’agent, les paramètres ne se propageaient pas à d’autres niveaux application dans l’environnement.

Général

  • Correction de l’orthographe dans l’Assistant Configuration du serveur.
  • Augmentation de la taille du package d’extension et vous permet de modifier la taille dans le Registre.

Azure Test Plans

  • Impossible de revenir aux résultats des tests une fois que vous revenez de l’historique à la page récapitulative.

Azure DevOps Server 2020.1 Patch 2 Date de publication : 10 août 2021

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

  • Correction de l’erreur d’interface utilisateur de définition de build.
  • Modification de l’historique de navigation pour afficher les fichiers au lieu du dépôt racine.

Azure DevOps Server 2020.1 Patch 1 Date de publication : 15 juin 2021

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

  • Cookies sécurisés utilisés dans les flux d’autorisation qui affirment SameSite=None.

  • Résolvez le problème lié au KIT DE développement logiciel (SDK) Notifications. Auparavant, les abonnements aux notifications utilisant le filtre Chemin d’accès à la zone n’étaient pas analysés correctement.

Azure DevOps Server 2020.1 RTW Date de publication : 25 mai 2021

Résumé des nouveautés de Azure DevOps Server 2020.1 RTW

Azure DevOps Server 2020.1 RTW est un cumul de correctifs de bogues. Il inclut toutes les fonctionnalités du Azure DevOps Server 2020.1 RC2 précédemment publié. Azure DevOps Server 2020.1 RTW est un cumul de correctifs de bogues. Vous pouvez installer directement Azure DevOps Server 2020.1 ou effectuer une mise à niveau à partir de Azure DevOps Server 2020, 2019 ou Team Foundation Server 2015 ou version ultérieure.

Notes

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

date de publication de Azure DevOps Server 2020.1 RC2 : 13 avril 2021

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

Azure DevOps Server 2020.1 RC2 est un cumul de correctifs de bogues. Il inclut toutes les fonctionnalités du Azure DevOps Server 2020.1 RC1 précédemment publié.

date de publication de Azure DevOps Server 2020.1 RC1 : 23 mars 2021

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

Azure DevOps Server 2020.1 RC1 introduit de nombreuses nouvelles fonctionnalités. Voici les principales :

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


Boards

Règles de restriction de transition d’état

Nous continuons à combler l’écart de parité des fonctionnalités entre le xml hébergé et le modèle de processus hérité. Cette nouvelle règle de type d’élément de travail vous permet de limiter le déplacement des éléments de travail d’un état à un autre. Par exemple, vous pouvez empêcher les bogues de passer de Nouveau à Résolu. Au lieu de cela, ils doivent passer de Nouveau -> Actif -> Résolu

img

Vous pouvez également créer une règle pour restreindre les transitions d’état par appartenance au groupe. Par exemple, seuls les utilisateurs du groupe « Approbateurs » peuvent déplacer les récits utilisateur de Nouveau -> Approuvé.

Copier l’élément de travail pour copier des enfants

L’une des principales fonctionnalités demandées pour Azure Boards est la possibilité de copier un élément de travail qui copie également les éléments de travail enfants. Nous avons ajouté une nouvelle option à « Inclure des éléments de travail enfants » à la boîte de dialogue Copier l’élément de travail. Lorsqu’elle est sélectionnée, cette option copie l’élément de travail et copie tous les éléments de travail enfants (jusqu’à 100).

Cette page affiche la nouvelle option dans Azure Boards inclure des éléments de travail enfants dans un élément de travail copié.

Règles améliorées pour les champs activés et résolus

Jusqu’à présent, les règles pour Activated By, Activated Date, Resolved By et Resolved Date étaient un mystère. Ils sont définis uniquement pour les types d’éléments de travail système et sont spécifiques à la valeur d’état « Active » et « Resolved ». Nous avons modifié la logique afin que ces règles ne soient plus destinées à un état spécifique. Au lieu de cela, ils sont déclenchés par la catégorie (catégorie d’état) dans laquelle réside l’état. Par exemple, supposons que vous ayez un état personnalisé « Tests des besoins » dans la catégorie Résolu. Lorsque l’élément de travail passe de « Active » à « Needs Testing », les règles Resolved By et Resolved Date sont déclenchées.

Cela permet aux clients de créer des valeurs d’état personnalisées tout en continuant à générer les champs Activated By, Activated Date, Resolved By et Resolved Date , sans avoir besoin d’utiliser des règles personnalisées.

Les parties prenantes peuvent déplacer des éléments de travail d’une colonne à l’autre

Les parties prenantes ont toujours été en mesure de modifier l’état des éléments de travail. Mais lorsqu’ils accèdent au tableau Kanban, ils ne peuvent pas déplacer les éléments de travail d’une colonne à une autre. Au lieu de cela, les parties prenantes doivent ouvrir chaque élément de travail, un par un, et mettre à jour la valeur d’état. Cela a longtemps été un point problématique pour les clients, et nous sommes heureux d’annoncer que vous pouvez désormais déplacer des éléments de travail d’une colonne à l’autre.

Types d’éléments de travail système sur les backlogs et les tableaux

Vous pouvez maintenant ajouter un type d’élément de travail système au niveau de backlog de votre choix. Historiquement, ces types d’éléments de travail n’étaient disponibles qu’à partir de requêtes.

Processus Type d'élément de travail
Agile Problème
Scrum Obstacle
CMMI Demande de modification
Problème
Révision
Risque

L’ajout d’un type d’élément de travail système à un niveau de backlog est simple. Accédez simplement à votre processus personnalisé et cliquez sur l’onglet Niveaux de backlog. Sélectionnez le niveau de backlog de votre choix (exemple : Backlog des exigences) et choisissez l’option de modification. Ajoutez ensuite le type d’élément de travail.

Arriérés

Azure Boards limite de dépôt d’applications GitHub a été augmentée

La limite de dépôt pour l’application Azure Boards dans la Place de marché GitHub a été augmentée de 100 à 250.

Personnaliser l’état de l’élément de travail lors de la fusion d’une demande de tirage

Tous les workflows ne sont pas identiques. Certains clients souhaitent fermer leurs éléments de travail associés lorsqu’une demande de tirage est terminée. D’autres souhaitent définir les éléments de travail sur un autre état à valider avant la fermeture. Nous devrions autoriser les deux.

Nous avons une nouvelle fonctionnalité qui vous permet de définir les éléments de travail à l’état souhaité lorsque la demande de tirage est fusionnée et terminée. Pour ce faire, nous allons analyser la description de la demande de tirage et rechercher la valeur d’état suivie de la #mention des éléments de travail. Dans cet exemple, nous définissons deux récits utilisateur sur Résolu et fermons deux tâches.

work-item-state

Vous pouvez désormais facilement suivre vos dépendances de build dans un projet simplement en liant votre élément de travail à un build, Trouvé dans la build ou Intégré dans la build.

lier des éléments de travail

Modification de la description (texte d’aide) sur les champs système

Vous avez toujours pu modifier la description des champs personnalisés. Toutefois, pour les champs système tels que la priorité, la gravité et l’activité, la description n’était pas modifiable. Il s’agissait d’un écart de fonctionnalité entre le xml hébergé et hérité qui empêchait certains clients de migrer vers le modèle hérité. Vous pouvez maintenant modifier la description sur les champs système. La valeur modifiée affecte uniquement ce champ dans le processus et pour ce type d’élément de travail. Cela vous donne la possibilité d’avoir différentes descriptions pour le même champ sur différents types d’éléments de travail.

modifier la description

Personnaliser l’état de l’élément de travail lors de la fusion d’une demande de tirage

Les demandes de tirage font souvent référence à plusieurs éléments de travail. Lorsque vous créez ou mettez à jour une demande de tirage, vous pouvez fermer certaines d’entre elles, résoudre certaines d’entre elles et garder le reste ouvert. Vous pouvez maintenant utiliser des commentaires tels que ceux présentés dans la figure ci-dessous pour y parvenir. Pour plus d’informations, consultez la documentation.

Personnaliser l’état

Champ parent sur le tableau des tâches

En raison d’une demande populaire, vous pouvez maintenant ajouter le champ Parent aux cartes enfant et parent sur le tableau des tâches.

tableau des tâches de champ parent

Suppression de la règle « Affecté à » sur le type d’élément de travail bogue

Il existe plusieurs règles système masquées pour tous les différents types d’éléments de travail dans Agile, Scrum et CMMI. Ces règles existent depuis plus de dix ans et ont généralement bien fonctionné sans aucune plainte. Cependant, il y a quelques règles qui ont expiré leur accueil. Une règle en particulier a causé beaucoup de douleurs pour les clients nouveaux et existants et nous avons décidé qu’il était temps de la supprimer. Cette règle existe sur le type d’élément de travail Bogue dans le processus Agile.

« Définissez la valeur Affectée sur Créé par lorsque l’état est remplacé par Résolu »

Nous avons reçu un grand nombre de vos commentaires sur cette règle. En réponse, nous avons supprimé cette règle du type d’élément de travail Bogue dans le processus Agile. Cette modification affectera chaque projet utilisant un processus Agile hérité ou agile personnalisé. Pour les clients qui aiment et dépendent de cette règle actuelle, consultez notre billet de blog sur les étapes à suivre pour rajouter la règle à l’aide de règles personnalisées.

Éléments supprimés sur la page Éléments de travail

La page Éléments de travail est l’endroit idéal pour trouver rapidement des éléments que vous avez créés ou qui vous sont attribués, entre autres choses. Il fournit plusieurs pivots et filtres personnalisés. L’une des principales plaintes pour le tableau croisé dynamique « Affecté à moi » est qu’il affiche les éléments de travail supprimés (c’est-à-dire les éléments de travail dans l’état Supprimé). Et nous sommes d’accord ! Les éléments supprimés sont des travaux qui n’ont plus de valeur et qui ont donc été supprimés du backlog. Il n’est donc pas utile de les inclure dans cette vue.

Vous pouvez maintenant masquer tous les éléments supprimés du tableau croisé dynamique Qui m’est attribué sur la page Éléments de travail.

Repos

Préférence de nom de branche par défaut

Azure Repos offre désormais un nom de branche par défaut personnalisable pour Git. Dans les paramètres du dépôt, vous pouvez choisir n’importe quel nom de branche juridique à utiliser lors de l’initialisation d’un dépôt. Azure Repos a toujours pris en charge la modification du nom branche par défaut d’un dépôt existant. Pour plus d’informations, consultez Gérer les branches .

 default-branch-name

Remarque : si vous n’activez pas cette fonctionnalité, vos dépôts sont initialisés avec le nom par défaut de Azure Repos. Actuellement, cette valeur par défaut est master. Pour honorer l’engagement de Microsoft et les demandes des clients pour une langue inclusive, nous allons rejoindre les pairs du secteur en changeant cette valeur par défaut en main. Ce changement aura lieu plus tard cet été. Si vous souhaitez continuer à utiliser master, vous devez activer cette fonctionnalité maintenant et la définir sur master.

Paramètre au niveau de l’organisation pour branche par défaut

Il existe désormais un paramètre au niveau de la collection pour votre nom de branche initiale préféré pour les nouveaux dépôts. Si un projet n’a pas choisi de nom de branche initial, ce paramètre au niveau de l’organisation est utilisé. Si vous n’avez pas spécifié le nom initial de la branche dans les paramètres de l’organisation ou les paramètres de projet, les nouveaux dépôts utilisent une valeur par défaut définie par Azure DevOps.

Paramètre de branche pour le niveau de l’organisation

Ajouter une nouvelle étendue d’authentification pour contribuer aux commentaires de demande de tirage

Cette version ajoute une nouvelle étendue OAuth pour la lecture/écriture de commentaires de demande de tirage. Si vous disposez d’un bot ou d’une automatisation qui doit uniquement interagir avec les commentaires, vous pouvez lui donner un PAT avec uniquement cette étendue. Ce processus réduit le rayon d’explosion si l’automatisation présente un bogue ou si le jeton a été compromis.

Améliorations de l’expérience des demandes de tirage

La nouvelle expérience de demande de tirage a été améliorée avec les éléments suivants :

  • Rendre les vérifications facultatives plus visibles

Les clients utilisent des vérifications facultatives pour attirer l’attention d’un développeur sur les problèmes potentiels. Dans l’expérience précédente, il était évident que ces vérifications échouent. Toutefois, ce n’est pas le cas dans l’expérience de préversion. Une grande coche verte sur les vérifications requises masque les échecs dans les vérifications facultatives. Les utilisateurs n’ont pu découvrir que les vérifications facultatives ont échoué qu’en ouvrant le panneau de vérifications. Les développeurs ne le font pas souvent lorsqu’il n’y a aucune indication d’un problème. Dans ce déploiement, nous avons rendu la status de vérifications facultatives plus visible dans le résumé.


afficher les vérifications facultatives


  • Ctrl-clic sur les éléments de menu

Les menus tabulation d’une demande de tirage ne prennent pas en charge ctrl-clic. Les utilisateurs ouvrent souvent de nouveaux onglets de navigateur au fur et à mesure qu’ils examinent une demande de tirage. Ce problème a été résolu.

  • Emplacement de l’annotation [+]

L’arborescence des fichiers dans une demande de tirage affiche une annotation [+] pour aider les auteurs et les réviseurs à identifier les nouveaux fichiers. Étant donné que l’annotation se trouvait après les points de suspension, elle n’était souvent pas visible pour les noms de fichiers plus longs.


afficher les emplacements des annotations

  • Liste déroulante Des mises à jour de demande de tirage récupèrent les informations de minutage

La liste déroulante permettant de sélectionner la mise à jour et la comparaison des fichiers dans une demande de tirage a perdu un élément important dans l’expérience d’aperçu. Elle ne s’est pas montrée quand cette mise à jour a été effectuée. Ce problème a été résolu.


Informations de minutage manquantes dans la liste déroulante des mises à jour de demande de tirage

  • **Amélioration de la disposition du filtre de commentaires **

Lors du filtrage des commentaires sur la page récapitulative d’une demande de tirage, la liste déroulante se trouvait à droite, mais le texte était aligné à gauche. Ce problème a été résolu.


Amélioration de la disposition du filtre de commentaires

  • Navigation vers les validations parentes

Dans la page Validations, vous pouvez comparer les modifications apportées à un commit particulier avec son commit parent. Toutefois, vous souhaiterez peut-être accéder au commit parent et comprendre en quoi cette validation diffère de son propre parent. Cela est souvent nécessaire lorsque vous souhaitez comprendre toutes les modifications apportées à une version. Nous avons ajouté un ou plusieurs parents carte à un commit pour vous aider à y parvenir.


Navigation vers les validations parentes

  • Espace supplémentaire pour les dossiers et les fichiers avec des noms longs sous l’onglet Fichiers de demande de tirage

Les dossiers et les fichiers avec des noms longs ont été coupés en raison d’un manque d’espacement horizontal dans l’arborescence de fichiers. Nous avons récupéré un espace supplémentaire dans l’arborescence en modifiant la mise en retrait de l’arborescence pour qu’elle corresponde au nœud racine et en masquant le bouton de sélection de la page, sauf lors du pointage.

Image de la nouvelle arborescence de fichiers :


Espace supplémentaire pour les dossiers et les fichiers

Image de l’arborescence de fichiers lorsque vous pointez sur un répertoire :


Affichage du nom

  • Conserver la position de défilement lors du redimensionnement diff volet dans l’onglet Fichiers de demande de tirage

Lors du redimensionnement du volet de diff côte à côte dans l’onglet Fichiers de demande de tirage, l’emplacement de défilement de l’utilisateur est perdu. Ce problème a été résolu ; l’emplacement de défilement de l’utilisateur est maintenant conservé sur un redimensionnement de volet diff.

  • Rechercher un commit sur un appareil mobile

Lors de l’affichage de la page Commits sur un appareil mobile, la zone de recherche est manquante dans la nouvelle expérience. Par conséquent, il est difficile pour vous de trouver un commit par son hachage et de l’ouvrir. Ce problème a été résolu maintenant.


Rechercher un commit sur un appareil mobile

  • Amélioration de l’utilisation de l’espace pour le nouveau fichier de demande de tirage diff vue mobile

Nous avons mis à jour cette page pour mieux utiliser l’espace afin que les utilisateurs puissent voir davantage le fichier dans les affichages mobiles au lieu d’avoir 40 % de l’écran occupé par un en-tête.


Amélioration de l’utilisation de l’espace nouveau nom de fichier de demande de tirage

  • Images améliorées dans l’affichage résumé de la demande de tirage

Les images modifiées dans une demande de tirage ne s’affichaient pas dans l’affichage résumé de la demande de tirage, mais elles s’affichaient correctement dans la vue Fichiers de demande de tirage. Ce problème a été résolu.

  • Expérience de branche améliorée lors de la création d’une demande de tirage

Avant cette mise à jour, cette expérience n’était pas idéale, car elle comparerait les modifications avec la branche par défaut du dépôt au lieu de la branche de comparaison.


Amélioration de l’expérience de branche

Pipelines

Plateforme d’agent supplémentaire : ARM64

Nous avons ajouté Linux/ARM64 à la liste des plateformes prises en charge pour l’agent Azure Pipelines. Bien que les changements de code aient été minimes, beaucoup de travail en arrière-plan a dû être effectué en premier, et nous sommes heureux d’annoncer sa sortie !

Prise en charge des filtres de balises pour les ressources de pipeline

Nous avons maintenant ajouté des « balises » dans les pipelines YAML. Vous pouvez utiliser des balises pour définir le pipeline CI à exécuter ou quand se déclencher automatiquement.

resources:
  pipelines:
  - pipeline: MyCIAlias
    project: Fabrikam
    source: Farbrikam-CI
    branch: master
    tags:              ### This filter is used for resolving default version
    - Production       ### Tags are AND'ed
    trigger:
      tags:            ### This filter is used for triggering the pipeline run
      - Production     ### Tags are AND'ed
      - Signed

L’extrait de code ci-dessus montre que des balises peuvent être utilisées pour déterminer la version par défaut du pipeline CI (intégration continue) à exécuter lorsque l’exécution du pipeline CD (déploiement continu) n’est pas déclenchée par une autre source/ressource ou par un déclencheur d’exécution planifiée.

Par instance, si vous avez un jeu de déclencheurs planifié pour votre pipeline CD que vous souhaitez exécuter uniquement si votre CI a la balise de production, les balises de la section déclencheurs garantissent que le pipeline CD est déclenché uniquement si la condition d’étiquetage est remplie par l’événement d’achèvement CI.

Contrôler les tâches autorisées dans les pipelines

Vous pouvez maintenant désactiver les tâches de la Place de marché. Certains d’entre vous peuvent autoriser les extensions de la Place de marché, mais pas les tâches pipelines qu’elles apportent. Pour encore plus de contrôle, nous vous permettons également de désactiver indépendamment toutes les tâches dans la boîte (à l’exception de la validation, qui est une action spéciale). Une fois ces deux paramètres activés, les seules tâches autorisées à s’exécuter dans un pipeline sont celles chargées à l’aide de tfx. Consultez https://dev.azure.com/<your_org>/_settings/pipelinessettings et recherchez la section intitulée « Restrictions des tâches » pour commencer.

Stratégie de verrouillage de déploiement exclusif

Avec cette mise à jour, vous pouvez vous assurer qu’une seule exécution est déployée dans un environnement à la fois. En choisissant le « verrou exclusif » case activée sur un environnement, une seule exécution se poursuit. Les exécutions suivantes qui souhaitent effectuer un déploiement dans cet environnement seront suspendues. Une fois l’exécution avec le verrou exclusif terminée, la dernière exécution se poursuit. Toutes les exécutions intermédiaires sont annulées.

Dans la page Ajouter case activée, sélectionnez Verrouillage exclusif pour vous assurer qu’une seule exécution est déployée dans un environnement à la fois.

Filtres de phases pour les déclencheurs de ressources de pipeline

Nous avons ajouté la prise en charge des « phases » en tant que filtre pour les ressources de pipeline dans YAML. Avec ce filtre, vous n’avez pas besoin d’attendre que l’intégralité du pipeline CI soit terminée pour déclencher votre pipeline CD. Vous pouvez maintenant choisir de déclencher votre pipeline CD à l’issue d’une étape spécifique de votre pipeline CI.

resources:
  pipelines:
  - pipeline: MyCIAlias  
    project: Fabrikam  
    source: Farbrikam-CI  
    trigger:    
      stages:            ### This stage filter is used when evaluating conditions for triggering your CD pipeline
      - PreProduction    ### stages are AND'ed. On successful completion of all the stages provided, your CD pipeline will be triggered. 
      - Production

Lorsque les étapes fournies dans le filtre de déclencheur se terminent correctement dans votre pipeline CI, une nouvelle exécution est automatiquement déclenchée pour votre pipeline CD.

Déclencheurs webhook génériques pour les pipelines YAML

Aujourd’hui, nous disposons de différentes ressources (telles que les pipelines, les conteneurs, la build et les packages) par le biais desquelles vous pouvez utiliser des artefacts et activer des déclencheurs automatisés. Toutefois, jusqu’à présent, vous ne pouviez pas automatiser votre processus de déploiement en fonction d’autres événements ou services externes. Dans cette version, nous introduisons la prise en charge des déclencheurs de webhook dans les pipelines YAML pour permettre l’intégration de l’automatisation du pipeline avec n’importe quel service externe. Vous pouvez vous abonner à des événements externes via ses webhooks (Github, Github Enterprise, Nexus, Aritfactory, etc.) et déclencher vos pipelines.

Voici les étapes à suivre pour configurer les déclencheurs de webhook :

  1. Configurez un webhook sur votre service externe. Lorsque vous créez votre webhook, vous devez fournir les informations suivantes :

    • URL de la requête : «https://dev.azure.com/< Collection ADO>/_apis/public/distributedtask/webhooks/<Nom >webHook ?api-version=6.0-preview »
    • Secret : cette option est facultative. Si vous devez sécuriser votre charge utile JSON, indiquez la valeur Secret
  2. Créez une connexion de service « Webhook entrant ». Il s’agit d’un nouveau type de connexion de service qui vous permettra de définir trois informations importantes :

    • Nom du webhook : le nom du webhook doit correspondre au webhook créé dans votre service externe.
    • En-tête HTTP : nom de l’en-tête HTTP dans la requête qui contient la valeur de hachage de la charge utile pour la vérification de la demande. Par exemple, dans le cas de GitHub, l’en-tête de requête sera « X-Hub-Signature »
    • Secret : le secret est utilisé pour analyser le hachage de charge utile utilisé pour la vérification de la requête entrante (cela est facultatif). Si vous avez utilisé un secret pour créer votre webhook, vous devez fournir la même clé secrète

    Dans la page Modifier la connexion au service, configurez les déclencheurs de webhook.

  3. Un nouveau type de ressource appelé webhooks est introduit dans les pipelines YAML. Pour vous abonner à un événement de webhook, vous devez définir une ressource webhook dans votre pipeline et la pointer vers la connexion de service webhook entrante. Vous pouvez également définir des filtres supplémentaires sur la ressource webhook en fonction des données de charge utile JSON afin de personnaliser davantage les déclencheurs pour chaque pipeline, et vous pouvez utiliser les données de charge utile sous la forme de variables dans vos travaux.

resources:
  webhooks:
    - webhook: MyWebhookTrigger          ### Webhook alias
      connection: MyWebhookConnection    ### Incoming webhook service connection
      filters:
        - path: repositoryName      ### JSON path in the payload
          value: maven-releases     ### Expected value in the path provided
        - path: action
          value: CREATED
steps:
- task: PowerShell@2
  inputs:
    targetType: 'inline'
    ### JSON payload data is available in the form of ${{ parameters.<WebhookAlias>.<JSONPath>}}
    script: |
      Write-Host ${{ parameters.MyWebhookTrigger.repositoryName}}
      Write-Host ${{ parameters.MyWebhookTrigger.component.group}}
  1. Chaque fois qu’un événement de webhook est reçu par la connexion du service webhook entrant, une nouvelle exécution est déclenchée pour tous les pipelines abonnés à l’événement webhook.

Prise en charge et traçabilité des problèmes de déclencheur de ressource YAML

Cela peut être déroutant lorsque les déclencheurs de pipeline ne parviennent pas à s’exécuter comme prévu. Pour mieux comprendre cela, nous avons ajouté un nouvel élément de menu dans la page de définition de pipeline appelé « Problèmes de déclencheur » où des informations sont exposées sur la raison pour laquelle les déclencheurs ne s’exécutent pas.

Les déclencheurs de ressources peuvent ne pas s’exécuter pour deux raisons.

  1. Si la source de la connexion de service fournie n’est pas valide ou s’il existe des erreurs de syntaxe dans le déclencheur, le déclencheur n’est pas configuré du tout. Celles-ci sont signalées sous forme d’erreurs.

  2. Si les conditions du déclencheur ne sont pas mises en correspondance, le déclencheur ne s’exécute pas. Chaque fois que cela se produit, un avertissement est généré afin que vous puissiez comprendre pourquoi les conditions n’ont pas été mises en correspondance.

    Cette page de définition de pipeline appelée Problèmes de déclencheur affiche des informations sur la raison pour laquelle les déclencheurs ne sont pas en cours d’exécution.

Déclencheurs multi-référentiels

Vous pouvez spécifier plusieurs référentiels dans un fichier YAML et provoquer le déclenchement d’un pipeline par des mises à jour de l’un des dépôts. Cette fonctionnalité est utile, pour instance, dans les scénarios suivants :

  • Vous consommez un outil ou une bibliothèque à partir d’un autre référentiel. Vous souhaitez exécuter des tests de votre application chaque fois que l’outil ou la bibliothèque est mis à jour.
  • Vous conservez votre fichier YAML dans un référentiel distinct du code de l’application. Vous souhaitez déclencher le pipeline chaque fois qu’une mise à jour est envoyée (push) au référentiel de l’application.

Avec cette mise à jour, les déclencheurs multipo fonctionnent uniquement pour les dépôts Git dans Azure Repos. Ils ne fonctionnent pas pour les ressources de dépôt GitHub ou BitBucket.

Voici un exemple qui montre comment définir plusieurs ressources de référentiel dans un pipeline et comment configurer des déclencheurs sur toutes ces ressources.

trigger:
- main

resources:
  repositories:
  - repository: tools
    type: git
    name: MyProject/tools
    ref: main
    trigger:
      branches:
        include:
        - main
        - release

Dans cet exemple, le pipeline est déclenché s’il existe des mises à jour pour :

  • main branche dans le self référentiel contenant le fichier YAML
  • main ou release branches dans le tools dépôt

Pour plus d’informations, consultez Plusieurs dépôts dans votre pipeline.

Amélioration des chargements de journaux d’activité de l’agent

Lorsqu’un agent cesse de communiquer avec le serveur Azure Pipelines, le travail qu’il exécutait est abandonné. Si vous avez regardé les journaux de la console de streaming, vous avez peut-être obtenu des indices sur ce que l’agent était juste avant qu’il ne cesse de répondre. Mais si ce n’était pas le cas, ou si vous avez actualisé la page, ces journaux de console ont disparu. Avec cette version, si l’agent cesse de répondre avant d’envoyer ses journaux d’activité complets, nous conserverons les journaux de console comme la meilleure solution. Les journaux de console sont limités à 1 000 caractères par ligne et peuvent parfois être incomplets, mais ils sont beaucoup plus utiles que de ne rien montrer ! L’examen de ces journaux peut vous aider à dépanner vos propres pipelines, et cela aidera certainement nos ingénieurs du support technique lorsqu’ils vous aident à résoudre les problèmes.

Si vous le souhaitez, monter des volumes de conteneur en lecture seule

Lorsque vous exécutez un travail de conteneur dans Azure Pipelines, plusieurs volumes contenant l’espace de travail, les tâches et d’autres matériaux sont mappés en tant que volumes. Ces volumes sont par défaut l’accès en lecture/écriture. Pour renforcer la sécurité, vous pouvez monter les volumes en lecture seule en modifiant la spécification de votre conteneur dans YAML. Chaque clé sous mountReadOnly peut être définie sur true pour la lecture seule (la valeur par défaut est false).

resources:
  containers:
    - container: example
      image: ubuntu:18.04
      mountReadOnly:
        externals: true
        tasks: true
        tools: true
        work: false

Contrôle précis sur le démarrage/l’arrêt du conteneur

En général, nous vous recommandons d’autoriser Azure Pipelines à gérer le cycle de vie de vos conteneurs de travail et de service. Toutefois, dans certains scénarios rares, vous pouvez les démarrer et les arrêter vous-même. Avec cette version, nous avons intégré cette fonctionnalité à la tâche Docker.

Voici un exemple de pipeline utilisant la nouvelle fonctionnalité :

resources:
  containers:
    - container: builder
      image: ubuntu:18.04
steps:
  - script: echo "I can run inside the container (it starts by default)"
    target:
      container: builder
  - task: Docker@2
    inputs:
      command: stop
      container: builder
# if any step tried to run in the container here, it would fail

Nous incluons également la liste des conteneurs dans une variable de pipeline, Agent.ContainerMapping. Vous pouvez l’utiliser si vous souhaitez inspecter la liste des conteneurs dans un script, par exemple. Il contient un objet JSON stringifié mappant le nom de la ressource (« générateur » de l’exemple ci-dessus) à l’ID de conteneur géré par l’agent.

Décompresser des ensembles de tâches pour chaque étape

Lorsque l’agent exécute un travail, il télécharge d’abord tous les bundles de tâches requis par les étapes du travail. Normalement, pour des questions de performances, il décompresse les tâches une fois par travail, même si la tâche est utilisée en plusieurs étapes. Si vous avez des préoccupations concernant le code non approuvé qui modifie le contenu décompressé, vous pouvez échanger un peu de performances en demandant à l’agent de décompresser la tâche à chaque utilisation. Pour activer ce mode, passez lors de --alwaysextracttask la configuration de l’agent.

Améliorer la sécurité des mises en production en limitant l’étendue des jetons d’accès

S’appuyant sur notre initiative visant à améliorer les paramètres de sécurité pour Azure Pipelines, nous prenons désormais en charge la restriction de l’étendue des jetons d’accès pour les mises en production.

Chaque travail qui s’exécute dans les versions obtient un jeton d’accès. Le jeton d’accès est utilisé par les tâches et par vos scripts pour rappeler Azure DevOps. Par exemple, nous utilisons le jeton d’accès pour obtenir le code source, télécharger des artefacts, charger des journaux, des résultats de test 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 nous appuyons sur l’amélioration de la sécurité du pipeline en limitant l’étendue des jetons d’accès et en l’étendant aux versions classiques.

Cette fonctionnalité est activée par défaut pour les nouveaux projets et collections. Pour les regroupements existants, vous devez l’activer dans les paramètres de > regroupement Paramètres des pipelines > . > Limitez l’étendue d’autorisation du travail au projet actuel pour les pipelines de mise en production. En savoir plus ici.

Améliorations apportées à l’API de préversion YAML

Vous pouvez maintenant afficher un aperçu du YAML complet d’un pipeline sans l’exécuter. En outre, nous avons créé une URL dédiée pour la fonctionnalité de préversion. Vous pouvez maintenant POST sur https://dev.azure.com/{collection}/{project}/_apis/pipelines/{pipelineId}/preview pour récupérer le corps YAML finalisé. Cette nouvelle API prend les mêmes paramètres que la mise en file d’attente d’une exécution, mais ne nécessite plus l’autorisation « Builds de file d’attente ».

Exécuter ce travail ensuite

Avez-vous déjà eu un correctif de bogue que vous deviez déployer dès cette minute , mais que vous deviez attendre derrière les travaux CI et PR ? Avec cette version, nous vous permettons désormais d’augmenter la priorité d’un travail mis en file d’attente. Les utilisateurs disposant de l’autorisation « Gérer » sur le pool ( généralement les administrateurs de pool) voient un nouveau bouton « Exécuter ensuite » sur la page des détails du travail. Cliquez sur le bouton pour définir le travail à exécuter dès que possible. (Vous aurez toujours besoin d’un parallélisme disponible et d’un agent approprié, bien sûr.)

Expressions de modèle autorisées dans le bloc YAML resources

Auparavant, les expressions de compilation (${{ }}) n’étaient pas autorisées dans la resources section d’un fichier YAML Azure Pipelines. Avec cette version, nous avons levé cette restriction pour les conteneurs. Cela vous permet d’utiliser le contenu des paramètres d’exécution à l’intérieur de vos ressources, par exemple pour choisir un conteneur au moment de la file d’attente. Nous prévoyons d’étendre cette prise en charge à d’autres ressources au fil du temps.

Contrôle des mises à jour automatisées des tâches à partir de la Place de marché

Lorsque vous écrivez un pipeline YAML, vous spécifiez normalement uniquement le numéro de version principale des tâches incluses. Cela permet à vos pipelines d’accepter automatiquement les derniers ajouts de fonctionnalités et correctifs de bogues. Parfois, vous devrez peut-être revenir à une version antérieure d’une tâche, et avec cette mise à jour, nous avons ajouté la possibilité de le faire. Vous pouvez maintenant spécifier une version complète de la tâche major.minor.patch dans vos pipelines YAML.

Nous vous déconseillons de le faire régulièrement et de ne l’utiliser que comme solution de contournement temporaire quand vous constatez qu’une tâche plus récente interrompt vos pipelines. En outre, cela n’installe pas une version antérieure d’une tâche à partir de la Place de marché. Il doit déjà exister dans votre collection pour que votre pipeline échoue.

Exemple :

steps:
- task: MyTask@1  # a normal, major-version only reference
- task: MyOtherTask@2.3.4   # pinned to a precise version

Prise en charge de Node 10 dans l’agent et les tâches

Étant donné que le nœud 6 n’est plus pris en charge, nous procédons à la migration des tâches pour qu’elles fonctionnent avec le nœud 10. Pour cette mise à jour, nous avons migré près de 50 % des tâches entrantes vers le nœud 10. L’agent peut désormais exécuter les tâches Node 6 et Node 10. Dans une prochaine mise à jour, nous supprimerons entièrement le nœud 6 de l’agent. Pour préparer la suppression du nœud 6 de l’agent, nous vous demandons de mettre à jour vos extensions internes et vos tâches personnalisées pour utiliser bientôt le nœud 10. Pour utiliser le nœud 10 pour votre tâche, dans votre task.json, sous execution, mettez à jour à partir de Node vers Node10.

Améliorer la conversion YAML dans le concepteur de build classique

Avec cette version, nous introduisons une nouvelle fonctionnalité « exporter vers YAML » pour les pipelines de build de concepteur. Enregistrez votre définition de pipeline, puis recherchez « Exporter vers YAML » dans le ... menu.

La nouvelle fonction d’exportation remplace la fonction « Afficher en tant que YAML » précédemment trouvée dans le concepteur de build classique. Cette fonction était incomplète, car elle ne pouvait inspecter que ce que l’interface utilisateur web savait de la build, ce qui entraînait parfois la génération d’un YAML incorrect. La nouvelle fonction d’exportation prend en compte exactement la façon dont le pipeline sera traité et génère YAML avec une fidélité totale au pipeline du concepteur.

Nouvelle conversion de plateforme web – Paramètres du référentiel

Nous avons converti les deux pages de paramètres du référentiel en une seule expérience qui a été mise à niveau vers une nouvelle plateforme web. Cette mise à niveau rend non seulement l’expérience plus rapide et plus moderne, mais ces pages fournissent également un point d’entrée unique pour toutes les stratégies, du niveau projet au niveau de la branche.

Nouvelle conversion de plateforme web.

Avec cette nouvelle expérience, la navigation pour les projets avec un nombre important de dépôts est devenue plus facile en raison de temps de chargement plus rapides et d’un filtre de recherche ajouté. Vous pouvez également afficher les stratégies au niveau du projet et la liste des stratégies de dépôt croisé sous l’onglet Stratégies.

Affichez les stratégies de dépôt croisé sous l’onglet Stratégies.

Si vous cliquez sur un dépôt, vous pouvez afficher les stratégies et autorisations définies au niveau du dépôt. Dans l’onglet Stratégies, vous pouvez afficher la liste de chaque branche sur laquelle la stratégie est définie. Cliquez maintenant sur la branche pour afficher les stratégies tout en ne quittant jamais la page Paramètres du dépôt.

Sélectionnez branche pour voir les stratégies.

À présent, lorsque les stratégies sont héritées d’une étendue plus élevée que celle avec laquelle vous travaillez, nous vous montrons où la stratégie a été héritée en regard de chaque stratégie individuelle. Vous pouvez également accéder à la page où la stratégie de niveau supérieur a été définie en cliquant sur le nom de l’étendue.

Indique d’où la stratégie a été héritée.

La page de stratégie elle-même a également été mise à niveau vers la nouvelle plateforme web avec des sections réductibles ! Pour améliorer l’expérience de recherche d’une stratégie de validation de build, de vérification d’état ou de réviseur automatique particulière, nous avons ajouté des filtres de recherche pour chaque section.

Filtres de recherche pour chaque section.

Intégration de la gestion des modifications ServiceNow aux pipelines YAML

L’application Azure Pipelines pour ServiceNow vous aide à intégrer Azure Pipelines et ServiceNow Change Management. Avec cette mise à jour, nous allons poursuivre notre parcours de prise en charge d’Azure Pipelines sur le processus de gestion des modifications géré dans ServiceNow, en plus des pipelines YAML.

En configurant la case activée « Gestion des modifications ServiceNow » sur une ressource, vous pouvez maintenant suspendre la modification à approuver avant de déployer la build sur cette ressource. Vous pouvez créer automatiquement une modification pour une étape ou attendre une demande de modification existante.


Intégration de la gestion des modifications ServiceNow

Vous pouvez également ajouter la UpdateServiceNowChangeRequest tâche dans un travail serveur pour mettre à jour la demande de modification avec des status de déploiement, des notes, etc.

Artifacts

Possibilité de créer des flux étendus à l’organisation à partir de l’interface utilisateur

Nous rétablissons la possibilité pour les clients de créer et de gérer des flux étendus à la collection via l’interface utilisateur web pour les services locaux et hébergés.

Vous pouvez maintenant créer des flux d’étendue d’organisation via l’interface utilisateur, en accédant à Artefacts -> Créer un flux et en choisissant un type de flux dans Étendue.

Créez des flux délimités à la collection en sélectionnant Artefacts, puis Créer un flux et en sélectionnant un type de flux dans Étendue.

Bien que nous vous recommandons d’utiliser des flux dans l’étendue du projet en alignement avec le reste des offres Azure DevOps, vous pouvez à nouveau créer, gérer et utiliser des flux délimités par la collection via l’interface utilisateur et diverses API REST. Pour plus d’informations, consultez notre documentation sur les flux.

Mettre à jour l’API REST version du package désormais disponible pour les packages Maven

Vous pouvez maintenant utiliser l’API REST « Update Package Version » d’Azure Artifacts pour mettre à jour les versions du package Maven. Auparavant, vous pouviez utiliser l’API REST pour mettre à jour les versions de package pour les packages NuGet, Maven, npm et Universal, mais pas pour les packages Maven.

Pour mettre à jour les packages Maven, utilisez la commande HTTP PATCH comme suit.

PATCH https://pkgs.dev.azure.com/{collection}/{project?}/\_apis/packaging/feeds/{feedId}/maven/groups/{groupId}/artifacts/{artifactId}/versions/{packageVersion}?api-version=5.1-preview.1

Vous pouvez définir les éléments suivants :

Paramètres d’URI

Nom Dans Obligatoire Type Description
artifactId path TRUE string ID d’artefact du package
feed path TRUE string Nom ou ID du flux
groupId path TRUE string ID de groupe du package
collection path TRUE string Nom de la collection Azure DevOps
version path TRUE string Version du package
project path string ID de projet ou nom du projet
api-version query TRUE string Version de l’API à utiliser. Cette valeur doit être définie sur « 5.1-preview.1 » pour utiliser cette version de l’api

Corps de la requête

Nom Type Description
views JsonPatchOperation Vue à laquelle la version du package sera ajoutée

Pour plus d’informations, reportez-vous à la documentation de l’API REST lors de sa mise à jour.

Commentaires

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


Haut de la page