Notes de publication d’Azure DevOps Server 2019 Update 1

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

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

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

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

---

mise à niveau Coffre ly d’Azure DevOps Server 2019 vers Azure DevOps Server 2020

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

Azure DevOps Server 2020 gère la rétention des builds différemment, en fonction des stratégies de rétention au niveau du pipeline. Certaines configurations de stratégie entraînent la suppression des exécutions de pipeline après la mise à niveau. Les exécutions de pipeline qui ont été conservées manuellement ou qui sont conservées par une version ne seront pas supprimées après la mise à niveau.

Lisez notre billet de blog pour plus d’informations sur la mise à niveau sécurisée d’Azure DevOps Server 2019 vers Azure DevOps Server 2020.

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

File	Hachage SHA-256
devops2019.1.2patch9.exe	4A3F41BBE00174DE9646667878766EBF7F4D292526CBC1D885180B55D94B4D81

Nous avons publié patch 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 correctifs précédents (Correctif 5 et 6).

Remarque

Il n’est pas nécessaire de suivre les étapes des correctifs 5 et 6 ; ceux-ci peuvent être ignorés et ce correctif peut être appliqué à la place.

Installer les correctifs

Important

 Ce correctif met à jour l’agent pipeline disponible, la nouvelle version de l’agent après l’installation de Patch 9 sera 3.225.0.

Exigences relatives aux pipelines

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. Pour plus d’informations sur le comportement activé, consultez ici :

• Sur classique :

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

• Exemple YAML :

variables: 
- name: AZP_75787_ENABLE_NEW_LOGIC 
  value: true 

Date de publication d’Azure DevOps Server 2019 Update 1.2 Patch 8 : 12 mars 2024

File	Hachage SHA-256
devops2019.1.2patch8.exe	67E78EA7D67A09A6EE06309614F92E6D8495DEF52FF442E4E7C7979244FAD20A

Nous avons publié patch 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

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

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

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

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 pour activer la validation des arguments des tâches de l’interpréteur de commandes.

Remarque

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

Installer les correctifs

Important

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

Configurer TFX

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

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

File	Hachage SHA-256
Tasks20231103.zip	389BA66EEBC32622FB83402E21373CE20AE040F70461B9F9AF9EFCED5034D2E5

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

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

Exigences relatives aux pipelines

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

• Sur classique :

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

• Exemple YAML :

variables: 
- name: AZP_75787_ENABLE_NEW_LOGIC 
  value: true 

Date de publication d’Azure DevOps Server 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 d’Azure DevOps Server.
• CVE-2023-38155 : Vulnérabilité d’élévation de privilèges azure DevOps Server et Team Foundation Server.

Important

Veuillez déployer le patch dans un environnement de test et vous assurer que les pipelines de l’environnement fonctionnent comme prévu avant d’appliquer le correctif à la production.

Remarque

Pour implémenter des correctifs pour ce correctif, vous devez suivre plusieurs é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.  

Remarque

Le paramètre AZP_AGENT_DOWNGRADE_DISABLED doit être défini sur « true » pour empêcher l’agent de passer à une version antérieure. 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 de la documentation sur le téléchargement des tâches dans la collection de projets pour installer et vous connecter à tfx-cli.

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

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

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

Exigences relatives aux pipelines

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

• Sur classique :

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

• Exemple YAML :

variables: 
- name: AZP_75787_ENABLE_NEW_LOGIC 
  value: true 

Date de publication d’Azure DevOps Server 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é d’usurpation d’identité azure DevOps Server.
• Mettez à jour le service SSH pour prendre en charge SHA2-256 et SHA2-512. Si vous avez des fichiers de configuration SSH codés en dur pour utiliser RSA, vous devez effectuer une mise à jour vers SHA2 ou supprimer l’entrée.
• Correction du bogue 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ère avec les packages push lors de la mise à niveau à partir de 2018 ou 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 le travail Analyse de synchronisation du parallélisme de compte.

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 dis carte 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 cumul de correctifs de bogues. 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.

