Notes de publication d’Azure DevOps Server 2019 Update 1

Communauté des développeurs | configuration système requise | termes du contrat de licence | Blog DevOps | hachages SHA-1

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

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

La mise à niveau directe vers Azure DevOps Server est prise en charge à partir d’Azure DevOps Server 2020, Azure DevOps Server 2019 ou Team Foundation Server (TFS) 2015 ou version ultérieure. Si votre déploiement TFS se trouve sur TFS 2010 ou version antérieure, vous devez effectuer certaines étapes intermédiaires avant de procéder à la mise à niveau vers Azure DevOps Server 2019. Pour plus d’informations, 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 une nouvelle exécution de pipeline (build) modèle de conservation qui fonctionne en fonction de 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é retenues manuellement ou qui sont retenues par une version de logiciel 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 2019 Update 1.2 Patch 11 : 8 avril 2025

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

• Précédemment, l’agent Azure DevOps a utilisé le CDN Edgio avec le point de terminaison vstsagentpackage.azureedge.net. Dans le cadre de la retraite d’Edgio, le *.azureedge.net domaine est mis hors service. Pour garantir une disponibilité continue, nous avons migré vers un CDN soutenu par Akamai avec un nouveau point de terminaison download.agent.dev.azure.com. Ce correctif inclut les modifications nécessaires pour extraire les fichiers binaires de l'agent à partir du nouveau point de terminaison CDN, ce qui permet de migrer depuis le point de terminaison CDN précédent.

Date de publication d’Azure DevOps Server 2019 Update 1.2 Patch 10 : 11 mars 2025

Nous avons publié correctif 10 pour Azure DevOps Server 2019 Update 1.2, notamment :

• Mettez à jour les tâches à cause de la dépréciation du CDN Edgio. Pour plus d’informations, consultez le billet de blog sur le changement de fournisseur de CDN.

Date de publication d’Azure DevOps Server 2019 Update 1.2 Patch 9 : 28 mai 2024

Nous avons publié correctif 9 pour Azure DevOps Server 2019 Update 1.2 qui inclut les éléments suivants :

• Simplifiez le déploiement des mises à jour de l'agent et des tâches à partir des patches précédents (patches 5 et 6).

Installer des correctifs

Exigences du pipeline

Pour appliquer le nouveau comportement pour valider les arguments de ligne de commande, une variable AZP_75787_ENABLE_NEW_LOGIC = true doit être définie dans les pipelines qui utilisent les tâches affectées. Consultez ici pour plus d’informations sur le comportement activé :

• À propos du 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 2019 Update 1.2 Patch 8 : 12 mars 2024

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

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

Nous avons publié correctif 7 pour Azure DevOps Server 2019 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 du serveur Azure DevOps.

Date de publication d’Azure DevOps Server 2019 Update 1.2 Patch 6 : 14 novembre 2023

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

• Étendue de la liste des caractères autorisés aux tâches PowerShell pour Activer la validation des arguments des tâches shell.

Installer des correctifs

Configurer TFX

1. Suivez les étapes des tâches de téléversement dans la documentation de la collection du projet pour installer et se connecter avec tfx-cli.

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

1. Téléchargez et extrayez Tasks20231103.zip.
2. Modifiez le répertoire dans les fichiers extraits.
3. Exécutez les commandes suivantes pour charger les tâches :

tfx build tasks upload --task-zip-path AzureFileCopyV1.1.230.0.zip
tfx build tasks upload --task-zip-path AzureFileCopyV2.2.230.0.zip 
tfx build tasks upload --task-zip-path AzureFileCopyV3.3.230.0.zip 
tfx build tasks upload --task-zip-path AzureFileCopyV4.4.230.0.zip 
tfx build tasks upload --task-zip-path AzureFileCopyV5.5.230.0.zip 
tfx build tasks upload --task-zip-path BashV3.3.226.2.zip 
tfx build tasks upload --task-zip-path BatchScriptV1.1.226.0.zip 
tfx build tasks upload --task-zip-path PowerShellV2.2.230.0.zip 
tfx build tasks upload --task-zip-path SSHV0.0.226.1.zip 
tfx build tasks upload --task-zip-path WindowsMachineFileCopyV1.1.230.0.zip 
tfx build tasks upload --task-zip-path WindowsMachineFileCopyV2.2.230.0.zip 

Exigences du pipeline

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

• À propos du 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 2019 Update 1.2 Patch 5 : 12 septembre 2023

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

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

Installer des correctifs

1. Téléchargez et installez Azure DevOps Server 2019 Update 1.2 correctif 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.  

Configurer TFX

1. Suivez les étapes des tâches de téléversement dans la documentation de la collection du projet pour installer et se connecter avec tfx-cli.

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

1. Téléchargez et extrayez Tasks_20230825.zip.
2. Modifiez le répertoire dans les fichiers extraits.
3. Exécutez les commandes suivantes pour charger les tâches :

