notes de publication Azure DevOps Server 2019 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 2019 Update 1.2 Patch 8 Date de publication : 12 mars 2024

Fichier	Hachage SHA-256
devops2019.1.2patch8.exe	67E78EA7D67A09A6EE06309614F92E6D8495DEF52FF442E4E4E7C7979244FAD20A

Nous avons publié le correctif 8 pour Azure DevOps Server mise à jour 2019 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 du correctif 7.

Azure DevOps Server 2019 Update 1.2 Patch 7 Date de publication : 13 février 2024

Fichier	Hachage SHA-256
devops2019.1.2patch7.exe	8C67C72A83C9215302BDEFB752A7C4E3F876D4D17FCFA63A02B955FCFB5455AA

Nous avons publié le correctif 7 pour Azure DevOps Server mise à jour 2019 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 2019 Update 1.2 Patch 6 Date de publication : 14 novembre 2023

Nous avons publié un correctif pour Azure DevOps Server mise à jour 2019 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 5 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 5, nous vous recommandons d’installer ces mises à jour avant d’installer le correctif 6. La nouvelle version de l’agent après l’installation du correctif 5 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 2019 Update 1.2 Patch 5 Date de publication : 12 septembre 2023

Nous avons publié un correctif pour Azure DevOps Server mise à jour 2019 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 2019 Update 1.2 patch 5.

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 2019 Update 1.2 Patch 4 Date de publication : 8 août 2023

Nous avons publié un correctif pour Azure DevOps Server mise à jour 2019 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.
• Correction d’un bogue de boucle infinie sur CronScheduleJobExtension.

Azure DevOps Server 2019 Update 1.2 Patch 3 Date de publication : 13 juin 2023

Nous avons publié un correctif pour Azure DevOps Server mise à jour 2019 1.2 qui inclut les correctifs suivants.

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

Azure DevOps Server 2019 Update 1.2 Patch 2 Date de publication : 13 décembre 2022

Nous avons publié un correctif pour Azure DevOps Server mise à jour 2019 1.2 qui inclut les correctifs suivants.

• Correction des échecs dans le « Travail d’analyse de la synchronisation du parallélisme de compte ».

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

Nous avons publié un correctif pour Azure DevOps Server mise à jour 2019 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.
• Lors de la modification d’un pipeline classique, l’onglet rétention était vide après avoir ignoré les modifications sur un autre onglet.

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

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

Notes

L’outil de migration de données sera disponible pour Azure DevOps Server 2019 Update 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 :

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

Azure DevOps Server 2019 Update 1.1 Patch 13 Date de publication : 26 janvier 2022

Nous avons publié un correctif pour Azure DevOps Server 2019 Update 1.1 qui inclut des correctifs pour les éléments 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’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.
• 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 13.
2. Vérifiez la valeur du Registre à l’adresse HKLM:\Software\Elasticsearch\Version. Si la valeur de Registre n’existe pas, ajoutez une valeur de chaîne et définissez version sur 5.4.1 (Nom = Version, Valeur = 5.4.1).
3. Exécutez la commande PS C:\Program Files\{TFS Version Folder}\Search\zip> .\Configure-TFSSearch.ps1 -Operation update update comme indiqué dans le fichier lisez-moi. Il peut renvoyer un avertissement du type : Impossible de se connecter au serveur distant. Ne fermez pas la fenêtre, car la mise à jour effectue de nouvelles tentatives jusqu’à ce qu’elle soit terminée.

Notes

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

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

Hachage SHA-256 : DB762E391F9DF8E71E58D6FAA169CA44DFBE996AE6567B55F772CBA9E3DA2AB3

Azure DevOps Server 2019 Update 1.1 Patch 12 Date de publication : 15 septembre 2021

Le correctif 12 pour Azure DevOps Server 2019 Update 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 renvoyaient des résultats incorrects pour les valeurs qui contenaient un saut de ligne.
• 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 2019 Update 1.1 Patch 11 Date de publication : 14 septembre 2021

Le correctif 11 pour Azure DevOps Server 2019 Update 1.1 inclut des correctifs pour les éléments suivants.

• Résolvez le problème signalé dans ce ticket de commentaires Developer Community.

Azure DevOps Server 2019 Update 1.1 Patch 10 Date de publication : 10 août 2021

Le correctif 10 pour Azure DevOps Server 2019 Update 1.1 inclut des correctifs pour les éléments suivants.

• Correction du problème lié aux tâches de remise d’e-mails pour certains types d’éléments de travail.

Azure DevOps Server 2019 Update 1.1 Patch 9 Date de publication : 15 juin 2021

Le correctif 9 pour Azure DevOps Server 2019 Update 1.1 inclut des correctifs pour les éléments suivants.

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

Azure DevOps Server 2019 Update 1.1 Patch 8 Date de publication : 13 avril 2021

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

• CVE-2021-27067 : Divulgation d’informations
• Résoudre le problème signalé dans ce ticket de commentaires Developer Community | Impossible d’inscrire les détails de l’itération des résultats de test sur Azure DevOps Server 2019

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

Installation générale des correctifs

Si vous avez Azure DevOps Server 2019 Update 1.1, vous devez installer Azure DevOps Server 2019 Update 1.1 Patch 8.

Vérification de l’installation

• Option 1 : exécutez devops2019.1.1patch8.exe CheckInstall, devops2019.1.1patch8.exe est le fichier téléchargé à partir du lien ci-dessus. La sortie de la commande indique soit que le correctif a été installé, soit qu’il n’est pas installé.

• Option 2 : Vérifiez la version du fichier suivant : [INSTALL_DIR]\Azure DevOps Server 2019\Application Tier\Web Services\bin\Microsoft.VisualStudio.Services.Feed.Server.dll. Azure DevOps Server 2019 est installé c:\Program Files\Azure DevOps Server 2019 sur par défaut. Après avoir installé Azure DevOps Server 2019.1.1 Patch 8, la version sera 17.153.31129.2.

Installation de la tâche AzureResourceGroupDeploymentV2

Notes

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

Installer

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

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

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

npm install -g tfx-cli

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

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

~$ tfx login
Copyright Microsoft Corporation

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

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

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

Azure DevOps Server 2019 Update 1.1 Patch 7 Date de publication : 12 janvier 2021

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

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

Azure DevOps Server 2019 Update 1.1 Patch 6 Date de publication : 8 décembre 2020

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

• CVE-2020-1325 : Azure DevOps Server vulnérabilité d’usurpation d’identité
• CVE-2020-17135 : Azure DevOps Server vulnérabilité d’usurpation d’identité
• CVE-2020-17145 : vulnérabilité d’usurpation d’identité Azure DevOps Server et Team Foundation Services
• Résolution du problème lié au fait que TFVC ne traitait pas tous les résultats

Important

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

Installation générale des correctifs

Si vous avez Azure DevOps Server 2019 Update 1.1, vous devez installer Azure DevOps Server 2019 Update 1.1 Patch 6.

Vérification de l’installation

• Option 1 : exécutez devops2019.1.1patch6.exe CheckInstall, devops2019.1.1patch6.exe est le fichier téléchargé à partir du lien ci-dessus. La sortie de la commande indique soit que le correctif a été installé, soit qu’il n’est pas installé.

• Option 2 : Vérifiez la version du fichier suivant : [INSTALL_DIR]\Azure DevOps Server 2019\Application Tier\Web Services\bin\Microsoft.VisualStudio.Services.Feed.Server.dll. Azure DevOps Server 2019 est installé c:\Program Files\Azure DevOps Server 2019 sur par défaut. Après avoir installé Azure DevOps Server 2019.1.1 Patch 6, la version sera 17.153.30723.5.

Installation de la tâche AzurePowerShellV4

Notes

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

Prérequis

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

2. Créez un pipeline avec la tâche AzurePowerShellV4 . Vous ne verrez qu’une seule erreur d’échec sur l’erreur standard dans la tâche.

Installer

1. Extrayez le package AzurePowerShellV4.zip dans un dossier nommé AzurePowerShellV4.

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

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

npm install -g tfx-cli

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

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

~$ tfx login
Copyright Microsoft Corporation

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

6. Exécutez la commande suivante pour charger la tâche sur le serveur. Le chemin d’accès du package extrait est D :\tasks\AzurePowerShellv4.

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

Azure DevOps Server 2019 Update 1.1 Patch 5 Date de publication : 8 septembre 2020

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

• DTS 1713492 : comportement inattendu lors de l’ajout de groupes AD aux autorisations de sécurité.