Remarque

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

Remarque

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

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

Hachage SHA-256 : DB762E391F9DF8E71E58D6FAA169CA44DFBE996AE6567B55F772CBA9E3DA2AB3

Date de publication d’Azure DevOps Server 2019 Update 1.1 Patch 12 : 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 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

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 de la Communauté des développeurs.

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

Le correctif 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

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

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

Date de publication d’Azure DevOps Server 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 ce ticket de commentaires de la Communauté des développeurs | 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 répertoriées 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 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é 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

Remarque

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

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

npm install -g tfx-cli

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

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

~$ tfx login
Copyright Microsoft Corporation

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

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

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

Date de publication d’Azure DevOps Server 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. Consultez le billet de blog pour plus d’informations.

• 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. Consultez le billet de blog pour plus d’informations.

• 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

Important

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

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é 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

Remarque

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

Prérequis

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

2. Créez un pipeline avec la tâche AzurePowerShellV4 . Vous ne verrez qu’un échec sur une 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 complets et copiez-le. Ce jeton d’accès personnel sera utilisé lors de l’exécution de la commande tfx login.

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

~$ tfx login
Copyright Microsoft Corporation

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

6. Exécutez la commande suivante pour charger la tâche sur le serveur. Le chemin d’accès du package extrait est 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. 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é.

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. Consultez le billet de blog pour plus d’informations.

• 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.
• Corrigez l’erreur lors de la modification de l’héritage sur Activé ou 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. Consultez le billet de blog pour plus d’informations.

• 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. Consultez le billet de blog pour plus d’informations.

• 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. Consultez le billet de blog pour plus d’informations.

• 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 cumul des correctifs de bogues et des 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.

Remarque

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

Cette version inclut les corrections des bugs suivants :

Azure Boards

• 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ée par est incorrecte sur les liens d’élément de travail.

Azure Pipelines

• Dans les notifications Pipelines, les champs tels que Durée peuvent être Null dans certains paramètres régionaux.
• Le chemin d’accès au 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.

Azure Test Plans

• La modification des champs dans les plans de test est lente.
• Dans un cas de test, lors de l’ouverture à partir de tableaux (par opposition aux plans de test), 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 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. Consultez le billet de blog pour plus d’informations.

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

---

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

Remarque

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

---

Date de publication 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 les principales :

• Nouveau processus de base
• Effectuer des requêtes relatives au travail en fonction du début du jour, de la semaine, du mois ou de l’année
• Accepter et exécuter sur des problèmes dans GitHub lors de la planification dans Azure Boards
• Relancer un build expiré pour les demandes de tirage à saisie automatique
• Nouveaux types de fusion pour la réalisation de demandes de tirage
• Pipelines YAML de déclencheur avec balises
• Assistant Tâche pour l’édition de fichier YAMLs
• Éditeur web avec IntelliSense pour les pipelines YAML
• Gérer les mises en production GitHub à l’aide de pipelines
• Widget Tendance des résultats de test (Avancé)
• Informations sur la provenance dans les packages
• Prise en charge des packages Python
• Sources amont pour Maven
• Incorporer des résultats de requête Azure Boards dans Wiki
• Permalinks pour les pages Wiki
• Notifications sur les pages de wiki
• L’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
• Boards
• Référentiels
• Pipelines
• Test Plans
• Artefacts
• Wiki
• Génération d’états

---

Général

Thème foncé

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.

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 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 sur votre travail, déplacez les éléments le long d’un flux de travail d’état simple de To Do, Doing et Done.

Consultez la documentation sur le suivi des problèmes 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 la documentation de référence avec des pièces jointes d’élément de travail plus riches

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 supprimant 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 un aperçu et parcourez-les pour trouver rapidement les informations dont vous avez besoin.

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