tfx build tasks upload --task-zip-path AzureFileCopyV1.1.226.3.zip 
tfx build tasks upload --task-zip-path AzureFileCopyV2.2.226.2.zip 
tfx build tasks upload --task-zip-path AzureFileCopyV3.3.226.2.zip 
tfx build tasks upload --task-zip-path AzureFileCopyV4.4.226.2.zip 
tfx build tasks upload --task-zip-path AzureFileCopyV5.5.226.2.zip 
tfx build tasks upload --task-zip-path BashV3.3.226.2.zip 
tfx build tasks upload --task-zip-path BatchScriptV1.1.226.0.zip 
tfx build tasks upload --task-zip-path PowerShellV2.2.226.1.zip 
tfx build tasks upload --task-zip-path SSHV0.0.226.1.zip 
tfx build tasks upload --task-zip-path WindowsMachineFileCopyV1.1.226.2.zip 
tfx build tasks upload --task-zip-path WindowsMachineFileCopyV2.2.226.2.zip 

Exigences du pipeline

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

• À propos du 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 2019 Update 1.2 Patch 4 : 8 août 2023

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

• CVE-2023-36869: Vulnérabilité de falsification 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.
• Correction du défaut de boucle infinie sur CronScheduleJobExtension.

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

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

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

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

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

• Correction des échecs dans la tâche d'analyse de la synchronisation du parallélisme de comptes.

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

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

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

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

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

• 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 2019 Update 1.1 Patch 13 : 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.

• Les notifications par e-mail n’ont pas été envoyées lors de l’utilisation du contrôle @mention 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.

Étapes d’installation

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

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

hachage SHA-256 : DB762E391F9DF8E71E58D6FAA169CA44DFBE996AE6567B55F772CBA9E3DA2AB3

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

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 qui contiennent des mots. Auparavant, les requêtes retournaient des résultats incorrects pour les valeurs qui contenaient un saut de ligne.
• 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 2019 Update 1.1 Patch 11 : 14 septembre 2021

Correctif 11 pour Azure DevOps Server 2019 Update 1.1 corrige les éléments suivants.

• Résolvez le problème signalé dans ce ticket de commentaires de la Communauté des développeurs.

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

Mise à jour 10 pour Azure DevOps Server 2019 Update 1.1 inclut des correctifs pour les éléments suivants.

• Résolution du problème lié aux travaux de remise par e-mail pour certains types d’éléments de travail.

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

Patch 9 pour Azure DevOps Server 2019 Update 1.1 comprend des correctifs pour les éléments suivants.

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

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

Nous avons publié un correctif pour Azure DevOps Server 2019 Update 1.1 qui corrige ce qui suit.

• CVE-2021-27067: divulgation d’informations
• Résoudre le problème signalé dans le ticket de retour d'expérience de la Communauté des développeurs | Impossible d’enregistrer 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 répertoriées ci-dessous pour installation générale des correctifs et installations de tâches AzureResourceGroupDeploymentV2.

Installation générale des correctifs

Si vous disposez d’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écuter 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 que le correctif a été installé ou qu’il n’est pas installé.

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

Installation de tâche AzureResourceGroupDeploymentV2

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) selon les besoins de votre ordinateur.

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

npm install -g tfx-cli

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

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

~$ tfx login
Copyright Microsoft Corporation

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

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

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

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

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

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

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

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

• CVE-2020-1325: Vulnérabilité d’usurpation d’identité Azure DevOps Server
• CVE-2020-17135: Vulnérabilité d’usurpation d’identité Azure DevOps Server
• CVE-2020-17145: Vulnérabilité d’usurpation d’identité Azure DevOps Server et Team Foundation Services
• Résolution d’un problème avec TFVC qui ne traite pas tous les résultats

Installation générale des correctifs

Si vous disposez d’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écuter 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 que le correctif a été installé ou qu’il n’est pas installé.

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

Installation de tâche AzurePowerShellV4

Conditions préalables

1. installer le module Azure PowerShell Az sur votre machine d'agent privé Azure PowerShell.

2. Créez un pipeline avec la tâche AzurePowerShellV4. Vous ne verrez qu’un seul Échec sur l'erreur-type dans cette 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 complet , puis copiez-le ensuite. Ce jeton d'accès personnel sera utilisé lors de l’exécution de la commande tfx login.

5. Exécutez ce qui suit depuis 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 sera D :\tasks\AzurePowerShellv4.

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

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

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

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

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

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

• CVE-2020-1326: vulnérabilité de script intersites
• Le pipeline de génération 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 du changement de l’héritage en Activé ou en Désactivé dans la définition de build XAML.

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

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

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

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

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

• Les validations SVN ne déclenchent pas de pipeline

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

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

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

• CVE-2020-0700: vulnérabilité de script intersites

• 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 d’Azure DevOps Server 2019 Update 1.1 RTW : 10 décembre 2019

