Notes de publication d’Azure DevOpsServer 2020 Update 1

Conditions | de licence requises pour la communauté | | des développeurs DevOps Blog | SHA-1 Hachages

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

Pour en savoir plus sur l’installation ou la mise à niveau d’un déploiement Azure DevOps Server, consultez 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 2020 est prise en charge à partir d’Azure DevOps Server 2019 ou Team Foundation Server 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 1.2 Patch 14 : 12 novembre 2024

File	Hachage SHA-256
devops2020.1.2patch14.exe	29012B79569F042E2ED4518CE7216CA521F9435CCD80295B71F734AA60FCD03F

Nous avons publié patch 14 pour Azure DevOps Server 2020 Update 1.2 afin d’inclure une mise à niveau vers une dépendance vulnérable.

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

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

Nous avons publié patch 13 pour Azure DevOps Server 2020 Update 1.2 qui inclut des correctifs pour les éléments suivants :

• Résolution d’un problème où le serveur proxy a cessé de fonctionner après l’installation de Patch 12.

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

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

Nous avons publié patch 12 pour Azure DevOps Server 2020 Update 1.2 qui inclut des correctifs pour les éléments suivants :

• Correction d’un bogue où l’espace disque utilisé par le dossier du cache proxy était calculé de manière incorrecte et que le dossier n’était pas correctement nettoyé.
• CVE-2024-20667 : Vulnérabilité d’exécution de code à distance d’Azure DevOps Server.

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

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

Nous avons publié patch 11 pour Azure DevOps Server 2020 Update 1.2 qui inclut des correctifs pour les éléments suivants :

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

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

Nous avons publié un correctif pour Azure DevOps Server 2020 Update 1.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.

Installer les correctifs

Configurer TFX

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

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

File	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 relatives aux pipelines

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

• Sur 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 1.2 Patch 9 : 10 octobre 2023

Nous avons publié un correctif. pour Azure DevOps Server 2020 Update 1.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 ordinateurs de mise à niveau des correctifs.

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

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

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

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.  

Configurer TFX

1. Suivez les étapes de la documentation sur le téléchargement des tâches dans la collection de projets pour installer et vous connecter à 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 relatives aux pipelines

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

• Sur 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 1.2 Patch 7 : 8 août 2023

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

• CVE-2023-36869 : Vulnérabilité d’usurpation d’identité azure DevOps Server.
• 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 effectuer une mise à jour vers SHA2 ou supprimer l’entrée.
• Problème résolu avec les liens relatifs qui ne fonctionnent pas dans les fichiers Markdown.
• Correction d’un bogue avec navigation de commentaire sur une page de validation.
• Correction d’un bogue dans lequel l’identité du propriétaire d’analyse s’est montrée comme une identité inactive.
• Correction du bogue de boucle infinie sur CronScheduleJobExtension.

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

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

• CVE-2023-21565 : Vulnérabilité d’usurpation d’identité azure DevOps Server.
• CVE-2023-21569 : Vulnérabilité d’usurpation d’identité azure DevOps Server.
• Correction d’un bogue qui interfère avec les packages push lors de la mise à niveau à partir de 2018 ou version antérieure.
• Correction d’un bogue dans lequel la collection de détachements ou d’attachement ne signale pas 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.

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

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

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

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

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

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

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

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

Nous avons publié un correctif pour Azure DevOps Server 2020 Update 1.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 génération de vérification contrôlée lorsque les paramètres de l’organisation pour le pipeline avaient une étendue d’autorisation de travail configurée en tant que limite l’étendue d’autorisation du 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é.

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

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

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

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

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

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

Date de publication d’Azure DevOps Server 2020 Update 1.2 : 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 d’Azure DevOps Server 2020 ou Team Foundation Server 2013 ou version ultérieure.

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) pour empêcher la perte d’exécutions de pipeline (builds). Cela signifie que le système effectue les tâches suivantes :

  • 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 seront conservées en fonction de la stratégie de rétention spécifique au pipeline.
  • Les builds avec des baux ne comptent pas vers le paramètre Minimum pour conserver le paramètre