ReadME du référentiel est souvent la maison à 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 pouvez utiliser un état de génération 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 code source ouvert.

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.

Effectuer des requêtes relatives au travail en fonction du 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 vient à venir ou en fonction des itérations de sprint, il est souvent intéressant de revenir au travail à travers l’objectif du calendrier pour signaler tout le travail qui s’est passé 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 sur les macros de requête.

Modifier et supprimer des commentaires de discussion

Nous sommes heureux d’annoncer la disponibilité d’une fonctionnalité de communauté des développeurs hautement votée, de modifier et de supprimer 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 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 requête au format CSV

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

Accéder aux éléments de travail Azure Boards directement à partir des mentions dans un 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 AB#{work item ID} syntaxe, ces mentions deviendront des liens hypertexte que vous pouvez cliquer pour accéder directement à 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 d’intégration GitHub d’Azure Boards.

Accepter et exécuter sur 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 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 .

Consulter 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 carte pour plus d’informations sur ce sujet et les autres annotations pour les tâches et les tests.

Référentiels

Brouillon des demandes de tirage (pull request)

Afin d’empêcher la fin des demandes de tirage 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 demandes de tirage provisoire.

Vous pouvez créer des 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 verrez un badge indiquant son état en regard du titre.

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

Relancer un build expiré pour les demandes de tirage à 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 comme les réviseurs requis, le processus d’approbation peut prendre trop de temps et une build associée peut expirer avant qu’un réviseur ait approuvé la demande de tirage. Si la demande de tirage a été définie sur la saisie semi-automatique, elle reste bloquée jusqu’à ce qu’un utilisateur ait mis manuellement en file d’attente la build expirée. Avec cette modification, la génération 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.

Remarque

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

Afficher simplement le fichier de gauche ou de droite dans une demande de tirage (pull request)

Aujourd’hui, lors de l’affichage des modifications de fichier dans une demande de tirage, vous pouvez utiliser undiff côte à côte ou un mode de différences inline. 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 la réalisation de demandes de tirage

Vous avez maintenant plus d’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 la communauté des développeurs : fusion rapide et fusion semi-linéaire (également appelée « Rebase and Merge »).

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

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.

Remarque

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

Il existe quelques situations où la rebastage pendant la saisie semi-automatique de demande de tirage n’est pas possible :

• Si une stratégie sur la branche cible interdit l’utilisation de stratégies de base, vous aurez besoin de l’autorisation « Remplacer les stratégies de branche ».
• Si la branche source de la demande de tirage a des stratégies, vous ne pourrez pas la rebaser. La 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 conflit de fusion. Les résolutions de conflit appliquées à une fusion tridirectionnel sont rarement réussies (ou même valides) lors de la rebastage de toutes les validations dans une demande de tirage en une à la fois.

Dans tous ces cas, vous avez toujours la possibilité de rebaser votre branche localement et d’envoyer (push) vers le serveur, ou squashing de fusionner vos modifications lors de la fin de la demande de tirage.

Filtrer par branche cible dans les demandes de tirage

Les demandes de tirage permettent à votre équipe d’examiner le code et de donner des commentaires 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 demandes de tirage dans l’onglet Mine .

Autoriser les extensions à ajouter la coloration syntaxique et l’auto-complétion

Actuellement, nous publions la mise en surbrillance de la syntaxe pour un sous-ensemble de langues prises 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 mise en surbrillance de la syntaxe et la saisie semi-automatique aux vues de l’Explorateur de fichiers et des demandes d’extraction.

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

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

Support amélioré pour l’encodage

Auparavant, la modification et l’enregistrement de fichiers sur le web n’enregistreraient que l’encodage UTF-8 et nous n’avons pas invité à modifier l’encodage du fichier. À 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 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 illustre la boîte de dialogue que vous verrez lorsque vous introduisez des modifications d’encodage par un push web.

Bénéficier d'un support technique dans Azure Repos