Azure DevOps Server 2019 Update 1.1 est un récapitulatif 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 précédemment publiés. Vous pouvez installer directement Azure DevOps Server 2019 Update 1.1 ou effectuer une mise à niveau à partir d’Azure DevOps Server 2019 ou Team Foundation Server 2012 ou version ultérieure.

Cette version inclut des correctifs pour les bogues suivants :

Azure Boards

• Lors de la création d’un élément de travail à partir du backlog de 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’expiration lors de l’utilisation d’Azure Boards.
• La valeur Révisé par est incorrecte sur les liens des éléments de travail.

Azure Pipelines

• Dans les notifications Pipelines, les champs tels que Durée peuvent être nuls 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 des paramètres de rétention au niveau de la collection s’affiche dans les pages des paramètres du projet.

Plans de test Azure

• La modification des champs dans les plans de test est lente.
• Dans un cas de test, lorsqu'on l'ouvre depuis les tableaux et non depuis les plans de test, les détails de l'étape partagée ne s'ouvrent pas.

Généralités

• 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 s’installent sur SQL Azure ne voient pas la boîte de dialogue d’évaluation complète.
• L’installation d’extensions donne l’erreur « Message d’erreur contribution manquante (ms.vss-dashboards-web.widget-sdk-version-2) ».
• Lors de la configuration de la recherche élastique, une erreur s’affiche : « 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 d’Azure DevOps Server.

Cette version inclut la mise à jour suivante :

• Prise en charge de SQL Server 2019.

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

Nous avons publié un correctif de sécurité pour Azure DevOps Server 2019 Update 1 qui corrige le bogue suivant. Pour plus d’informations, consultez le billet de blog .

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

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

Date de publication RC2 : 23 juillet 2019

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

Date de publication RC1 : 2 juillet 2019

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

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

• nouveau processus de base
• Requête concernant le travail lié au début de la journée, de la semaine, du mois ou de l'année
• Accepter et traiter des tickets sur GitHub tout en planifiant dans Azure Boards
• Réexécuter la compilation expirée pour compléter automatiquement les demandes de tirage
• Nouveaux types de fusion pour finaliser les requêtes de tirage
• déclencher des pipelines YAML avec des balises
• Assistant de tâche pour modification des fichiers YAML
• éditeur web avec IntelliSense pour les pipelines YAML
• Gérer les versions de GitHub à l’aide de pipelines
• widget de tendance des résultats de test (avancé)
• Informations de provenance sur les paquets
• Prise en charge des packages Python
• Sources en amont pour Maven
• Incorporer des résultats de requête Azure Boards dans le 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éral
• Tableaux
• Dépôts
• Chaînes de traitement
• plans de test
• Artefacts
• Wiki
• Rapport

Généralités

Thème sombre

Le thème sombre a été une fonctionnalité populaire sur Azure DevOps Services et il est désormais 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.

Comités

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 d’éléments de travail et d’états pour répondre à une variété de méthodes de livraison de projet. Pour certaines équipes, qui sont plus familières avec d’autres outils ou qui veulent adopter un ensemble d’outils plus puissant, souhaitent commencer rapidement à utiliser la terminologie avec laquelle ils sont plus familiers.

Le nouveau processus de base fournit trois types d’éléments de travail (épopées, problèmes et tâches) pour planifier et suivre votre travail. Nous vous recommandons d’utiliser Des problèmes pour suivre des éléments tels que des histoires utilisateur, des bogues et des fonctionnalités tout en utilisant Epics pour regrouper les problèmes en unités de travail plus importantes. À mesure que vous progressez dans votre travail, déplacez les éléments à travers un flux de travail d'état simple : À faire, En cours, Terminé.

Consultez la documentation des problèmes de la piste et des tâches pour vous aider à bien démarrer avec votre nouveau projet.

Ordre des valeurs d’état sur le formulaire d’é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 correspondre à l’ordre de flux de travail dans les paramètres de processus. Vous pouvez également modifier l’ordre des états dans chaque catégorie dans les paramètres de personnalisation de l’état.

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

Les clients devront mettre à jour manuellement le code XML pour chaque projet afin d’activer de 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 enrichies

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

Partagez le tableau de votre équipe grâce à un badge

Le README du référentiel est souvent la référence principale vers laquelle votre équipe de projet se tourne pour obtenir des informations sur la façon de contribuer et à utiliser votre solution. À présent, comme vous le faites pour un état de build ou de déploiement dans Azure Pipelines, vous pouvez ajouter un badge à votre fichier README pour le tableau de votre équipe dans Azure Boards. Vous pouvez configurer le badge pour afficher uniquement les en cours colonnes 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 d’état et le coller dans votre fichier.

Rechercher du travail lié au début du jour, 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 va arriver ou en fonction des itérations de sprint, il est souvent intéressant d'examiner le travail à travers la perspective du calendrier pour rendre compte de tout le travail qui s'est produit le mois dernier ou au premier trimestre de l'année. Vous pouvez maintenant utiliser le nouvel ensemble suivant de macros @StartOf ainsi que n’importe quel champ basé sur des dates pour interroger 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 unités de date différentes. Par exemple, vous pouvez écrire une requête pour rechercher tous les éléments de travail terminés au premier trimestre de cette année en interrogeant la date de modification de l’état >= @StartOfYear et la date de modification d’état <= @StartOfYear(« +3M »). Pour plus d’informations, consultez la documentation des macros de requête .