Azure DevOps Server 2019 Update 1.1 Patch 4 Date de publication : 14 juillet 2020

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

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

Azure DevOps Server 2019 Update 1.1 Patch 3 Date de publication : 9 juin 2020

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

• CVE-2020-1327 : Vérifiez que le serveur Azure DevOps assainit les entrées utilisateur.

Azure DevOps Server 2019 Update 1.1 Patch 2 Date de publication : 14 avril 2020

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

• Les commits SVN ne déclenchent pas le pipeline

• Ajout de la prise en charge de SHA2 dans SSH sur Azure DevOps

Azure DevOps Server 2019 Update 1.1 Patch 1 Date de publication : 10 mars 2020

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

• CVE-2020-0700 : Vulnérabilité de script intersite

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

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

---

date de publication de Azure DevOps Server 2019 Update 1.1 RTW : 10 décembre 2019

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

Notes

L’outil de migration de données sera disponible pour Azure DevOps Server mise à jour 2019 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

• Lors de la création d’un élément de travail à partir du backlog du produit, le champ Titre n’est pas initialisé avec la valeur par défaut dans le modèle de processus.
• Lenteur et délais d’attente lors de l’utilisation de Azure Boards.
• La valeur Revised By est incorrecte sur les liens d’élément de travail.

Azure Pipelines

• Dans les notifications Pipelines, des champs tels que Durée peuvent être null dans certains paramètres régionaux.
• Le chemin du modèle peut ne pas pointer vers un fichier JSON valide dans un pipeline qui inclut un déploiement de groupe de ressources Azure.
• La page paramètres de rétention au niveau de la collection s’affiche dans les pages des paramètres du projet.

Azure Test Plans

• La modification des champs dans Test Plans est lente.
• Dans un cas de test, lors de l’ouverture à partir de tableaux (par opposition à Test Plans), les détails de l’étape partagée ne s’ouvrent pas.

Général

• Les collections ne sont pas triées par ordre alphabétique.

Administration

• Utilisation élevée de la mémoire.
• Les serveurs avec des configurations d’équilibreur de charge devaient ajouter explicitement leur origine publique à l’entrée de Registre AllowedOrigins.
• Les clients qui installent sur SQL Azure ne voient pas la boîte de dialogue Terminer la version d’évaluation.
• L’installation des extensions génère l’erreur « Message d’erreur Contribution manquante (ms.vss-dashboards-web.widget-sdk-version-2) ».
• Lors de la configuration de la recherche élastique, il existe une erreur : « L’utilisateur n’est pas autorisé ».
• Échecs d’indexation et de requête dans la recherche élastique lors de la mise à niveau à partir de TFS 2018 Update 2 ou version ultérieure.
• L’étape « Créer un entrepôt » échoue lors de la configuration de Azure DevOps Server.

Cette version inclut la mise à jour suivante :

• Prise en charge de SQL Server 2019.

---

Azure DevOps Server 2019 Update 1 Patch 1 Date de publication : 10 septembre 2019

Nous avons publié un correctif de sécurité pour Azure DevOps Server mise à jour 2019 1 qui corrige le bogue suivant. Consultez le billet de blog pour plus d’informations.

• CVE-2019-1306 : Vulnérabilité d’exécution de code à distance dans le Wiki

---

Azure DevOps Server 2019 Update 1 Date de publication : 20 août 2019

Notes

L’outil de migration de données sera disponible pour Azure DevOps Server mise à jour 2019 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 RC2 : 23 juillet 2019

RC2 inclut plusieurs correctifs de bogues depuis RC1 et constitue la dernière préversion planifiée.

---

Date de publication de RC1 : 2 juillet 2019

Résumé des nouveautés de Azure DevOps Server 2019 Update 1

Azure DevOps Server 2019 Update 1 introduit de nombreuses nouvelles fonctionnalités. Voici les principales :

• Nouveau processus de base
• Requête pour le travail relatif au début de la journée, de la semaine, du mois ou de l’année
• Accepter et exécuter des problèmes dans GitHub lors de la planification dans Azure Boards
• Réexécuter la build expirée pour les demandes de tirage à la saisie automatique
• Nouveaux types de fusion pour effectuer des demandes de tirage
• Déclencher des pipelines YAML avec des balises
• Assistant de tâches pour modifier des fichiers YAML
• Éditeur web avec IntelliSense pour les pipelines YAML
• Gérer les versions de GitHub à l’aide de pipelines
• Widget Tendance des résultats de test (Avancé)
• Informations de provenance sur les packages
• Prise en charge des packages Python
• Sources en amont pour Maven
• Incorporer Azure Boards résultats de requête dans Wiki
• Permalinks pour les pages Wiki
• Notifications sur les pages wiki
• Extension Analytics n’est plus nécessaire pour utiliser Analytics

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

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

---

Général

Thème foncé

Le thème sombre a été une fonctionnalité populaire sur Azure DevOps Services et il est maintenant disponible dans Azure DevOps Server. Vous pouvez activer le thème sombre en sélectionnant Thème dans le menu sous votre avatar en haut à droite de chaque page.

Boards

Nouveau processus de base

Historiquement, Agile a été le processus par défaut pour les nouveaux projets, offrant un ensemble robuste et flexible de types et d’états d’éléments de travail pour s’adapter à diverses méthodes de livraison de projet. Pour certaines équipes, qui sont plus familiarisées avec d’autres outils ou qui sont en croissance et souhaitent adopter un ensemble d’outils plus puissant, veulent commencer rapidement à utiliser la terminologie qu’elles connaissent mieux.

Le nouveau processus de base fournit trois types d’éléments de travail (Epics, Issues et Tasks) pour planifier et suivre votre travail. Nous vous recommandons d’utiliser Problèmes pour suivre des éléments tels que les récits utilisateur, les bogues et les fonctionnalités tout en utilisant Epics pour regrouper les problèmes en unités de travail plus importantes. À mesure que vous progressez sur votre travail, déplacez des éléments le long d’un flux de travail d’état simple à faire, à faire et à faire.

Consultez la documentation sur le suivi des problèmes et des tâches pour vous aider à démarrer avec votre nouveau projet.

Ordre des valeurs d’état sur le formulaire élément de travail

Auparavant, la valeur d’état du formulaire d’élément de travail était triée par ordre alphabétique. Avec cette mise à jour, nous avons modifié la façon dont les valeurs d’état sont ordonnées pour qu’elles correspondent à l’ordre du flux de travail dans les paramètres de processus. Vous pouvez également modifier l’ordre des états de chaque catégorie dans les paramètres de personnalisation d’état.

L’activation des fonctionnalités n’est plus disponible

Les clients devront mettre à jour manuellement le code XML de chaque projet afin d’activer les nouvelles fonctionnalités après la mise à niveau de leur collection.

Reportez-vous à la documentation pour savoir comment activer des fonctionnalités spécifiques.

Organiser les documents de référence avec des pièces jointes d’éléments de travail plus riches

L’attachement de fichiers à des éléments de travail vous permet, à vous et à votre équipe, de centraliser les documents de référence afin qu’ils soient toujours proches quand vous en avez besoin. Il est désormais plus facile d’ajouter une nouvelle pièce jointe en faisant simplement glisser et déposer le fichier n’importe où dans le formulaire d’élément de travail. Vous pouvez continuer à afficher les pièces jointes sous forme de liste ou basculer en mode grille pour afficher un aperçu miniature. Double-cliquez sur le fichier pour ouvrir une préversion et parcourez-les pour trouver rapidement les informations dont vous avez besoin.

de

Partager le tableau de votre équipe à l’aide d’un badge

Le FICHIER README du dépôt est souvent la maison vers laquelle votre équipe de projet se tourne pour obtenir des informations sur la façon de contribuer et d’utiliser votre solution. À présent, comme vous le pouvez avec une status de build ou de déploiement dans Azure Pipelines, vous pouvez ajouter à votre fichier README un badge pour le tableau de votre équipe dans Azure Boards. Vous pouvez configurer le badge pour afficher uniquement les colonnes en cours ou toutes les colonnes, et même rendre le badge visible publiquement si votre projet est open source.

Si votre FICHIER README est basé sur Markdown, vous pouvez simplement copier l’exemple Markdown à partir de la page des paramètres du badge status et le coller dans votre fichier.

Requête pour le travail relatif au début de la journée, de la semaine, du mois ou de l’année