• Les liens des commentaires de l’ensemble de modifications et de l’ensemble de rayons n’ont pas été redirigés correctement. Lorsque des commentaires ont été ajoutés à des fichiers dans des ensembles de modifications ou des ensembles de rayons, la sélection de ces commentaires n’a pas été redirigée vers l’emplacement approprié dans l’affichage de fichiers.

• Impossible d’ignorer la file d’attente de build à l’aide du bouton « Exécuter 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.1.1 Patch 4 : 26 janvier 2022

Nous avons publié un correctif pour Azure DevOps Server 2020.1.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.
• L’adresse e-mail préférée n’a pas été 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’a pas été 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 à l’adresse HKLM:\Software\Elasticsearch\Version. Si la valeur du registre n’y figure pas, ajoutez une valeur de chaîne et définissez la version sur 5.4.1 (Nom = Version, Valeur = 5.4.1).
3. Exécutez la commande PS C:\Program Files\{TFS Version Folder}\Search\zip> .\Configure-TFSSearch.ps1 -Operation update de mise à jour comme indiqué dans le fichier lisez-moi. Elle peut renvoyer un avertissement tel que : Impossible de se connecter au serveur distant. Ne fermez pas la fenêtre, car la mise à jour effectue des nouvelles tentatives tant qu’elle n’est pas terminée.

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

Hachage SHA-256 : 451F0BB73132EFCD2B3D2922F0040DBF2BCF2808C35D3C37CA5A3CD8F65F29D6

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

Le correctif 3 pour Azure DevOps Server 2020.1.1 inclut des correctifs pour les éléments suivants.

• Correction de la macro d’élément de travail pour les requêtes avec « Contient des mots ». Auparavant, les requêtes retournaient 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 d’é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.

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

Le correctif 2 pour Azure DevOps Server 2020.1.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 sur 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.1.1 Patch 1 : 14 septembre 2021

Le correctif 1 pour Azure DevOps Server 2020.1.1 inclut des correctifs pour les éléments suivants.

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

Date de publication d’Azure DevOps Server 2020 Update 1.1 : 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 effectuer une mise à niveau à partir d’Azure DevOps Server 2020 ou Team Foundation Server 2013 ou version ultérieure.

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 des cases à cocher d’héritage des types de fusion limités affichées pour activer la modification des types de fusion limités après avoir défini des stratégies de dépôt croisé.

Azure Pipelines

• Lorsque vous modifiez le paramètre de mise à jour de l’agent, les paramètres ne se propagent pas à d’autres niveaux d’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.

---

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

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

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

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

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

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

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

Résumé des nouveautés d’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 d’Azure DevOps Server 2020.1 RC2 précédemment publiées. 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 d’Azure DevOps Server 2020, 2019 ou Team Foundation Server 2015 ou version ultérieure.

Date de publication d’Azure DevOps Server 2020.1 RC2 : 13 avril 2021

Résumé des nouveautés d’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 d’Azure DevOps Server 2020.1 RC1 précédemment publiées.

Date de publication d’Azure DevOps Server 2020.1 RC1 : 23 mars 2021

Résumé des nouveautés d’Azure DevOps Server 2020.1 RC1

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

• Règles de restriction de transition d’état dans les tableaux
• Les parties prenantes peuvent désormais déplacer des éléments de travail dans plusieurs colonnes de tableau
• Amélioration de la sécurité des versions en limitant l’étendue des jetons d’accès
• Expérience de demande de tirage améliorée
• Déclencheurs multirépo dans pipelines

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

• Boards
• Référentiels
• Pipelines
• Artefacts

---

Boards

Règles de restriction de transition d’état

Nous continuons à combler l’écart de parité des fonctionnalités entre le code 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 d’éléments de travail d’un état à un autre. Par exemple, vous pouvez restreindre les bogues d’aller de Nouveau à Résolu. Au lieu de cela, ils doivent aller de Nouveau -> Actif -> Résolu

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 des récits utilisateur à partir 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 pour « Inclure des éléments de travail enfants » dans la boîte de dialogue Copier l’élément de travail. Lorsque cette option est sélectionnée, cette option copie l’élément de travail et copie tous les éléments de travail enfants (jusqu’à 100).

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 ont été un mystère. Elles sont définies uniquement pour les types d’éléments de travail système et sont spécifiques à la valeur d’état « Active » et « Résolu ». 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 disposez d’un état personnalisé de « Tests des besoins » dans la catégorie résolue. Lorsque l’élément de travail passe de « Actif » à « Tests des besoins », les règles De date résolues et By sont déclenchées.