Modifier et supprimer des commentaires de discussion

Nous sommes heureux d’annoncer la disponibilité d’une fonctionnalité très plébiscitée par la communauté des développeurs : la modification et la suppression de commentaires dans les discussions de vos éléments 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 modifier vos modifications et appuyer sur le bouton « Mettre à jour » pour enregistrer vos modifications.

Lorsque vous cliquez sur le menu de dépassement de capacité, vous verrez l’option permettant de supprimer votre commentaire. Une fois que vous cliquez sur ce bouton, vous êtes invité à nouveau à confirmer que vous souhaitez supprimer ce commentaire et que 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 qu’elle se sente plus moderne et interactive. Nous avons ajouté des bulles autour des commentaires pour le rendre plus clair où les commentaires des individus commencent et se terminent.

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

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

Accédez aux éléments de travail Azure Boards directement depuis les mentions de n'importe quel commentaire GitHub.

Maintenant, lorsque vous mentionnez 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 syntaxe AB#{work item ID}, ces mentions deviennent des liens hypertexte cliquables pour naviguer directement vers l’élément de travail mentionné.

Cela ne crée pas de 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 lors de la discussion du code ou d’un problème signalé par le client. Pour plus d’informations, consultez la documentation de l’intégration GitHub des 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 dans GitHub, mais associez et organisez le travail de l’équipe dans Azure Boards, vous pouvez maintenant le faire.

La même syntaxe de mention que celle utilisée par votre équipe pour les commits et les pull requests s’applique toujours et bien sûr, vous pouvez créer un lien manuellement dans Azure Boards avec l’URL de l’élément. Pour plus d’informations, consultez la documentation GitHub & Azure Boards.

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

Lorsque vous passez en revue le tableau Kanban vous-même ou en tant qu’équipe, vous avez souvent des questions telles que « cet élément a-t-il 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 obtenir un aperçu 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 ce sujet et les autres annotations pour les tâches et les tests.

Repos

Brouillons de pull requests

Afin d’empêcher l'achèvement des pull requests avant qu'elles ne soient prêtes et de faciliter la création de travaux en cours qui peuvent ne pas impliquer tout le monde, nous prenons désormais en charge les pull requests brouillons.

Vous pouvez créer des pull requests en sélectionnant Créer en tant que brouillon dans la liste déroulante du bouton Créer lors de la création d'une pull request.

Une fois que vous avez créé un brouillon de pull request, vous verrez un badge indiquant son état à côté du titre.

Les requêtes de tirage en mode brouillon n'incluent pas par défaut les examinateurs ni ne lancent les builds, mais vous permettent d'ajouter manuellement des examinateurs et de lancer des builds. Pour promouvoir la pull request en une pull request normale, cliquez simplement sur le bouton Publier à partir de la page des détails de la pull request.

Réexécuter la build expirée pour les pull requests à complétion automatique

Azure Repos mettra désormais automatiquement en file d'attente les builds expirés qui ont été déclenchés par une stratégie de requête de tirage. Cela s'applique aux requêtes de tirage qui ont passé toutes les autres stratégies et qui sont prêtes pour l'achèvement automatique.

Auparavant, lorsque les pull requests avaient des politiques comme des approbations obligatoires, le processus d'approbation pouvait prendre trop de temps et une construction associée pouvait expirer avant qu'un examinateur ait approuvé la pull request. Si la pull request avait été définie pour une finalisation automatique, elle resterait bloquée jusqu'à ce qu'un utilisateur place manuellement la construction expirée en file d'attente. Avec cette modification, le build est mis en file d'attente automatiquement afin que la pull request se termine automatiquement après un build réussi.

Afficher uniquement le fichier gauche ou droit dans une pull request

Aujourd'hui, lors de l'affichage des modifications de fichier dans une pull request, vous pouvez utiliser un mode de différences côte à côte ou en ligne. Nous avons reçu des commentaires indiquant que bon nombre d’entre vous veulent 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 compléter les pull requests

Vous avez maintenant plus d’options lors de la fusion des modifications d’un pull request dans la branche cible. Nous avons ajouté la prise en charge de deux de nos fonctionnalités les plus demandées sur la Communauté des développeurs : fusion de Fast-Forward avec et fusion de Semi-Linear avec (également appelée « Rebasage et fusion »).

Vous verrez maintenant ces nouvelles options disponibles dans la boîte de dialogue Terminer la pull request :

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.

Il existe quelques situations où le rebasage lors de la finalisation d'une demande de tirage n'est pas possible :