Bien que les équipes se concentrent souvent sur le travail dans le contexte de ce qui sera à venir ou sur la base d’itérations de sprint, il est souvent intéressant de regarder le travail en arrière à travers le prisme du calendrier pour signaler tout le travail qui s’est produit le mois dernier ou au cours du premier trimestre de l’année. Vous pouvez maintenant utiliser le nouvel ensemble de macros @StartOf suivants, ainsi que n’importe quel champ basé sur la date, pour effectuer une requête en fonction du début du jour, de la semaine, du mois ou de l’année :

• @StartOfYear
• @StartOfMonth
• @StartOfWeek
• @StartOfDay

Chacune de ces macros accepte également une nouvelle chaîne de modificateur qui vous permet de déplacer les données par différentes unités de date. Par exemple, vous pouvez écrire une requête pour rechercher tous les éléments de travail terminés au cours du premier trimestre de cette année en interrogeant sur Date >de changement d’état = @StartOfYear et Date <de changement d’état = @StartOfYear(« +3M »). Pour plus d’informations, consultez la documentation sur les macros de requête .

Modifier et supprimer des commentaires de discussion

Nous sommes ravis d’annoncer la disponibilité d’une fonctionnalité Developer Community hautement votée, la modification et la suppression des commentaires dans la discussion de votre élément de travail dans Azure Boards. Pour modifier votre commentaire, pointez simplement sur n’importe quel commentaire que vous possédez et vous verrez deux nouveaux boutons. Si vous cliquez sur l’icône de crayon, vous entrez en mode édition et pouvez simplement apporter vos modifications et appuyer sur le bouton « Mettre à jour » pour enregistrer vos modifications.

Lorsque vous cliquez sur le menu de dépassement de capacité, l’option permettant de supprimer votre commentaire s’affiche. Une fois que vous avez cliqué sur ce bouton, vous serez à nouveau invité à confirmer que vous souhaitez supprimer ce commentaire, et le commentaire sera supprimé.

Vous aurez une trace complète de tous les commentaires modifiés et supprimés sous l’onglet Historique du formulaire d’élément de travail. Vous verrez également que nous avons mis à jour l’interface utilisateur de notre expérience de discussion pour la rendre plus moderne et interactive. Nous avons ajouté des bulles autour des commentaires pour qu’il soit plus clair où les commentaires des individus commencent et se terminent.

Exporter les résultats de la requête dans un fichier CSV

Vous pouvez maintenant exporter les résultats de la requête directement dans un fichier de format CSV à partir du web.

Accédez à Azure Boards éléments de travail directement à partir des mentions dans n’importe quel commentaire GitHub

À présent, lorsque vous mention un élément de travail dans le commentaire d’un problème, d’une demande de tirage ou d’une validation dans GitHub à l’aide de la AB#{work item ID} syntaxe, ces mentions deviennent des liens hypertexte sur lesquels vous pouvez cliquer pour accéder directement à l’élément de travail mentionné.

Cela ne crée pas un lien formel qui encombre l’élément de travail dans Azure Boards pour chaque conversation associée, mais donne à votre équipe un moyen de fournir un peu plus d’informations sur les éléments de travail tout en discutant du code ou d’un problème signalé par le client. Pour plus d’informations, consultez la documentation d’intégration de GitHub Azure Boards.

Accepter et exécuter des problèmes dans GitHub lors de la planification dans Azure Boards

Vous pouvez maintenant lier des éléments de travail dans Azure Boards avec des problèmes connexes dans GitHub. Avec ce nouveau type de liaison, plusieurs autres scénarios sont désormais possibles. Si votre équipe souhaite continuer à accepter les rapports de bogues des utilisateurs, par exemple, en tant que problèmes au sein de GitHub, mais qu’il s’agit de lier et d’organiser le travail de l’équipe dans Azure Boards, vous pouvez maintenant le faire.

La même syntaxe mention que celle utilisée par votre équipe pour les validations et les demandes de tirage s’applique toujours et, bien sûr, vous pouvez lier manuellement dans Azure Boards avec l’URL du problème. Pour plus d’informations, consultez la documentation gitHub & Azure Boards.

Afficher rapidement l’activité GitHub liée à partir du tableau Kanban

Lorsque vous examinez le tableau Kanban vous-même ou en équipe, vous avez souvent des questions telles que « cet élément a encore commencé le développement ? » ou « cet élément est-il encore en révision ? » Avec les nouvelles annotations GitHub sur le tableau Kanban, vous pouvez maintenant avoir une idée rapide de l’emplacement d’un élément et accéder directement à la validation GitHub, à la demande de tirage ou au problème pour plus de détails. Consultez la documentation Personnaliser les cartes pour plus d’informations sur cette opération et les autres annotations pour les tâches et les tests.

Repos

Brouillon des demandes de tirage (pull request)

Afin d’empêcher les demandes de tirage d’être effectuées avant qu’elles ne soient prêtes et de faciliter la création de travaux en cours qui n’impliquent peut-être pas tout le monde, nous prenons désormais en charge les brouillons de demandes de tirage.

Vous pouvez créer des brouillons de demandes de tirage en sélectionnant Créer en tant que brouillon dans la liste déroulante Créer lors de la création d’une demande de tirage.

Une fois que vous avez créé un brouillon de demande de tirage, vous voyez un badge indiquant son status en regard du titre.

Les brouillons de demandes de tirage n’incluent pas de réviseurs ou d’exécution de builds par défaut, mais vous permettent d’ajouter manuellement des réviseurs et d’exécuter des builds. Pour promouvoir la demande de tirage en une demande de tirage normale, cliquez simplement sur le bouton Publier dans la page de détails de la demande de tirage.

Réexécuter la build expirée pour les demandes de tirage à la saisie automatique

Azure Repos met désormais automatiquement en file d’attente les builds expirées qui ont été déclenchées par une stratégie de demande de tirage. Cela s’applique aux demandes de tirage qui ont passé toutes les autres stratégies et qui sont définies sur la saisie semi-automatique.

Auparavant, lorsque les demandes de tirage avaient des stratégies telles que les réviseurs requis, le processus d’approbation pouvait prendre trop de temps et une build associée pouvait expirer avant qu’un réviseur approuve la demande de tirage. Si la demande de tirage a été définie pour se terminer automatiquement, elle reste bloquée jusqu’à ce qu’un utilisateur ait mis manuellement en file d’attente la build expirée. Avec cette modification, la build est mise en file d’attente automatiquement afin que la demande de tirage puisse se terminer automatiquement après une génération réussie.

Notes

Cette automatisation ne met en file d’attente que jusqu’à cinq builds expirées par demande de tirage et ne tente de mettre en file d’attente chaque build qu’une seule fois.

Afficher uniquement le fichier gauche ou droit dans une demande de tirage

Aujourd’hui, lors de l’affichage des modifications de fichier dans une demande de tirage, vous pouvez utiliser un mode diff côte à côte ou inline diff. Nous avons reçu des commentaires indiquant que beaucoup d’entre vous souhaitaient simplement voir le fichier d’origine ou le fichier modifié, sans les comparer, nous avons donc ajouté une nouvelle option qui vous permettra d’afficher le fichier gauche ou le fichier droit individuellement.

Nouveaux types de fusion pour effectuer des demandes de tirage

Vous disposez maintenant d’autres options lors de la fusion des modifications d’une demande de tirage vers la branche cible. Nous avons ajouté la prise en charge de deux de nos fonctionnalités les plus demandées sur le Developer Community : fusion rapide et fusion semi-linéaire (également appelée « Rebase et fusion »).

Vous voyez maintenant ces nouvelles options disponibles dans la boîte de dialogue Demande de tirage complète :

La page d’administration de stratégie mise à jour permet aux administrateurs de contrôler les stratégies de fusion autorisées sur une branche ou un dossier de branches.

Notes

Les stratégies existantes sont toujours appliquées. Par exemple, si votre branche a actuellement une stratégie « squashing fusion uniquement » en place, vous devrez modifier cette stratégie afin d’utiliser les nouvelles stratégies de fusion.

Il existe quelques situations dans lesquelles le rebasage pendant l’achèvement de la demande de tirage n’est pas possible :

• Si une stratégie sur la branche cible interdit l’utilisation de stratégies de rebase, vous aurez besoin de l’autorisation « Remplacer les stratégies de branche ».
• Si la branche source de la demande de tirage comporte des stratégies, vous ne pourrez pas la rebaser. Le rebasing modifie la branche source sans passer par le processus d’approbation de stratégie.
• Si vous avez utilisé l’extension de conflit de fusion pour résoudre les conflits de fusion. Les résolutions de conflit appliquées à une fusion à trois sont rarement réussies (voire valides) lors de la rebasing de tous les commits dans une demande de tirage un par un.