Cela permet aux clients de créer des valeurs d’état personnalisées et de générer toujours les champs Activé par, Date activée, Résolu par et Date résolue, sans avoir à utiliser de règles personnalisées.

Les parties prenantes peuvent déplacer des éléments de travail dans plusieurs colonnes de tableau

Les parties prenantes ont toujours pu 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 vers une autre. Au lieu de cela, les parties prenantes doivent ouvrir chaque élément de travail, un à la fois et mettre à jour la valeur d’état. Cela a longtemps été un point de douleur pour les clients, et nous sommes heureux d’annoncer que vous pouvez maintenant déplacer des éléments de travail dans les colonnes de tableau.

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

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

Process	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 du backlog. Sélectionnez le niveau de votre backlog de choix (exemple : Backlog des exigences) et choisissez l’option de modification. Ajoutez ensuite le type d’élément de travail.

Limite de dépôt d’application GitHub Azure Boards levée

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

Personnaliser l’état de l’élément de travail lorsque la demande de tirage est fusionnée

Tous les flux de travail 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 de fermer. 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 scannons la description de la demande de tirage et recherchons 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 fermant deux tâches.

Lier votre élément de travail à des builds dans un autre projet

Vous pouvez désormais facilement suivre vos dépendances de build dans le projet en liant simplement votre élément de travail à une build, trouvée dans la build ou intégrée dans la build.

Modification de description (texte d’aide) sur des 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 code XML hébergé et l’héritage 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.

Personnaliser l’état de l’élément de travail lorsque la demande de tirage est fusionnée

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 certains d’entre eux, résoudre certains d’entre eux 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.

Champ parent dans le tableau des tâches

En raison d’une demande populaire, vous pouvez maintenant ajouter le champ Parent aux cartes enfants et parentes du Tableau des tâches.

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

Il existe plusieurs règles système masquées sur tous les différents types d’éléments de travail dans Agile, Scrum et CMMI. Ces règles ont existé depuis plus d’une décennie et ont généralement fonctionné correctement sans plainte. Toutefois, il existe quelques règles qui ont dépassé 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 le supprimer. Cette règle existe sur le type d’élément de travail Bogue dans le processus Agile.

« Définir la valeur affectée sur Created By when state is changed to Resolved »