• Si une politique sur la branche cible interdit l'utilisation de stratégies de rebasage, il vous faudra l'autorisation de « Remplacer les politiques de branche ».
• Si la branche source de la pull request a des stratégies, vous ne pourrez pas la rebaser. Le réalignement modifie la branche source sans suivre le processus d'approbation de la stratégie.
• Si vous avez utilisé la Extension de Conflit de Fusion pour résoudre les conflits de fusion. Les résolutions de conflit appliquées à une fusion tridirectionnelle sont rarement réussies (ou même valides) lors du rebasage de toutes les validations dans un pull request, un à un.

Dans tous ces cas, vous avez toujours la possibilité de rebaser votre branche localement et de pousser sur le serveur, ou de fusionner vos modifications lors de la finalisation de la demande de tirage.

Filtrer par branche cible dans les pull requests (PR)

Les pull requests permettent à votre équipe d’examiner le code et de faire des retours sur les modifications avant de les fusionner dans la branche principale. Ils sont devenus une partie importante des flux de travail 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 pull requests dans l’onglet Mine.

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

Actuellement, nous publions la mise en surbrillance de la syntaxe pour un sous-ensemble de langages pris en charge par l’éditeur Monaco. Toutefois, beaucoup d’entre vous souhaitent créer votre 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 coloration syntaxique et la saisie semi-automatique aux vues de l’Explorateur de fichiers et des pull requests.

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 pour le langage Kusto.

Point d'extension pour la création de dépôt

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

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

Auparavant, la modification et l’enregistrement de fichiers sur le web n’enregistrait que l’encodage UTF-8 et nous ne vous avertissions pas lorsque l’encodage du fichier changeait. À présent, nous vous donnerons un avertissement lorsque vous essayez d’enregistrer un fichier qui n’est pas encodé par 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 les points de terminaison des pushs 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 illustre la boîte de dialogue que vous verrez lorsque vous introduisez des modifications d’encodage par un push web.

Support des commandes Go 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 des go get dans un référentiel 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 mot clé import pour spécifier le chemin d’importation.

Canalisations

É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 activer IntelliSense lorsque vous modifiez le fichier YAML. Vous verrez les erreurs de syntaxe mises en surbrillance et obtenir de l’aide sur la correction de ces erreurs.

Assistant de tâches pour éditer les fichiers YAML

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

Déclencher des pipelines YAML avec des balises

Les pipelines YAML peuvent être déclenchés lorsque des balises sont ajoutées à une validation. Cela est utile pour les équipes dont les flux de travail incluent des balises. Par exemple, vous pouvez lancer un processus lorsqu’une validation est marquée comme « dernière bonne connue ».

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

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

Déclarer les ressources de conteneur en ligne

Auparavant, nous vous avons demandé 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 ne 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 pull request est mise à jour

Par défaut, les pipelines déclenchés par des requêtes d'extraction (PR) sont annulés si un nouveau commit est appliqué à la même requête d'extraction. Cela est souhaitable dans la plupart des cas, car généralement vous ne souhaitez 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 pull request.

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

Choisissez le répertoire du code vérifié dans les pipelines YAML

Auparavant, nous avons extrait les dépôts dans le répertoire s 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 mot clé path sur checkout et vous êtes dans le contrôle de la structure de 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 sera téléchargé dans le répertoire my-great-repo de l’espace de travail de l’agent. Si vous ne spécifiez pas de chemin d’accès, votre dépôt continue 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 offrent un moyen simple et puissant de déployer Azure App Services avec des développeurs modernes à l’esprit. Ces tâches ont une syntaxe YAML optimisée qui permet de créer des déploiements simples et intuitifs sur Azure AppServices, notamment WebApps, FunctionApps, WebApps pour conteneurs et FunctionApp pour conteneurs sur les plateformes Windows et Linux.

Nous prenons également en charge une nouvelle tâche utilitaire pour la transformation de fichier 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 n’ont pas pu créer de pipelines, sauf s’ils reçoivent 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. Cette modification réduit 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 constituent un excellent moyen de empaqueter et de fournir des logiciels aux utilisateurs. Nous sommes heureux d’annoncer que vous pouvez désormais 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 brouillons/publiées existantes ou ignorer les versions antérieures. Il prend en charge des fonctionnalités telles que le chargement de plusieurs ressources, le marquage d’une version en 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 log de construction

Vous pouvez désormais partager un lien vers des lignes spécifiques dans le journal de construction. 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 de résultats pour obtenir une icône de lien.

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

Nous avions besoin de fournir une sécurité pour les 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 les scénarios hors production. Auparavant, 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 rendons plus facile pour résoudre un problème d’autorisation de ressource même si vous n’avez pas marqué une ressource comme 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 pour les extensions dans l’onglet Test des pipelines

Nous avons continué à rendre le framework d’extension plus puissant en ajoutant deux nouveaux points de contribution dans l’onglet Résultats des tests dans Pipelines. Cela permettra aux extensions du Marché de fournir des expériences de rapport plus personnalisées et d’ajouter une interactivité supplémentaire.

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 de métadonnées à partir 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 *Action personnalisée- bouton.

   