Dans tous ces cas, vous avez toujours la possibilité de rebaser votre branche localement et d’effectuer un envoi push vers le serveur, ou d’squashing-fusion de vos modifications lors de la fin de la demande de tirage.

Filtrer par branche cible dans les demandes de tirage (PRs)

Les demandes de tirage permettent à votre équipe d’examiner le code et de fournir des commentaires sur les modifications avant de les fusionner dans la branche main. Ils sont devenus un élément important des workflows de nombreuses équipes, car vous pouvez parcourir les modifications proposées, laisser des commentaires et voter pour approuver ou rejeter les modifications de code.

Pour faciliter la recherche de vos demandes de tirage, nous avons ajouté une option de filtrage pour vous permettre de rechercher des demandes de tirage à l’aide de la branche cible.

Vous pouvez également utiliser le filtrage de branche cible pour personnaliser l’affichage des demandes de tirage dans l’onglet Mine .

Autoriser les extensions à ajouter une mise en surbrillance et une saisie semi-automatique de syntaxe

Actuellement, nous publions la mise en surbrillance de syntaxe pour un sous-ensemble de langages pris en charge par l’éditeur Monaco. Toutefois, beaucoup d’entre vous souhaitent créer leur propre mise en surbrillance de syntaxe pour les langages que nous ne prenons pas en charge.

Avec cette mise à jour, nous avons ajouté un point d’extensibilité qui permet aux extensions d’ajouter la mise en surbrillance de syntaxe et la saisie semi-automatique aux vues de l’explorateur de fichiers et des demandes de tirage.

Vous trouverez un exemple d’extension illustrant cette fonctionnalité ici.

En outre, nous avons ajouté la prise en charge de la mise en surbrillance de la syntaxe du langage Kusto .

Point d’extension de création de référentiel

Nous avons ajouté un point d’extension pour vous permettre d’ajouter de nouveaux éléments au sélecteur de référentiel. Ce point d’extension vous permet d’ajouter des actions personnalisées (redirections, fenêtres contextuelles, etc.) au menu du sélecteur de référentiel, ce qui permet d’activer des flux comme d’autres scénarios de création de référentiels.

Prise en charge améliorée de l’encodage

Auparavant, la modification et l’enregistrement de fichiers sur le web ne s’enregistraient qu’en tant qu’encodage UTF-8 et nous ne vous avons pas demandé quand l’encodage du fichier a changé. À présent, nous allons vous donner un avertissement lorsque vous essayez d’enregistrer un fichier qui n’est pas encodé en UTF via le web (qui prend uniquement en charge l’encodage UTF). En outre, nous avons ajouté la prise en charge de l’encodage UTF-16 et UTF-32 via le point de terminaison push web. Cela signifie que nous allons conserver le type d’encodage afin que vous n’ayez pas à les réécrire en UTF-8.

La capture d’écran suivante montre et l’exemple de boîte de dialogue que vous verrez lorsque vous introduirez des modifications d’encodage par un push web.

Accéder à la prise en charge des commandes dans Azure Repos

Go est un langage de programmation open source, également appelé Golang. Dans Go, vous pouvez utiliser la commande get pour télécharger et installer des packages et des dépendances. Avec cette mise à jour, nous avons ajouté la prise en charge au go get sein d’un dépôt Azure DevOps. Avec go get, vous pourrez télécharger des packages avec leurs dépendances nommées par les chemins d’importation. Vous pouvez utiliser le import mot clé pour spécifier le chemin d’importation.

Pipelines

Éditeur web avec IntelliSense pour les pipelines YAML

Si vous utilisez YAML pour définir vos pipelines, vous pouvez désormais tirer parti des nouvelles fonctionnalités de l’éditeur introduites avec cette version. Que vous créiez un pipeline YAML ou que vous modifiez un pipeline YAML existant, vous pourrez modifier le fichier YAML dans l’éditeur web de pipeline. Utilisez Ctrl+Espace pour la prise en charge d’IntelliSense lorsque vous modifiez le fichier YAML. Vous verrez les erreurs de syntaxe mises en évidence et obtenir de l’aide sur la correction de ces erreurs.

Assistant de tâches pour modifier des fichiers YAML

Nous continuons à recevoir de nombreux commentaires demandant de faciliter la modification des fichiers YAML pour les pipelines. Nous ajoutons donc une tâche assistant à l’éditeur YAML. Avec cela, vous aurez la même expérience familière pour l’ajout d’une nouvelle tâche à un fichier YAML que dans l’éditeur classique. Cette nouvelle assistant prend en charge la plupart des types d’entrée de tâches courants, tels que les listes de choix et les connexions de service. Pour utiliser la nouvelle assistant de tâche, sélectionnez Modifier sur un pipeline YAML, puis sélectionnez le assistant tâche.

Déclencher des pipelines YAML avec des balises

Les pipelines YAML peuvent être déclenchés lorsque des balises sont ajoutées à un commit. Cela est utile pour les équipes dont les flux de travail incluent des balises. Par instance, vous pouvez lancer un processus lorsqu’un commit est étiqueté comme « dernier bon connu ».

Vous pouvez spécifier les balises à inclure et à exclure. Par exemple :