Nous avons reçu beaucoup de vos commentaires sur cette règle. En réponse, nous avons poursuivi et supprimé cette règle du type d’élément de travail Bogue dans le processus Agile. Cette modification affecte chaque projet à l’aide d’un processus Agile hérité ou hérité 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 un endroit idéal pour trouver rapidement les éléments que vous avez créés ou qui vous sont attribués, entre autres. Il fournit plusieurs pivots et filtres personnalisés. L’une des principales plaintes pour le tableau croisé dynamique « Affecté à moi » est qu’elle affiche les éléments de travail supprimés (autrement dit, 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 ont donc été supprimés du backlog, de sorte que son inclusion dans cette vue n’est pas utile.

Vous pouvez maintenant masquer tous les éléments supprimés du tableau croisé dynamique Affecté à moi dans la page Éléments de travail.

Référentiels

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 référentiel, vous pouvez choisir n’importe quel nom de branche légale à utiliser lorsqu’un référentiel est initialisé. Azure Repos a toujours pris en charge la modification du nom branche par défaut pour un référentiel existant.

Pour plus d’informations, consultez Gérer les branches et modifier le branche par défaut.

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

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

Ajouter une nouvelle étendue d’autorisation pour les commentaires de demandes de tirage

Cette version ajoute une nouvelle étendue OAuth pour lire/écrire des commentaires de demande de tirage. Si vous disposez d’un bot ou d’une automatisation qui a uniquement besoin d’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 a un bogue ou si le jeton a été compromis.

Améliorations apportées à l’expérience de demande 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 d’aperçu. Une coche verte volumineuse sur les contrôles requis masque les échecs dans les vérifications facultatives. Les utilisateurs n’ont pu découvrir que les vérifications facultatives ont échoué 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 l’état des vérifications facultatives plus visibles dans le résumé.

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

Les menus onglets d’une demande de tirage ne prenaient pas en charge le clic Ctrl. Les utilisateurs ouvrent souvent de nouveaux onglets de navigateur au fur et à mesure qu’ils passent en revue une demande de tirage. Ce problème a été résolu.

• Emplacement de l’annotation [+]

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

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

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

• **Disposition améliorée du filtre de commentaire **

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

• Navigation vers les validations parentes

Dans la page Validations, vous pouvez comparer les modifications apportées dans une validation particulière avec sa validation parente. Toutefois, vous souhaiterez peut-être accéder à la validation parente et comprendre comment cette validation diffère de son propre parent. Cela est souvent nécessaire lorsque vous souhaitez comprendre toutes les modifications d’une version. Nous avons ajouté une carte parente à une validation pour vous aider à y parvenir.

• Plus d’espace pour les dossiers et fichiers aux noms longs sous l’onglet des fichiers PR

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, à l’exception du pointage.

Image de la nouvelle arborescence de fichiers :

Image de l’arborescence de fichiers lors du pointage sur un répertoire :

• Conserver la position de défilement lors du redimensionnement du volet Diff sous l’onglet des fichiers PR

Lorsque vous redimensionnez le volet de différences côte à côte sous l’onglet Fichiers PR, 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 du volet de différences.

• Rechercher une validation sur un appareil mobile

Lorsque vous affichez 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 une validation par son hachage et de l’ouvrir. Cela a été résolu maintenant.

• Utilisation améliorée de l’espace pour le nouvel affichage mobile Diff de fichier PR

Nous avons mis à jour cette page pour améliorer l’utilisation de l’espace afin que les utilisateurs puissent voir plus du fichier dans les affichages mobiles au lieu d’avoir 40 % de l’écran pris en charge par un en-tête.

• Images améliorées en mode résumé de demande de tirage

Les images modifiées dans une demande de tirage n’étaient pas affichées dans la vue récapitulative de la demande de tirage, mais elles s’affichaient correctement dans la vue des 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 PR

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

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 modifications du code aient été minimes, beaucoup de travail en arrière-plan devaient être terminés en premier, et nous sommes heureux d’annoncer sa publication !

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

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

resources:
  pipelines:
  - pipeline: MyCIAlias
    project: Fabrikam
    source: Farbrikam-CI
    branch: main
    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 les 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 un déclencheur d’exécution planifié.

Par exemple, si vous avez un jeu de déclencheurs planifié pour votre pipeline CD que vous souhaitez exécuter uniquement si votre ci dispose de 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’ils apportent. Pour un contrôle encore plus grand, nous vous permettent également de désactiver indépendamment toutes les tâches in-the-box (à l’exception de l’extraction, qui est une action spéciale). Avec ces deux paramètres activés, les seules tâches autorisées à s’exécuter dans un pipeline seraient celles chargées à l’aide de tfx. Visitez et recherchez https://dev.azure.com/<your_org>/_settings/pipelinessettings la section intitulée « Restrictions de tâche » 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 sur un environnement à la fois. En choisissant la vérification « Verrouillage exclusif » sur un environnement, une seule exécution se poursuit. Les exécutions suivantes qui souhaitent être déployées sur cet environnement seront suspendues. Une fois l’exécution terminée avec le verrou exclusif, la dernière exécution se poursuit. Toutes les exécutions intermédiaires seront annulées.

Filtres d’étapes pour les déclencheurs de ressources de pipeline

Nous avons ajouté la prise en charge des « phases » comme filtre pour les ressources de pipeline dans YAML. Avec ce filtre, vous n’avez pas besoin d’attendre que l’ensemble du pipeline CI soit terminé pour déclencher votre pipeline CD. Vous pouvez maintenant choisir de déclencher votre pipeline CD à la fin 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 sont correctement terminées 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 des pipelines, des conteneurs, des builds et des packages) via lesquelles vous pouvez consommer des artefacts et activer des déclencheurs automatisés. Toutefois, jusqu’à présent, vous n’avez pas pu 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 webhook dans les pipelines YAML pour permettre l’intégration de l’automatisation des pipelines à n’importe quel service externe. Vous pouvez vous abonner à tous les é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 demande - «https://dev.azure.com/< Collection> ADO/_apis/public/distributedtask/webhooks/<Nom> webHook ?api-version=6.0-preview »
   • Secret : cela est facultatif. Si vous devez sécuriser votre charge utile JSON, fournissez 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 charge utile pour la vérification de la demande. Par exemple, dans le cas de GitHub, l’en-tête de requête est « 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 (facultatif). Si vous avez utilisé un secret pour créer votre webhook, vous devez fournir la même clé secrète

   