2. onglet Détails personnalisés dans le volet Détails

   Il est probable que vous disposiez d'un large éventail de flux de traitement des rapports de test et que vous souhaitiez voir différents points de données pour les tests échoués en vue du débogage et de l'analyse. À l’aide de ce point de contribution, votre équipe peut ajouter un nouvel onglet au volet d’informations qui s’affiche 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.

Agent d’exécution unique

Si vous utilisez une infrastructure telle qu’Azure Container Instances pour exécuter des agents privés élastiques, vous souhaitez souvent que chaque agent accepte un seul travail avant de partir. Jusqu’à présent, cela n’était pas facile, car vous deviez mettre fin à l’agent (peut-être à l’origine d’un échec) ou accepter le risque qu’un agent puisse recevoir un autre travail avant de pouvoir l’arrêter. Avec cette mise à jour, nous avons ajouté le --once flag à 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 lui-même.

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

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

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

Par défaut, Azure Pipelines utilisé pour réexécuter tous les travaux lorsque vous redéployez une exécution ayant é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 Toute tâche et limiter aux cibles échouées dans un groupe de déploiement, la réexécution lancera tous les travaux et ignorera les déploiements vers les cibles qui sont déjà à jour.

Redéployer automatiquement en cas d’échec

Lorsqu’un déploiement échoue à une étape, 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 actions déclenchés supplémentaires à la configuration de redéploiement automatique dans un sprint futur. Consultez la documentation groupes de déploiement pour plus d’informations.

Service de raccrochage 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 « 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 liées aux alertes d'Azure Monitor

La version précédente de la tâche Query Azure Monitors prenait uniquement en charge l'interrogation des alertes sur l'expérience de surveillance 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 les pipelines de mise en production supprimés

La suppression de pipelines de mise en production inutilisés permet de garder la liste des pipelines propre, mais il arrive parfois que l'on supprime 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 Releases qui affiche une liste de 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 sur l’échec d’une demande de création de livraison

Vous pouvez définir des notifications pour recevoir des e-mails lorsque des modifications se produisent sur 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 enverra un e-mail quand une demande de création de version échoue. Un exemple de scénario dans lequel cela peut être utile est lorsqu’une demande de création d’une version échoue, car une version d’artefact n’est pas disponible. Pour savoir comment gérer vos notifications, consultez la documentation ici.

Planifier des publications sur une modification de la source ou du pipeline

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

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

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

Publier sur les files d'attente de session Azure Service Bus

Nous avons élargi la tâche de génération sans agent pour inclure la capacité à 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 versions vous permettent de vous connecter à des services externes et distants pour 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 d’administration de votre projet.

Avec cette mise à jour, nous avons ajouté une option d’authentification au formulaire de connexion au 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 du cluster.

Pour un cluster avec contrôle d’accès en fonction du rôle (RBAC), ServiceAccount et objets 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 avec RBAC désactivé, le compte de service créé dispose d'autorisations à l'échelle du cluster sur l'ensemble des espaces de noms.

Registre de conteneurs Azure dans la connexion au service de registre Docker

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 tels que Docker@2 et KubernetesManifest@0 prennent en charge une seule façon de spécifier une connexion.

Rechercher par nom de dossier dans les définitions de mise en production

Vous pouvez organiser vos définitions de déploiement en les stockant dans des dossiers. Auparavant, vous n’avez pas la possibilité d’effectuer une recherche par dossier. Il était difficile de trouver une définition de version spécifique si vous aviez créé beaucoup de dossiers. Vous pouvez maintenant effectuer une recherche par nom de dossier dans la définition de mise en production, ce qui facilite la recherche des définitions que vous recherchez.

Tâche de l'installateur de l'outil Duffle dans le pipeline de compilation et de déploiement

Duffle est un outil en ligne de commande qui vous permet d’installer et de gérer des bundles 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 du fichier binaire Duffle.

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 fichier binaire kubectl dans les scripts :

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

• Stabilité du manifeste - L'état du déroulement du déploiement est vérifié pour que les objets Kubernetes déployés intègrent des contrôles de stabilité lors de la détermination de l'état de la tâche en tant que réussite/échec.

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

• Manifeste de bake : l'action de bake de la tâche permet de convertir des charts Helm en fichiers manifeste Kubernetes afin qu'ils puissent être appliqués au cluster.

• Stratégie de déploiement : choisir une stratégie canary avec une action de déploiement entraîne la création du pourcentage souhaité de charges de travail suffixées par -base et -canary afin qu’elles puissent être comparées durant une tâche ManualIntervention avant d’utiliser 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 à jour de 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 les connexions de service de Registre Docker pour la connexion aux registres de conteneurs. Les métadonnées de traçabilité sur le référentiel source, la provenance de build et le commit sont ajoutées comme étiquettes aux images générées avec 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

Installateur 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 latest et Semver telles que « v1.14.0 » sont acceptées comme valeurs valides pour l'entrée Spec Kubectl Version.

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