trigger:
  tags:
    include:
    - releases/*
    exclude:
    - releases/old*

Déclarer des ressources de conteneur inline

Auparavant, nous vous demandions de déclarer vos ressources de conteneur dans des pipelines YAML, puis de les référencer par nom. Nous proposons maintenant une syntaxe inline pour les cas où vous n’allez pas faire référence au conteneur plusieurs fois.

jobs:
- job: my-container-job
  container:
    image: microsoft/dotnet:latest

Définition de l’annulation automatique d’un pipeline existant lorsqu’une demande de tirage est mise à jour

Par défaut, les pipelines déclenchés par des demandes de tirage (PRs) sont annulés si un nouveau commit est envoyé à la même demande de tirage. Cela est souhaitable dans la plupart des cas, car vous ne souhaitez généralement pas continuer à exécuter un pipeline sur du code obsolète. Si vous ne souhaitez pas ce comportement, vous pouvez ajouter autoCancel : false à votre déclencheur de demande de tirage.

pr:
  branches:
    include:
    - main
    - releases/*
  autoCancel: false

Choisir le répertoire du code extrait dans les pipelines YAML

Auparavant, nous avons extrait les dépôts dans le s répertoire sous $(Agent.BuildDirectory). Vous pouvez maintenant choisir le répertoire dans lequel votre dépôt Git sera extrait pour une utilisation avec des pipelines YAML.

Utilisez le path mot clé activé checkout et vous aurez le contrôle de la structure des dossiers. Vous trouverez ci-dessous un exemple de code YAML que vous pouvez utiliser pour spécifier un répertoire.

steps:
- checkout: self
  path: my-great-repo

Dans cet exemple, votre code est extrait dans le répertoire de l’espace my-great-repo de travail de l’agent. Si vous ne spécifiez pas de chemin d’accès, votre dépôt continuera d’être extrait dans un répertoire appelé s.

Nouvelles tâches Azure App Service optimisées pour YAML

Nous prenons désormais en charge quatre nouvelles tâches qui fournissent un moyen simple mais puissant de déployer Azure App Services en ayantuxuxux pour les développeurs modernes. Ces tâches ont une syntaxe YAML optimisée qui permet de créer des déploiements simples et intuitifs sur Azure AppServices, y compris WebApps, FunctionApps, WebApps pour les conteneurs et FunctionApp pour les conteneurs sur les plateformes Windows et Linux.

Nous prenons également en charge une nouvelle tâche utilitaire pour la transformation de fichiers et la substitution de variables pour les formats XML et JSON.

Modifications apportées aux autorisations par défaut pour les nouveaux projets

Jusqu’à présent, les contributeurs de projet ne pouvaient pas créer de pipelines, sauf s’ils recevaient explicitement l’autorisation « Créer une définition de build ». Pour les nouveaux projets, les membres de votre équipe peuvent facilement créer et mettre à jour des pipelines. Ce changement permettra de réduire les frictions pour les nouveaux clients qui sont intégrés à Azure Pipelines. Vous pouvez toujours mettre à jour les autorisations par défaut sur le groupe Contributeurs et restreindre leur accès.

Gérer les versions de GitHub à l’aide de pipelines

Les versions de GitHub sont un excellent moyen d’empaqueter et de fournir des logiciels aux utilisateurs. Nous sommes heureux d’annoncer que vous pouvez maintenant l’automatiser à l’aide de la tâche de mise en production GitHub dans Azure Pipelines. À l’aide de la tâche, vous pouvez créer une nouvelle version, modifier des versions de brouillon/publiées existantes ou en ignorer des versions plus anciennes. Il prend en charge des fonctionnalités telles que le chargement de plusieurs ressources, le marquage d’une version comme préversion, l’enregistrement d’une version en tant que brouillon et bien plus encore. Cette tâche vous aide également à créer des notes de publication. Il peut également calculer automatiquement les modifications (validations et problèmes associés) qui ont été apportées dans cette version et les ajouter aux notes de publication dans un format convivial.

Voici le YAML simple pour la tâche :

task: GithubRelease@0 
displayName: 'Create GitHub Release'      
inputs:
  githubConnection: zenithworks
  repositoryName: zenithworks/pipelines-java
  assets: $(build.artifactstagingdirectory)/*.jar

Exemple de version GitHub créée à l’aide de cette tâche :

Liens vers des lignes spécifiques dans un journal de génération

Vous pouvez maintenant partager un lien vers des lignes spécifiques dans le journal de génération. Cela vous aidera lors de la collaboration avec d’autres membres de l’équipe pour diagnostiquer les échecs de build. Sélectionnez simplement les lignes d’un journal dans la vue des résultats pour obtenir une icône de lien.

Améliorations apportées à l’autorisation des ressources

Nous devions assurer la sécurité des ressources protégées (par exemple, les connexions de service, les groupes de variables, les pools d’agents, les fichiers sécurisés) lorsqu’elles sont référencées dans un fichier YAML. En même temps, nous voulions faciliter la configuration et l’utilisation de pipelines qui utilisent ces types de ressources pour des scénarios hors production. Précédemment, nous avons ajouté un paramètre pour marquer une ressource comme « autorisée à être utilisée dans tous les pipelines ».

Avec cette mise à jour, nous vous permet de résoudre plus facilement un problème d’autorisation de ressource, même si vous n’avez pas marqué une ressource en tant que telle. Dans la nouvelle expérience, lorsqu’une build échoue en raison d’une erreur d’autorisation de ressource, vous verrez une option permettant d’autoriser explicitement l’utilisation de ces ressources dans le pipeline, puis de continuer. Les membres de l’équipe disposant des autorisations nécessaires pour autoriser les ressources pourront effectuer cette action directement à partir d’une build ayant échoué.

Nouveaux points de contribution d’extension sous l’onglet Test des pipelines

Nous avons continué à rendre l’infrastructure d’extension plus puissante en ajoutant deux nouveaux points de contribution dans l’onglet Résultats des tests dans Pipelines. Cela permettra aux extensions de la Place de marché de fournir des expériences de création de rapports plus personnalisées et d’ajouter davantage d’interactivité.

Les deux points de contribution sont les suivants :

1. Bouton Action personnalisée dans la barre d’outils

   Parfois, vous pouvez effectuer une action telle que la mise à jour des données d’une API ou l’exécution d’outils personnalisés à l’aide des métadonnées de vos résultats de test. Avec ce point de contribution, vous pouvez créer des extensions qui utilisent le contexte immédiat du résultat de test sélectionné pour ajouter une action personnalisée au bouton *Action personnalisée- .

   

2. Onglet Détails personnalisés dans le volet d’informations

   Vous pouvez avoir une grande variété de flux de travail de consommation de rapports de test et souhaiter voir différents points de données par rapport aux tests ayant échoué pour le débogage et l’analyse. À l’aide de ce point de contribution, votre équipe peut ajouter un nouvel onglet au volet d’informations qui apparaît lorsque vous sélectionnez la ligne de résultat de test dans la grille de données. Ce nouvel onglet peut afficher une vue avec du contenu statique ou des données dynamiques extraites à l’aide d’API internes ou externes.

Exécuter une seule fois l’agent

Si vous utilisez une infrastructure telle que Azure Container Instances pour exécuter des agents privés élastiques, vous souhaitez souvent que chaque agent n’accepte qu’un seul travail avant de partir. Jusqu’à présent, cela n’était pas facile, car vous deviez mettre fin à l’agent (éventuellement provoquer un échec) ou accepter le risque qu’un agent reçoive un autre travail avant de pouvoir l’arrêter. Avec cette mise à jour, nous avons ajouté l’indicateur --once à la configuration de l’agent. Lorsque vous configurez l’agent de cette façon, il n’accepte qu’un seul travail, puis s’arrête.

Mise à jour de l’interface utilisateur du pool d’agents

La page de gestion des pools d’agents dans les paramètres de projet a été mise à jour avec une nouvelle interface utilisateur. Vous pouvez désormais facilement voir tous les travaux en cours d’exécution dans un pool. En outre, vous pouvez découvrir pourquoi un travail n’est pas en cours d’exécution.

de

Déployer sur des cibles ayant échoué dans un groupe de déploiement

Par défaut, Azure Pipelines permet de réexécuter tous les travaux lorsque vous redéployez une exécution qui a échoué précédemment. À présent, vous pouvez remplacer ce comportement en configurant l’option de déploiement lors du déploiement. En sélectionnant l’option Tous les travaux et limiter les cibles ayant échoué dans un groupe de déploiement , la réexécutation exécute tous les travaux et ignore les déploiements vers les cibles déjà à jour.

Redéployer automatiquement en cas d’échec

Lorsqu’un déploiement sur une phase échoue, Azure Pipelines peut désormais redéployer automatiquement le dernier déploiement réussi. Vous pouvez configurer la phase pour déployer automatiquement la dernière version réussie en configurant le déclencheur de redéploiement automatique dans les conditions de post-déploiement. Nous prévoyons d’ajouter des événements et des actions déclenchés supplémentaires à la configuration de redéploiement automatique dans un sprint ultérieur. Pour plus d’informations , consultez la documentation groupes de déploiement.

Hook de service des annotations Grafana

Nous prenons désormais en charge un nouveau hook de service qui vous permet d’ajouter des annotations Grafana pour les événements De déploiement terminé à un tableau de bord Grafana. Cela vous permet de mettre en corrélation les déploiements avec les modifications apportées aux métriques d’application ou d’infrastructure qui sont visualisées dans un tableau de bord Grafana.

Interroger des tâches d’alertes Azure Monitor

La version précédente de la tâche Interroger Azure Monitors ne prend en charge l’interrogation des alertes que sur l’expérience de supervision classique. Avec cette nouvelle version de la tâche, vous pouvez interroger des alertes sur l’expérience de supervision unifiée récemment introduite par Azure Monitor.

Entrée inline du fichier de spécifications dans la tâche Déployer sur Kubernetes

Auparavant, la tâche de déploiement Kubernetes vous obligeait à fournir un chemin d’accès de fichier pour la configuration. Vous pouvez maintenant ajouter la configuration en ligne.

Tâche du programme d’installation de Docker CLI

Cette tâche permet l’installation de n’importe quelle version de Docker CLI sur les agents, comme spécifié par l’utilisateur.

Restaurer des pipelines de mise en production supprimés

La suppression des pipelines de mise en production inutilisés permet de conserver la liste des pipelines de mise en production propre, mais vous supprimez parfois quelque chose par erreur. Avec cette mise à jour, il est désormais possible de restaurer un pipeline de mise en production qui a été supprimé au cours des 30 derniers jours. Nous avons ajouté un nouvel onglet dans le volet gauche de la page Mises en production qui affiche la liste des pipelines de mise en production supprimés. Dans cette vue, vous pouvez restaurer un pipeline de mise en production supprimé en sélectionnant le pipeline dans la liste et en cliquant sur le bouton Restaurer .

Notifications en cas d’échec d’une demande de création de mise en production

Vous pouvez définir des notifications pour recevoir des e-mails à mesure que des modifications sont apportées à vos builds, à votre base de code et à d’autres opérations. Par exemple, vous pouvez définir une alerte pour recevoir une notification lorsqu’un élément de travail vous est affecté.

Avec cette mise à jour, nous avons ajouté un nouvel abonnement de notification à la catégorie Release . Cette notification vous envoie un e-mail en cas d’échec d’une demande de création de mise en production. Un exemple de scénario où cela peut être utile est lorsqu’une demande de création d’une mise en production échoue, car une version d’artefact n’est pas disponible. Pour savoir comment gérer vos notifications, consultez la documentation ici.

Planifier des mises en production sur la modification de la source ou du pipeline

Auparavant, lorsque vous aviez un déclencheur de mise en production planifiée, une mise en production était déclenchée même si aucune modification n’était détectée dans l’artefact amont ou dans la définition de mise en production. Une option a été ajoutée au panneau déclencheur Planifier la mise en production pour planifier les mises en production uniquement si la version de l’artefact ou la définition de mise en production a changé.

Point de contribution pour les variables dans la boîte de dialogue Créer une mise en production

Auparavant, les valeurs de variables nécessaires lors de la création de la version devaient être entrées par l’utilisateur sans assistance ni suggestion. Nous avons ajouté des points de contribution à la boîte de dialogue Créer une mise en production pour prendre en charge les extensions qui aideront à remplir la valeur d’une variable lors de la création de la version.

Publier sur Azure Service Bus files d’attente de session

Nous avons étendu la tâche de génération de travaux sans agent pour inclure la possibilité de publier des messages dans les files d’attente de session. Cette option a été ajoutée à la tâche Publier sur Azure Service Bus.

Nouvelle option d’abonnement Azure dans la connexion au service Kubernetes

Les connexions de service pour les builds et les mises en production vous permettent de vous connecter à des services externes et distants afin d’exécuter des tâches pour une build ou un déploiement. Vous pouvez définir et gérer une connexion de service à partir des paramètres Administration de votre projet.

Avec cette mise à jour, nous avons ajouté une option d’authentification au formulaire de connexion du service Kubernetes. Vous pouvez maintenant sélectionner Abonnement Azure pour authentifier votre connexion. Cela facilite le déploiement sur des espaces de noms spécifiques en configurant des connexions Kubernetes avec votre abonnement Azure et le nom de votre cluster.

Pour un cluster RBAC (Contrôle d’accès en fonction du rôle), les objets ServiceAccount et RoleBinding sont créés dans l’espace de noms choisi. L’objet RoleBinding limite les opérations du compte de service créé uniquement à l’espace de noms choisi. Pour un cluster RBAC désactivé, le compte de service créé dispose d’autorisations à l’échelle du cluster entre les espaces de noms.

Azure Container Registry dans la connexion au service Docker Registry

Vous pouvez maintenant créer une connexion de service de registre Docker à partir de la page des paramètres de votre projet. Pour créer la connexion, choisissez un registre de conteneurs Azure dans l’un des abonnements associés à votre identité Azure Active Directory (AAD). Toutes les tâches nécessitant des connexions de service à des registres de conteneurs, telles que Docker@2 et KubernetesManifest@0 , prennent en charge une méthode unique de spécification d’une connexion.

Rechercher par nom de dossier dans les définitions de version

Vous pouvez organiser vos définitions de mise en production en les stockant dans des dossiers. Auparavant, vous n’aviez pas la possibilité d’effectuer une recherche par dossier. Il était difficile de trouver une définition de mise en production spécifique si vous aviez créé un grand nombre de dossiers. Vous pouvez désormais rechercher par nom de dossier dans la définition de mise en production, ce qui vous permet de trouver plus facilement les définitions que vous recherchez.

Tâche du programme d’installation de l’outil Duffle dans le pipeline de build et de mise en production

Duffle est un outil en ligne de commande qui vous permet d’installer et de gérer des offres groupées d’applications natives cloud (CNAB). Avec les CNAB, vous pouvez regrouper, installer et gérer des applications natives conteneur et leurs services.

Dans cette mise à jour, nous avons ajouté une nouvelle tâche pour les pipelines de build et de mise en production qui vous permet d’installer une version spécifique de Duffle binary.

Tâche de manifeste Kubernetes

Nous avons ajouté une nouvelle tâche à nos pipelines de mise en production pour simplifier le processus de déploiement sur des clusters Kubernetes à l’aide de fichiers manifestes. Cette tâche offre les avantages suivants par rapport à l’utilisation du binaire kubectl dans les scripts :

• Substitution d’artefact : l’action de déploiement prend comme entrée une liste d’images conteneur qui peuvent être spécifiées avec leurs balises ou synthèses. Cela est remplacé dans la version autre que le modèle des fichiers manifestes avant de l’appliquer au cluster pour garantir que la version appropriée de l’image est extraite par les nœuds du cluster.

• Stabilité du manifeste : le déploiement status est vérifié pour les objets Kubernetes déployés pour incorporer des vérifications de stabilité lors du calcul de la tâche status comme réussite/échec.

• Annotations de traçabilité : les annotations sont ajoutées aux objets Kubernetes déployés pour superposer les informations de traçabilité sur l’origine des organization, du projet, du pipeline et de l’exécution.

• Bake manifest : l’action bake de la tâche permet de créer des graphiques Helm dans des fichiers manifeste Kubernetes afin qu’ils puissent être appliqués au cluster.

• Stratégie de déploiement : le choix d’une stratégie canary avec action de déploiement entraîne la création du pourcentage souhaité de charges de travail avec suffixes -baseline et -canary afin qu’elles puissent être comparées au cours d’une tâche avant d’utiliser ManualIntervention l’action de promotion/rejet de la tâche pour finaliser la version à conserver.

steps:
- task: KubernetesManifest@0
  name: bake
  displayName: Bake K8s manifests from Helm chart
  inputs:
    action: bake
    helmChart: charts/sample
    overrides: 'image.repository:nginx'

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

Mises à niveau vers la tâche Docker

Nous avons mis à niveau la tâche Docker pour simplifier l’expérience de création de pipeline. La commande buildAndPush peut désormais être utilisée pour générer plusieurs balises pour un référentiel de conteneurs spécifique et l’envoyer à plusieurs registres de conteneurs en une seule étape. La tâche peut utiliser des connexions de service de registre Docker pour la connexion aux registres de conteneurs. Les métadonnées de traçabilité relatives au dépôt source, à la validation et à la provenance de build sont ajoutées en tant qu’étiquettes aux images générées à l’aide de cette tâche.

steps:
- task: Docker@2
  displayName: Container registry login - ACR1 service connection
  inputs:
    command: login
    containerRegistry: acr1
- task: Docker@2
  displayName: Container registry login - ACR2 service connection
  inputs:
    command: login
    containerRegistry: acr2
- task: Docker@2
  displayName: Build and push images
  inputs:
    repository: test
    tags: |
      d1
      d2

Programme d'installation de l'outil Kubectl

Nous avons ajouté une nouvelle tâche qui vous permet d’installer une version spécifique du binaire Kubectl sur les agents. Les chaînes de version les plus récentes et semver telles que « v1.14.0 » sont acceptées en tant que valeurs valides pour l’entrée Kubectl Version Spec.

Améliorations apportées à l’intégration de ServiceNow

Une fonctionnalité clé de la collaboration inter-équipes consiste à permettre à chaque équipe d’utiliser un service de son choix et d’avoir une livraison efficace de bout en bout. Avec cette mise à jour, nous avons amélioré l’intégration de ServiceNow pour prendre en charge tous les types de modifications (normales, standard et d’urgence). En outre, vous pouvez maintenant spécifier la porte utilisée pour créer une demande de modification à l’aide d’un modèle existant, conformément au processus ITSM suivi dans votre organization. Enfin, vous pouvez également contrôler les mises en production en fonction des demandes de modification existantes. Cela vous permet d’adopter CD, sans avoir à modifier le processus recommandé par vos équipes informatiques.

Prise en charge de Red Hat Enterprise Linux 6

Avec cette mise à jour, nous avons ajouté la prise en charge de l’agent pour Red Hat Enterprise Linux 6. Vous pouvez maintenant configurer des agents ciblant la plateforme Red Hat Enterprise Linux 6 pour l’exécution des travaux de génération et de mise en production.

Prise en charge de Azure PowerShell module Az

Azure PowerShell fournit un ensemble d’applets de commande que vous pouvez utiliser pour gérer les ressources Azure à partir de la ligne de commande. En décembre dernier, le module Az Azure PowerShell est devenu disponible et est désormais le module prévu pour la gestion de vos ressources Azure.

Auparavant, nous ne prenions pas en charge le module Azure PowerShell Az dans nos agents hébergés. Avec la nouvelle Azure PowerShell tâche version 4.* dans les pipelines de build et de mise en production, nous avons ajouté la prise en charge du nouveau module Az pour toutes les plateformes. Azure PowerShell tâche version 3.* continue de prendre en charge le module AzureRM. Toutefois, pour suivre les derniers services et fonctionnalités Azure, nous vous recommandons de basculer vers la Azure PowerShell tâche version 4.* dès que possible.

Le module Az dispose d’un mode de compatibilité pour vous aider à utiliser des scripts existants pendant que vous les mettez à jour pour utiliser la nouvelle syntaxe. Pour activer la compatibilité pour le module Az, utilisez la Enable-AzureRmAlias commande . Les alias vous permettent d’utiliser les anciens noms d’applet de commande avec le module Az. Vous pouvez obtenir plus d’informations sur la migration du module Azure RM vers le module Az Azure PowerShell ici.

Notes

Vous devez installer le module Az sur votre ordinateur d’agent si vous utilisez des agents privés.

Pour plus d’informations sur le module Az Azure PowerShell, consultez la documentation ici.

Prise en charge de l’authentification Azure Active Directory (AD) pour Azure SQL tâche

La tâche de Azure SQL a été améliorée pour prendre en charge la connexion à une base de données à l’aide d’Azure AD (mot de passe & intégré) et d’un chaîne de connexion en plus de la prise en charge existante de l’authentification SQL Server.

Publier des artefacts de build avec des chemins de fichiers longs

Jusqu’à présent, une limitation empêchait le chargement d’artefacts de build avec des chemins de plus de 233 caractères. Cela peut vous empêcher de charger les résultats de la couverture du code à partir de builds Linux et macOS avec des chemins de fichiers plus longs que la limite. La limite a été mise à jour pour prendre en charge les chemins d’accès longs.

Ignorer l’intégration continue (CI) pour un commit

Vous pouvez maintenant indiquer à Azure Pipelines d’ignorer un commit et d’ignorer l’exécution d’un pipeline que la validation se déclencherait normalement. Incluez [skip ci] simplement dans le message de validation du HEAD commit et Azure Pipelines ignore CI. Vous pouvez également utiliser l’une des variantes répertoriées ci-dessous. Cela est pris en charge pour les commits sur Azure Repos Git et GitHub Enterprise Server.

• [skip ci] ou [ci skip]
• skip-checks: true ou skip-checks:true
• [skip azurepipelines] ou [azurepipelines skip]
• [skip azpipelines] ou [azpipelines skip]
• [skip azp] ou [azp skip]
• ***NO_CI***

Test Plans

Widget Tendance des résultats de test (Avancé)

Le widget Tendance des résultats de test (Avancé) offre une visibilité en quasi temps réel sur vos données de test pour plusieurs builds et versions. Le widget Tendance des résultats de test (Avancé) affiche une tendance de vos résultats de test pour vos pipelines ou entre pipelines. Vous pouvez l’utiliser pour suivre le nombre quotidien de tests, le taux de réussite et la durée des tests. Le suivi de la qualité des tests au fil du temps et l’amélioration de la documentation des tests sont essentiels au maintien d’un pipeline DevOps sain.

Le widget Tendance des résultats de test (Avancé) vous aide à trouver des valeurs aberrantes dans vos résultats de test et à répondre à des questions telles que : l’exécution des tests prend-elle plus de temps que d’habitude ? Quel fichier de test ou pipeline affecte mon taux de réussite global ? Quels sont mes tests de longue durée ?

Pour vous aider à répondre à ces questions, le widget fournit les fonctionnalités suivantes :

• Affiche une tendance du taux de réussite et du nombre de résultats des tests ou de la durée du test
• Présente les résultats des tests basés sur plusieurs pipelines de build ou pipelines de mise en production
• Utilise des options de graphiques combinées pour afficher deux métriques sur la même tendance
• Filtre le nombre de tests au fil du temps par résultat du test
• Filtre tous vos résultats de test par branche ou test
• Empile vos métriques par attributs de test tels que Priority ou Environment
• Regrouper vos données sur des fichiers de test, un propriétaire ou des pipelines

Le widget est hautement configurable, ce qui vous permet de l’utiliser pour un large éventail de scénarios.

Partager les résultats de la série de tests via l’URL

Vous pouvez configurer des tests automatisés pour qu’ils s’exécutent dans le cadre d’une build ou d’une version. Les résultats des tests publiés peuvent être affichés sous l’onglet Tests dans le résumé de la build ou de la mise en production. Avec cette mise à jour, nous avons ajouté une fonctionnalité Copier l’URL des résultats afin que vous puissiez partager les résultats d’une seule série de tests avec d’autres membres de votre équipe.

Les niveaux de partage sont les suivants :

• Niveau d’exécution
• Niveau de résultat
• Onglet individuel sélectionné dans la série de tests
• Le partage est également compatible avec tous les onglets d’extension configurés

Lorsque vous partagez l’URL, les visionneuses voient les résultats de la série de tests en mode plein écran.

Artifacts

Packages NuGet avec numéros de version SemVer 2.0.0

Auparavant, Azure Artifacts ne prenait pas en charge les packages NuGet avec les numéros de version SemVer 2.0.0 (en général, les numéros de version qui contiennent la partie de métadonnées de build de la version, qui est indiquée par un +). Vous pouvez désormais enregistrer des packages à partir de nuget.org qui contiennent des métadonnées de build et envoyer (push) vos propres packages avec des métadonnées de build. Conformément à la spécification SemVer et à la stratégie NuGet.org, les métadonnées de build ne peuvent pas être utilisées pour commander des packages. Par conséquent, vous ne pouvez pas publier à la fois 1.0.0+build1 et 1.0.0+build2 sur Azure Artifacts (ou nuget.org), car ces versions seront considérées comme équivalentes et donc soumises aux contraintes d’immuabilité.

Informations de provenance sur les packages

Avec cette mise à jour, nous avons un peu facilité la compréhension de la provenance de vos packages : qui ou ce qui les a publiés et de quelle validation de code source ils proviennent. Ces informations sont renseignées automatiquement pour tous les packages publiés à l’aide des tâches NuGet, npm, Maven et Twine Authenticate (pour Python) dans Azure Pipelines.

Statistiques d’utilisation des packages

Jusqu’à présent, Azure Artifacts ne fournissait pas de moyen d’évaluer l’utilisation ou la popularité des packages. Avec cette mise à jour, nous avons ajouté un nombre de téléchargements et d’utilisateurs à la liste des packages et aux pages de détails du package. Vous pouvez voir les statistiques sur le côté droit de l’une ou l’autre page.

Prise en charge des packages Python

Azure Artifacts peut désormais héberger des packages Python : les packages que vous produisez vous-même et amont packages enregistrés à partir du PyPI public. Pour plus d’informations, consultez le billet de blog d’annonce et la documentation.

Vous pouvez maintenant héberger tous vos packages NuGet, npm, Maven et Python dans le même flux.

Sources en amont pour Maven

Les sources en amont sont désormais disponibles pour les flux Maven. Cela inclut le référentiel Maven Central principal et les flux Azure Artifacts. Pour ajouter Maven upstreams à un flux existant, accédez à Paramètres du flux, sélectionnez le tableau croisé dynamique sources en amont, puis sélectionnez Ajouter amont source.

Prise en charge du proxy pour les tâches liées aux artefacts

Jusqu’à présent, de nombreuses tâches de génération liées aux artefacts ne fournissaient pas une prise en charge complète de l’infrastructure proxy d’Azure Pipelines, ce qui entraînait des difficultés à utiliser les tâches des agents locaux. Avec cette mise à jour, nous avons ajouté la prise en charge des proxys aux tâches suivantes :

• Npm@1 (« npm » dans le concepteur)
• NuGetCommand@2 (« NuGet » dans le concepteur) : commandes de restauration et d’envoi (push) uniquement
• DotNetCoreCLI@2 (« .NET Core » dans le concepteur) : restauration et commandes push nuget uniquement
• NpmAuthenticate@0, PipAuthenticate@0 et TwineAuthenticate@0 (« [type] Authentifier » dans le concepteur) : ces tâches prennent en charge les proxys lors de l’acquisition de jetons d’authentification, mais il est toujours nécessaire de configurer les tâches/scripts/outils suivants pour utiliser également le proxy. Autrement dit, ces tâches ne configurent pas le proxy pour l’outil sous-jacent (npm, pip, twine).
• NuGetToolInstaller@0, NodeTool@0 DotNetCoreInstaller@0 ('[type] Installer' dans le concepteur)

Tous les types de packages Artifacts pris en charge dans les versions

Jusqu’à présent, seuls les packages NuGet étaient pris en charge dans le type d’artefact Azure Artifacts dans les versions pipelines. Avec cette mise à jour, tous les types de packages Azure Artifacts (Maven, npm et Python) sont pris en charge.

Affichages d’artefacts pris en charge dans les versions

Auparavant, le type d’artefact Azure Artifacts pouvait uniquement se déclencher lorsque de nouvelles versions de package étaient publiées dans le flux. Maintenant, nous avons également ajouté la prise en charge des vues, afin que vous puissiez déclencher des mises en production lorsque les packages déjà présents dans le flux sont promus en vue.

Les stratégies de rétention peuvent ignorer les packages téléchargés récemment

Jusqu’à présent, les flux Azure Artifacts offraient des stratégies de rétention de base qui commençaient à supprimer les anciennes versions de package lorsqu’un « nombre maximal de versions par package » était atteint. Avec cette mise à jour, nous avons ajouté la possibilité d’ignorer les packages récemment téléchargés lors de cette propre. Pour l’activer, modifiez votre flux et case activée la case Ignorer les packages téléchargés récemment.

Déléguer qui peut gérer les flux

Dans Azure Artifacts, les administrateurs de collection de projets (PCA) ont toujours été en mesure d’administrer tous les flux dans un serveur Azure DevOps. Avec cette mise à jour, les PCA peuvent également donner cette possibilité à d’autres utilisateurs et groupes, déléguant ainsi la possibilité de gérer n’importe quel flux.

Wiki

Modèles Markdown pour les formules et les vidéos

Il n’est plus nécessaire de mémoriser la syntaxe Markdown pour ajouter des formules, desvidéos et des balises YAML lors de la modification d’un Wiki. Vous pouvez maintenant cliquer sur le menu contextuel dans la barre d’outils et sélectionner l’option de votre choix.

Incorporer Azure Boards résultats de requête dans wiki

Vous pouvez maintenant incorporer Azure Boards résultats de requête dans une page wiki sous la forme d’une table. L’image ci-dessous montre un exemple de page wiki avec une liste de toutes les fonctionnalités publiées et de tous les bogues actifs dans le sprint actuel incorporés dans le wiki. Le contenu affiché dans la page utilise une requête d’élément de travail existante. Avec cette nouvelle fonctionnalité, vous pouvez créer du contenu dynamique et ne pas avoir à vous soucier de la mise à jour manuelle de la page wiki.

Les résultats de la requête peuvent être ajoutés en deux étapes :

1. Cliquez sur le bouton « Résultats de la requête » dans la barre d’outils Modifier.

2. Sélectionnez la requête requise, puis cliquez sur le bouton « Insérer ».

Les résultats de la requête peuvent désormais être affichés sous la forme d’une table après avoir enregistré la page.

Police monospaced pour l’éditeur Wiki Markdown

Avec l’introduction des polices monospaced pour l’éditeur Wiki Markdown, la lisibilité n’est plus un défi. La source Markdown semble propre et facile à lire. Cette fonctionnalité a été hiérarchisée en fonction de ce ticket de suggestion.

Permalinks pour les pages Wiki

Jusqu’à présent, les liens de page Wiki partagés étaient rompus si la page liée était renommée ou déplacée. Nous avons maintenant introduit des liens permanents en ajoutant des ID de page à l’URL. Cela garantit que les liens que vous partagez restent intacts à mesure que le wiki change au fil du temps.

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

Afficher les status d’éléments de travail dans les pages Wiki

Dans cette mise à jour, nous avons amélioré les mentions d’éléments de travail dans les pages Wiki en ajoutant la status de l’élément de travail à la page, ainsi que son ID et son titre.

Les références d’éléments de travail dans les commentaires de demande de tirage et les discussions sur les tableaux affichent également les status.

@mention utilisateurs et groupes

Vous pouvez désormais @mention utiliser des utilisateurs et des groupes dans une page wiki. Cela enrichit les documents tels que la page de contact d’une équipe, les documents d’aide et les documents de connaissances. L’image ci-dessous est un exemple montrant une rétrospective de sprint avec les tâches et la personne responsable.

@mention utilisateurs et groupes. » />

En outre, vous pouvez également sélectionner un utilisateur ou un groupe dans la suggestion automatique en tapant « @ » dans la page de modification wiki. La personne mentionnée sera également avertie par courrier.

@mention. » />

Enfin, vous pouvez également cliquer sur l’utilisateur @mentioned pour afficher les informations de profil carte. Cette fonctionnalité a été hiérarchisée en fonction de cette suggestion de fonctionnalité.

Notifications sur les pages wiki

Jusqu’à présent, vous ne disposiez pas d’un moyen de savoir quand le contenu d’une page wiki a été modifié. Vous pouvez désormais suivre les pages wiki pour recevoir une notification par e-mail lorsque la page est modifiée, supprimée ou renommée. Pour suivre les modifications apportées à un wiki, sélectionnez le bouton Suivre dans la page wiki.

Cette fonctionnalité a été hiérarchisée en fonction de ce ticket de suggestion. Pour en savoir plus, consultez notre documentation ici.

Prise en charge des balises HTML

Maintenant, vous pouvez créer du contenu plus riche dans wiki à l’aide de balises HTML. Découvrez ce que vous pouvez faire avec les balises HTML ci-dessous.

1. Vous pouvez maintenant créer des sections réductibles à l’intérieur de vos pages wiki à l’aide des balises de détails et de résumé . Vous pouvez ajouter l’attribut open pour conserver les détails développés par défaut.

   

   Pour plus d’informations sur la balise de détails , consultez la documentation ici.

   Cela a été hiérarchisé en fonction de ce ticket de suggestion.

   Notes

   Cette balise n’est pas prise en charge dans les navigateurs Edge et Internet Explorer.

Amélioration de la création et de la modification des tables

Jusqu’à présent, la création et la modification de tables dans un wiki étaient difficiles. Nous avons apporté des modifications pour faciliter l’ajout et la gestion des tables dans votre wiki.

1. Créer une table à partir d’une grille

   Vous n’avez plus besoin de mémoriser la syntaxe de la table markdown. Vous pouvez maintenant créer facilement une table markdown en sélectionnant à partir d’une grille 15 x 15. Sélectionnez simplement le nombre requis de colonnes et de lignes pour insérer un tableau en un seul clic.

   

   Cette fonctionnalité a été hiérarchisée en fonction des tickets de suggestion suivants :

   • Vue table pour wiki
   • Simplifier l’insertion de tables dans wiki

2. Meilleure lisibilité des tables

   Vous pouvez maintenant désactiver l’habillage de mots pour que votre éditeur ait une meilleure lisibilité de vos tableaux. La désactivation de l’habillage de mots ajoute une barre de défilement qui vous permet de voir plus facilement le contenu des grandes tables.

   

3. Mise en forme automatique des tables markdown

   Vous n’avez plus besoin d’ajouter d’espaces pour aligner vos colonnes markdown. Avec le bouton Mettre en forme les tables , vos tables markdown sont automatiquement mises en forme en ajoutant des espaces aux cellules pour aligner les colonnes. Si vous avez des tables volumineuses, utilisez-la avec désactiver l’habillage de mots pour faciliter la lecture des tables.

   

   Vous pouvez également utiliser le raccourci Ctrl + Maj + F pour mettre en forme vos tables.

Rapports

Extension Analytics n’est plus nécessaire pour utiliser Analytics

L’analytique fait de plus en plus partie intégrante de l’expérience Azure DevOps. Il est important pour les clients de les aider à prendre des décisions basées sur les données.

Pour Update 1, nous sommes heureux d’annoncer que les clients n’ont plus besoin de l’extension Analytics pour utiliser Analytics. Les clients peuvent désormais activer l’analytique sous Les paramètres de collection de projets. Il s’agit d’un processus simple qui se trouve directement dans le produit.

Voici comment les clients peuvent activer Analytics :

1. Accédez à Paramètres de la collection de projets :

2. Cliquez sur Activer Analytics

C’est tout ! Les expériences basées sur l’analytique seront activées pour la collection.

Les nouvelles collections créées dans Update 1 et Azure DevOps Server collections 2019 avec l’extension Analytics installée et qui ont été mises à niveau auront Analytics activée par défaut.

Pour en savoir plus sur l’analytique et les expériences qu’elle permet :

• En savoir plus sur l’activation d’Analytics.
• Lisez la documentation Vue d’ensemble d’Analytics.
• Découvrez les principales fonctionnalités : Widgets d’analyse, Rapport de test top-échec, Intégration Power BI et point de terminaison OData.
• Regardez cette vidéo channel 9 sur Azure DevOps Analytics.

---

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