3. Un nouveau type de ressource appelé webhooks est introduit dans les pipelines YAML. Pour vous abonner à un événement webhook, vous devez définir une ressource webhook dans votre pipeline et la pointer vers la connexion du service webhook entrant. Vous pouvez également définir des filtres supplémentaires sur la ressource webhook en fonction des données de charge utile JSON pour personnaliser davantage les déclencheurs pour chaque pipeline, et vous pouvez consommer 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}}

4. Chaque fois qu’un événement 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

Il 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ée « Problèmes de déclencheur » où les informations sont exposées concernant 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 exposées sous forme d’erreurs.

2. Si les conditions du déclencheur ne sont pas mises en correspondance, le déclencheur n’est pas exécuté. Chaque fois que cela se produit, un avertissement est exposé afin de comprendre pourquoi les conditions n’ont pas été mises en correspondance.

   

Déclencheurs multirépo

Vous pouvez spécifier plusieurs référentiels dans un fichier YAML et déclencher un pipeline en mettant à jour l’un des référentiels. Cette fonctionnalité est utile, par exemple, 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 multi-référentiels fonctionnent uniquement pour les référentiels Git dans Azure Repos. Ils ne fonctionnent pas pour les ressources de référentiel 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 tous ces déclencheurs.

trigger:
- main

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

Le pipeline de cet exemple 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 référentiels dans votre pipeline.

Améliorations des téléchargements du journal de l’agent

Lorsqu’un agent cesse de communiquer avec le serveur Azure Pipelines, le travail en cours d’exécution devient abandonné. Si vous examinez les journaux de la console de diffusion en continu, vous avez peut-être obtenu des indices sur ce que l’agent était à droite avant qu’il ne réponde. Mais si vous n’étiez pas, ou si vous avez actualisé la page, ces journaux de console ont disparu. Avec cette version, si l’agent cesse de répondre avant qu’il n’envoie ses journaux complets, nous allons conserver les journaux de la console comme meilleure chose. 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 de support lorsqu’ils vous aident à résoudre les problèmes.

Vous pouvez également 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 accessibles 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 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 affiné sur le démarrage/l’arrêt d’un 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 commencer 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

En outre, nous incluons 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 » à partir de l’exemple ci-dessus) à l’ID de conteneur que l’agent gère.

Décompression des groupes de tâches pour chaque étape

Lorsque l’agent exécute un travail, il télécharge tout d’abord tous les ensembles de tâches requis par les étapes du travail. Normalement, pour les 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é modifiant le contenu décompressé, vous pouvez supprimer un peu de performances en faisant décompresser la tâche sur chaque utilisation. Pour activer ce mode, passez --alwaysextracttask lors de la configuration de l’agent.

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

En 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 versions.

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 dans Azure DevOps. Par exemple, nous utilisons le jeton d’accès pour obtenir du 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 étendant la même chose aux versions classiques.

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

Améliorations de la version préliminaire de l’API YAML

Vous pouvez maintenant afficher un aperçu du YAML complet d’un pipeline sans l’exécuter. En outre, nous avons créé une nouvelle URL dédiée pour la fonctionnalité d’aperçu. Vous pouvez maintenant publier pour https://dev.azure.com/{collection}/{project}/_apis/pipelines/{pipelineId}/preview 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 « Files d’attente ».