Go est un langage de programmation code source ouvert, é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 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 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 la prise en charge de Ctrl+Espace pour 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 Tâche pour l’édition de fichier YAMLs

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 tâche, sélectionnez Modifier sur un pipeline YAML, puis sélectionnez l’Assistant Tâche.

Pipelines YAML de déclencheur avec 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éclaration de 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 manière à annuler automatiquement un pipeline existant en cas de mise à jour d’une demande de tirage (pull request)

Par défaut, les pipelines déclenchés par des demandes de tirage (PR) sont annulés si une nouvelle validation est envoyée à la même demande de tirage. 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 demande de tirage.

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

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

Auparavant, nous avons case activée des 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 case activée utilisé avec des pipelines YAML.

Utilisez le path mot clé activé checkout et vous êtes en 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 est case activée transféré vers 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 case activée transféré vers 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 contributeur 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 mises en production 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 dis carte 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 d’un journal de génération

Vous pouvez désormais 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 de résultats pour obtenir une icône de lien.

Améliorations des autorisations de 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 d’extension 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 de la Place de marché de fournir des expériences de création de rapports 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 bouton *Action personnalisée.

   

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

   Vous disposez peut-être d’un large éventail de flux de travail de consommation de rapports de test et souhaiterez peut-être 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 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 à 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é 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 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 ayant échoué dans un groupe de déploiement

Par défaut, Azure Pipelines a 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 tous les travaux et en limitant les cibles ayant échoué dans une option de groupe de déploiement, la réexécutation exécute tous les travaux et ignore les déploiements vers les cibles qui sont déjà à jour.

Redéploiement automatique 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. Pour plus d’informations, consultez la documentation des groupes de déploiement.

Crochet de service 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 Deployment Completed à 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 les tâches liées à des alertes Azure Monitor

La version précédente de la tâche Requête Azure Monitors a pris en charge les alertes d’interrogation uniquement 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 en ligne du fichier de spécification 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 incluse.

Tâche d’installation de l’interface CLI de Docker

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 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 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 en cas d’échec d’une requête de création de mise en production

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 Mise en production. Cette notification vous envoie un e-mail quand une demande de création de mise en production é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 les mises en production en cas de changement de la source ou du pipeline

Auparavant, lorsque vous aviez un déclencheur de mise en production planifié, une version se déclencherait même lorsqu’aucune modification n’a été 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 de planification de 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 de création d’une mise en production

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 contribution à la boîte de dialogue Créer une nouvelle mise en production pour prendre en charge les extensions qui aideront à remplir la valeur d’une variable pendant la création de la version.

Publier dans les files d’attente de session Azure Service Bus

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

Nouvelle option d’abonnement Azure pour 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 de 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 l’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), 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 désactivé RBAC, le compte de service créé dispose d’autorisations à l’échelle du cluster sur les espaces de noms.

Registre de conteneurs Azure dans la connexion du 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.

Effectuer une recherche par nom de dossier dans les définitions de mise en production

Vous pouvez organiser vos définitions de mise en production 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 mise en production spécifique si vous aviez créé un grand nombre 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 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 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 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 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 de déploiement est case activée ed pour les objets Kubernetes déployés afin d’incorporer des case activée de stabilité tout en calculant 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 bake de la tâche permet de cuire 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 une action de déploiement entraîne la création d’un pourcentage souhaité de charges de travail suffixees avec -baseline et -canary afin qu’elles puissent être comparées pendant une ManualIntervention tâche 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 à niveau 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 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 dernières chaînes de version et semver telles que « v1.14.0 » sont acceptées comme valeurs valides pour l’entrée Kubectl Version Spec.

Améliorations de l’intégration 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 gérer 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.

Support 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 Az dans Azure PowerShell

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 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 Azure PowerShell Az ici.

Remarque

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

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 (intégré et mot de passe) 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 de longs chemins d'accès de fichier

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