Une fonctionnalité clé pour la collaboration entre é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 (normal, 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 organisation. Enfin, vous pouvez également restreindre les mises en production en fonction des demandes de modification existantes. Cela vous permet d’adopter le 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 du module Azure PowerShell 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 Azure PowerShell Az est devenu disponible et est maintenant le module destiné à la gestion de vos ressources Azure.

Auparavant, nous n’avons pas pris en charge le module Azure PowerShell Az dans nos agents hébergés. Avec la nouvelle tâche Azure PowerShell 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. La tâche Azure PowerShell version 3.* continuera de prendre en charge le module AzureRM. Toutefois, pour suivre les derniers services et fonctionnalités Azure, nous vous recommandons de passer à la tâche Azure PowerShell version 4.* dès que possible.

Le module Az a 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 commande Enable-AzureRmAlias. 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 Azure PowerShell Az ici.

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

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

La tâche 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’une 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 fichier longs

Jusqu’à présent, il y avait une limitation qui empêchait le chargement d’artéfacts de build avec des chemins d’accès de plus de 233 caractères. Cela peut vous empêcher de téléverser les résultats de couverture de code à partir de compilations Linux et macOS avec des chemins d’accès de fichiers plus longs que ceux prévus par la limite. La limite a été mise à jour pour prendre en charge les chemins longs.

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

Vous pouvez maintenant indiquer à Azure Pipelines d’ignorer une validation et d’ignorer l’exécution d’un pipeline que la validation déclencherait normalement. Incluez simplement [skip ci] dans le message du commit HEAD, et Azure Pipelines ignorera le CI. Vous pouvez également utiliser l’une des variantes répertoriées ci-dessous. La prise en charge est assurée pour les commits dans Azure Repos Git et sur 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***

Plans de test

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

Le widget Tendance des résultats de test (Avancé) fournit une visibilité quasi en temps réel de 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 les pipelines. Vous pouvez l’utiliser pour suivre le nombre quotidien de tests, de taux de réussite et de durée de test. Le suivi de la qualité des tests au fil du temps et l’amélioration des garanties de test est essentiel à la maintenance d’un pipeline DevOps sain.

Le widget de tendance des résultats de test (avancé) vous aide à trouver des valeurs hors norme dans vos résultats de test et à répondre à des questions telles que : les tests prennent-ils plus de temps à s’exécuter que d’habitude ? Quel fichier de test ou pipeline affecte mon taux de réussite global ? Quels sont mes tests de durée prolongée ?

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

• Affiche une tendance du taux de réussite et le nombre de résultats de test ou de durée de test
• Présente les résultats des tests basés sur plusieurs pipelines de build ou de mise en production
• Utilise des options de graphique combinées pour afficher deux métriques sur la même tendance
• Filtre le nombre de tests au fil du temps par résultat de test
• Filtre tous vos résultats de test par branche ou test
• Classe vos métriques selon les attributs de test tels que la priorité ou l'environnement
• Regroupez vos données sur des fichiers de Test, propriétaires ou 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 l’exécution de test via l’URL

Vous pouvez configurer des tests automatisés à exécuter dans le cadre d’une build ou d’une version. Les résultats des tests publiés peuvent être consultés sous l’onglet Tests dans le résumé de build ou de mise en production. Avec cette mise à jour, nous avons ajouté une fonctionnalité Copier l’URL des résultats afin de pouvoir partager les résultats d'une seule exécution de test 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 le cadre d'un test
• Le partage est également compatible avec tous les onglets d’extension configurés

Lorsque vous partagez l’URL, les visionneuses verront les résultats de l’exécution de test en mode plein écran.

Artéfacts

Packages NuGet avec des numéros de version SemVer 2.0.0

Auparavant, Azure Artifacts ne prenait pas en charge les packages NuGet avec des numéros de version SemVer 2.0.0 (généralement, les numéros de version qui contiennent la partie de métadonnées de build de la version, ce qui est indiqué par un +). Vous pouvez maintenant 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 de NuGet.org, les métadonnées de génération ne peuvent pas être utilisées pour ordonner 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 fait en sorte qu’il soit un peu plus facile de comprendre la provenance de vos packages : qui les a publiés ou ce qui les a publiés et le commit du code source dont ils proviennent. Ces informations sont renseignées automatiquement pour tous les packages publiés à l’aide du NuGet, npm, Mavenet Twine Authentifier (pour Python) tâches dans Azure Pipelines.

Statistiques d’utilisation des packages

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

Prise en charge des paquets Python

Azure Artifacts peut désormais héberger des packages Python : les deux packages que vous produisez vous-même et les packages en amont 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 des sources en amont Maven à un flux existant, visitez les paramètres du flux, sélectionnez l'onglet sources en amont, puis sélectionnez Ajouter une source en amont.

Support 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 n’ont pas fourni une prise en charge complète de l’infrastructure proxy d’Azure Pipelines, ce qui a entraîné des difficultés à utiliser les tâches à partir d’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 restore et push uniquement
• DotNetCoreCLI@2 ('.NET Core' dans le concepteur) : commandes restore et nuget push 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 paquets Artifacts pris en charge dans les versions publiées

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

Vues d'artefacts prises en charge dans les versions logicielles

Auparavant, le type d’artefact Azure Artifacts ne pouvait se déclencher que lorsque de nouvelles versions de package ont été publiées dans le flux. À présent, nous avons également ajouté la prise en charge des vues, vous pouvez donc déclencher des versions lorsque des packages déjà présents dans le flux sont promus vers une vue.

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

Jusqu’à présent, les flux Azure Artifacts ont proposé des stratégies de rétention de base qui commenceraient à supprimer les anciennes versions de package lorsqu’un « nombre maximal de versions par package » a été atteint. Avec cette mise à jour, nous avons ajouté la possibilité d’ignorer les packages récemment téléchargés lors de ce nettoyage. Pour activer, modifiez votre flux et cochez la case Ignorer les paquets téléchargés récemment.

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

Dans Azure Artifacts, les Administrateurs de la Collection de Projets (PCA) ont toujours pu administrer tous les flux de données dans un serveur Azure DevOps. Avec cette mise à jour, les PCA peuvent également donner cette possibilité à d’autres utilisateurs et groupes, en 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 , vidéos et 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 des résultats de requête Azure Boards dans Wiki

Vous pouvez désormais incorporer des résultats de requête Azure Boards 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 tous les bogues actifs dans le sprint actuel incorporé 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 maintenant être consultés sous la forme d’une table après avoir enregistré la page.

Caractères en monospace pour l'éditeur Wiki Markdown

Avec l’introduction de 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é priorisée selon ce ticket de suggestion .

Permalinks pour les pages Wiki

Jusqu’à présent, les liens de page Wiki partagés se sont rompus si la page liée a été 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 l’état de l’élément de travail dans les pages Wiki

Dans cette mise à jour, nous avons amélioré les mentions d’élément de travail dans les pages Wiki en ajoutant l’état 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 pull request et les discussions sur les tableaux affichent également l’état.

@mention utilisateurs et groupes

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

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

Enfin, vous pouvez également cliquer sur le @mentioned utilisateur pour afficher la carte d’informations de profil. Cette fonctionnalité a été priorisée en fonction de cette suggestion de fonctionnalité .

Notifications sur les pages wiki

Jusqu’à présent, vous n’avez pas eu de moyen de savoir quand le contenu d’une page wiki a été modifié. Vous pouvez maintenant 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é prioritisée en fonction de ce ticket de suggestion . Pour en savoir plus, consultez notre documentation ici.

Prise en charge des balises HTML

À présent, 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 en utilisant les balises détail et synthèse. Vous pouvez ajouter l'attribut ouvert pour conserver les détails développés par défaut.

   

   Pour obtenir plus d'informations sur les détails de la balise , consultez la documentation ici.

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

   Remarque

   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 de table

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 de 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 dans une grille de 15 X 15. Sélectionnez simplement le nombre requis de colonnes et de lignes pour insérer une table en un seul clic.

   

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

   • Vue en tableau pour des wikis
   • Simplifier l’insertion de tables dans le wiki

2. Meilleure lisibilité des tables

   Vous pouvez maintenant activer ou désactiver le retour à la ligne automatique pour que votre éditeur affiche vos tableaux avec une meilleure lisibilité. La désactivation de l’habillage de mot ajoute une barre de défilement qui vous permet de voir plus facilement le contenu des grands tableaux.

   

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 Format des tableaux, vos tables Markdown sont automatiquement mises en forme en ajoutant des espaces aux cellules pour aligner les colonnes. Si vous disposez de tableaux volumineux, utilisez-le avec désactiver l’habillage de mots, pour faciliter la lecture des tableaux.

   

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

Rapports

L’extension Analytics n’est plus nécessaire pour utiliser Analytics

L’analytique devient de plus en plus une partie intégrante de l’expérience Azure DevOps. Il s’agit d’une capacité importante pour les clients de les aider à prendre des décisions pilotées par 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 Analytics sous les paramètres de collecte 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 aux paramètres de collection de projets :

2. Cliquez sur Activer Analytics

Et c’est ça ! Les expériences alimentées par l’analytique seront activées pour la collection.

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

Pour en savoir plus sur Analytics et les expériences qu’il permet :

• En savoir plus sur la manière dont permet l'activation d'Analytics.
• Lisez la documentation Analytics Overview.
• Lisez les principales fonctionnalités : widgets analytiques, rapport des tests échoués, d'intégration avec Power BIet le point de terminaison OData.
• Regardez cette vidéo Channel 9 sur Azure DevOps Analytics.

commentaires

Nous aimerions vous entendre ! Vous pouvez signaler un problème ou fournir une idée et le suivre via Communauté des développeurs et obtenir des conseils sur Stack Overflow.