Exécuter ce travail ensuite

Avez-vous déjà eu un correctif de bogue dont vous aviez besoin pour déployer cette minute , mais deviez attendre derrière les travaux CI et PR ? Avec cette version, nous vous permettent désormais de faire passer la priorité d’un travail en file d’attente. Les utilisateurs disposant de l’autorisation « Gérer » sur le pool ( généralement les administrateurs du pool) voient un nouveau bouton « Exécuter suivant » dans la page des détails du travail. Cliquez sur le bouton pour que le travail soit exécuté dès que possible. (Vous aurez toujours besoin du 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 au moment de la 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 ce support à d’autres ressources au fil du temps.

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

Lorsque vous écrivez un pipeline YAML, vous spécifiez normalement uniquement le numéro de version principal des tâches incluses. Cela permet à vos pipelines de prendre 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 nous l’utilisons uniquement comme solution de contournement temporaire lorsque 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 ou 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 du nœud 10 dans l’agent et les tâches

Étant donné que Node 6 n’est plus pris en charge, nous migrez les tâches pour travailler avec Node 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 à la fois les tâches Node 6 et Node 10. Dans une prochaine mise à jour, nous allons entièrement supprimer Node 6 de l’agent. Pour préparer la suppression de Node 6 de l’agent, nous vous demandons de mettre à jour vos extensions internes et vos tâches personnalisées pour utiliser également Node 10 bientôt. Pour utiliser Node 10 pour votre tâche, dans votre task.json, sous execution, mettez à jour à Node10partir de Node .

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

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

La nouvelle fonction d’exportation remplace la fonction « View as YAML » précédemment trouvée dans le concepteur de build classique. Cette fonction était incomplète, car elle pouvait uniquement inspecter ce que l’interface utilisateur web savait sur la build, ce qui a parfois conduit à une génération YAML incorrecte. 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 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 du projet au niveau de la branche.

Avec cette nouvelle expérience, la navigation pour les projets avec un nombre important de référentiels 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 référentiel croisé sous l’onglet Stratégies.

Si vous cliquez dans un référentiel, vous pouvez afficher les stratégies et les autorisations définies au niveau du référentiel. Dans l’onglet Stratégies, vous pouvez afficher la liste de chaque branche sur laquelle la stratégie est définie. À présent, cliquez sur la branche pour afficher les stratégies tout en ne laissant jamais la page des paramètres du référentiel.

À présent, lorsque les stratégies sont héritées d’une étendue supérieure à celle avec laquelle vous travaillez, nous vous montrons où la stratégie a été héritée à côté 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.

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, nous avons ajouté des filtres de recherche pour chaque section.

Intégration de la gestion des changements ServiceNow avec des pipelines YAML

L’application Azure Pipelines pour ServiceNow vous aide à intégrer Azure Pipelines et ServiceNow Change Management. Avec cette mise à jour, nous allons faire en sorte qu’Azure Pipelines prenne conscience du processus de gestion des modifications géré dans ServiceNow plus loin dans les pipelines YAML.

En configurant la vérification « 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.

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

Artifacts

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

Nous ramenons 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 l’étendue.

Bien que nous vous recommandons d’utiliser des flux d’étendue de projet en alignement avec les autres offres Azure DevOps, vous pouvez à nouveau créer, gérer et utiliser des flux étendus à la collecte via l’interface utilisateur et diverses API REST. Pour plus d’informations, consultez notre documentation sur les flux.

Mise à jour de l’API REST de version Package maintenant 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 pouvez utiliser l’API REST pour mettre à jour les versions des packages NuGet, Maven, npm et Universal, mais pas 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	VRAI	string	ID d’artefact du package
feed	path	VRAI	string	Nom ou ID du flux
groupId	path	VRAI	string	ID de groupe du package
collection	path	VRAI	string	Nom de la collection Azure DevOps
version	path	VRAI	string	Version du package
projet	path		string	ID de projet ou nom du projet
api-version	query	VRAI	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 demande

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 à mesure qu’elle est mise à jour.

Retours d'expérience

Nous sommes à votre écoute ! 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