Ignorer l’intégration continue (CI) pour une validation

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. [skip ci] Incluez simplement le message de validation de la validation HEAD 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 validations 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 De 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, 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 garantie de test sont essentiels pour maintenir un pipeline DevOps sain.

Le widget 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 longue duré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 pipelines 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
• Empile vos métriques par attributs de test tels que Priority ou Environment
• Regrouper des 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 des résultats de série de tests via une 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é d’URL de copie des résultats afin de pouvoir 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 l’exécution de 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.

Artifacts

Packages NuGet avec semVer 2.0.0 version numbers

Auparavant, Azure Artifacts ne prenait pas en charge les packages NuGet avec les 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, qui est indiquée 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 aux spécifications SemVer et NuGet.org stratégie, 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 dans Azure Artifacts (ou nuget.org), car ces versions seront considérées comme équivalentes et donc soumises aux contraintes d’immuabilité.

Informations sur la provenance dans 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 ou ce qui les a publiés et la validation du code source qu’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 n’a pas fourni de moyen de mesurer l’utilisation ou la popularité des packages. Avec cette mise à jour, nous avons ajouté un nombre de téléchargements et d’utilisateurs aux pages de détails de package et de liste de packages. Vous pouvez voir les statistiques sur le côté droit de l’une ou l’autre des pages.

Prise en charge des packages Python

Azure Artifacts peut désormais héberger des packages Python : les deux 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 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 amont Maven à un flux existant, visitez les paramètres de flux, sélectionnez le tableau croisé dynamique des sources en amont, puis sélectionnez Ajouter amont source.

Prise en charge de proxy pour les tâches liées à Artifacts

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 push de restauration et 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 package Artifacts pris en charge dans les mises en production

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

Affichages d’artefacts pris en charge dans les mises en production

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 mises en production lorsque les 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 cette propre-up. Pour activer, modifiez votre flux et case activée les packages Skip téléchargés récemment case activée box.

Délégué pouvant gérer les flux

Dans Azure Artifacts, la collection de projets Administration istrators (PCA) a 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, en déléguant ainsi la possibilité de gérer n’importe quel flux.

Wiki

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

Il n’est plus nécessaire de mémoriser la syntaxe markdown pour ajouter des formules, des vidé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 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.

Police monospaced 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é 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 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 demande de tirage et les discussions sur les tableaux affichent également l’état.

@mention utilisateurs et groupes

Vous pouvez désormais @mention utiliser 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 sprint avec des tâches et la personne responsable.

@mention utilisateurs et groupes ». />

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.

@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 de 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é hiérarchisé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 à l’aide des balises de détails et de résumé . Vous pouvez ajouter l’attribut ouvert 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.

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

Création et modification améliorées de 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 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 table pour wiki
   • Simplifier l’insertion de tables dans wiki

2. Meilleure lisibilité des tables

   Vous pouvez désormais activer/désactiver le retour à la ligne du mot pour que votre éditeur dispose d’une meilleure lisibilité de vos tables. La désactivation de l’habillage de mot ajoute une barre de défilement qui vous permet de voir plus facilement le contenu des tables volumineuses.

   

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 tableaux , 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 le retour à la ligne pour faciliter la lecture des tableaux.

   

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

Reporting

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 le 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 à la collection de projets Paramètres :

2. Cliquez sur Activer Analytics

C’est tout ! Les expériences optimisées pour l’analyse sont 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 l’activation d’Analytics.
• Lisez la documentation de vue d’ensemble d’Analytics.
• Lisez les principales fonctionnalités : Widgets d’analytique, rapport de test défaillant principal, intégration De Power BI et point de terminaison OData.
• Regardez cette vidéo Channel 9 sur Azure DevOps Analytics.

---

Retours d'expérience

Nous sommes à votre écoute ! Vous pouvez signaler un problème ou fournir une idée et le suivre via la Communauté des développeurs et obtenir des conseils sur Stack Overflow.

---

Haut de page