Notes de publication Azure DevOps Server 2019

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

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

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

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

---

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

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

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

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

Date de publication d’Azure DevOps Server 2019.0.1 Patch 16 : 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.

Installer les correctifs

Configurer TFX

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

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

File	Hachage SHA-256
Tasks20231103.zip	389BA66EEBC32622FB83402E21373CE20AE040F70461B9F9AF9EFCED5034D2E5

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

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

Exigences relatives aux pipelines

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

• Sur classique :

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

• Exemple YAML :

variables: 
- name: AZP_75787_ENABLE_NEW_LOGIC 
  value: true 

Date de publication d’Azure DevOps Server 2019.0.1 Patch 15 : 12 septembre 2023

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

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

Installer les correctifs

1. Téléchargez et installez Azure DevOps Server 2019.0.1 Patch 15.

Mettre à jour l’agent Azure Pipelines

1. Téléchargez l’agent à partir de : https://github.com/microsoft/azure-pipelines-agent/releases/tag/v3.225.0 - Agent_20230825.zip
2. Utilisez les étapes décrites dans la documentation des agents Windows auto-hébergés pour déployer l’agent.  

Configurer TFX

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

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

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

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

Exigences relatives aux pipelines

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

• Sur classique :

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

• Exemple YAML :

variables: 
- name: AZP_75787_ENABLE_NEW_LOGIC 
  value: true 

Date de publication d’Azure DevOps Server 2019.0.1 Patch 14 : 8 août 2022

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

• CVE-2023-36869 : Vulnérabilité d’usurpation d’identité azure DevOps Server.

Date de publication d’Azure DevOps Server 2019.0.1 Patch 13 : 17 mai 2022

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

• 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.0.1 Patch 12 : 26 janvier 2022

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

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

1. Mettez à niveau le serveur avec le correctif 12.
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 : 96C7AF3E3ED67C76451BA228427B3C0738EEB4A5835B6A91EBD3205A54C384D7

Date de publication d’Azure DevOps Server 2019.0.1 Patch 11 : 10 août 2021

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

• Corrigez l’erreur de l’interface utilisateur de définition de build.

Date de publication d’Azure DevOps Server 2019.0.1 Patch 10 : 13 avril 2021

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

• CVE-2021-27067 : divulgation d’informations

Pour appliquer le correctif 10, vous devez installer la AzureResourceGroupDeploymentV2 tâche.

Installation de tâche AzureResourceGroupDeploymentV2

Installer

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

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

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

npm install -g tfx-cli

4. Créez un jeton d’accès personnel avec des privilèges d’accès 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.0.1 Patch 9 : 8 décembre 2020

Nous avons publié un correctif pour Azure DevOps Server 2019.0.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 Server
• 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.0.1, vous devez installer Azure DevOps Server 2019.0.1 Patch 9.

Vérification de l’installation

• Option 1 : Exécuter devops2019.0.1patch9.exe CheckInstall, devops2019.0.1patch9.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.0.1 Patch 9, la version sera 17.143.30723.4 .

Installation de tâche AzurePowerShellV4

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 (1)\AzurePowerShellv4.

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

Date de publication d’Azure DevOps Server 2019.0.1 Patch 8 : 8 septembre 2020

Nous avons publié un correctif de sécurité pour Azure DevOps Server 2019.0.1 qui corrige les correctifs suivants. 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.0.1 Patch 7 : 14 juillet 2020

Nous avons publié un correctif de sécurité pour Azure DevOps Server 2019.0.1 qui corrige les correctifs suivants. 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.0.1 Patch 6 : 10 juin 2020

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

• CVE-2020-1327 : Vérifiez qu’Azure DevOps Server nettoie les entrées utilisateur
• Ajout de la prise en charge de SHA2 dans SSH sur Azure DevOps

Date de publication d’Azure DevOps Server 2019.0.1 Patch 5 : 10 mars 2020

Nous avons publié un correctif de sécurité pour Azure DevOps Server 2019.0.1 qui corrige les correctifs 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.0.1 Patch 3 : 10 septembre 2019

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

• CVE-2019-1305 : Vulnérabilité aux scripts de site à site (XSS) dans Azure Repos
• CVE-2019-1306 : Vulnérabilité d’exécution de code à distance dans le Wiki

---

Date de publication d’Azure DevOps Server 2019.0.1 Patch 2 : 13 août 2019

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

• Nous avons ajouté des informations aux connexions de service pour clarifier qu’elles sont autorisées pour tous les pipelines par défaut.

---

Date de publication d’Azure DevOps Server 2019.0.1 Patch 1 : 9 juillet 2019

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

• CVE-2019-1072 : Vulnérabilité de l’exécution de code à distance dans le suivi des éléments de travail
• CVE-2019-1076 : Vulnérabilité de script intersite (XSS) dans les demandes de tirage

---

Date de publication d’Azure DevOps Server 2019.0.1 : 21 mai 2019

Azure DevOps Server 2019.0.1 est un cumul de correctifs de bogues. Il inclut tous les correctifs dans les correctifs Azure DevOps Server 2019 précédemment publiés. Vous pouvez installer directement Azure DevOps Server 2019.0.1 ou effectuer une mise à niveau à partir d’Azure DevOps Server 2019 ou Team Foundation Server 2012 ou version ultérieure.

Cette version inclut les corrections des bugs suivants :

Azure Boards

• « Les critères de champ de ce plan ont une erreur . » lors de la configuration d’un plan. Signalé par le biais de la communauté des développeurs.
• apiwitcontroller.executequery lève une exception lorsqu’une requête a la même colonne plusieurs fois.
• Dans le modèle objet client à l’aide de l’étendue oauth vso.work_full, WorkItemServer.DownloadFile() échoue.
• La copie d’une image incorporée à partir d’un champ d’élément de travail vers un autre champ d’élément de travail dans un autre projet peut créer une image interrompue.

Azure Repos

• « TF401019 : GitRepositoryNotFoundException ».

Azure Pipelines

• L’onglet Analyse de test a une étoile (*) qui indique l’aperçu, même si cette fonctionnalité n’est pas en préversion.
• Sous l’onglet Versions , l’action de gestion de la sécurité s’affiche désormais à tous les utilisateurs, qu’ils puissent modifier les autorisations ou non.
• Sur les pages d’accueil Releases, l’action de démarrage de la version préliminaire a créé une nouvelle version, mais elle démarre maintenant le brouillon de version.

Azure Test Plans

• Le filtre de 1 heure sur TestRuns et TestResults CompletedDate est trop granulaire.
• Dans le type d’élément de travail Test Case , le type « Test Case » ne doit pas être localisé.
• Les cas de test ne s’affichent pas dans MTM ou dans un navigateur.
• « Phase de validation : vous n’êtes pas autorisé à déclencher des mises en production sur le pipeline de mise en production associé » lors de l’exécution de tests automatisés à partir d’un plan de test. Signalé par le biais de la communauté des développeurs.
• À l’aide de l’API de cas de test de suppression, les cas de test peuvent être supprimés d’autres projets. Signalé par le biais de la communauté des développeurs.
• Cliquer sur un lien d’élément de travail dans Test Runner ouvre l’URL de l’élément de travail dans Test Runner au lieu du navigateur par défaut.
• L’état du cas de test n’est pas mis à jour pour les utilisateurs qui se déconnectent de Test Runner.
• Le nom d’utilisateur et l’adresse e-mail ne s’affichent pas dans la liste déroulante utilisateur de Test Runner.

Azure Artifacts

• Déplacer vers le haut et descendre ne sont pas localisés dans les amonts.

Analyse

• Les rapports d’analyse peuvent afficher des données incomplètes, car le modèle est marqué comme « prêt » avant qu’il ne soit réellement terminé.
• Les widgets vitesse, burndown et burnup affichent différents travaux planifiés pour les utilisateurs sur différents fuseaux horaires.
• Une conservation peut être placée sur l’ingestion des données Analytics lors de la maintenance, ce qui peut entraîner des rapports obsolètes.

Général

• Les éléments de navigation gauche sont pressés sur Internet Explorer lorsqu’il n’y a pas suffisamment d’espace.

Administration

• Journalisation supplémentaire ajoutée à la mise à niveau de collection pour aider à résoudre les problèmes de débogage.
• Lorsque TfsConfig offlineDetach échoue, le message d’erreur n’est pas actionnable.
• Le service TfsJobAgent se bloque.
• L’extension de recherche n’est pas installée une fois la configuration terminée.
• La console d’administration ne répond plus lorsque la base de données de configuration est endommagée.
• Les hooks de service peuvent ne pas traiter correctement les notifications.
• L’indexation de recherche de code ne démarre pas après la configuration de la recherche.
• Il existe des chaînes non localisées dans les résultats des pages de recherche.

Cette version inclut la mise à jour suivante :

Prise en charge de Visual Studio 2019 (VS2019) dans la tâche de test Visual Studio

Nous avons ajouté la prise en charge de Visual Studio 2019 à la tâche de test Visual Studio dans les pipelines. Pour exécuter des tests à l’aide de la plateforme de test pour Visual Studio 2019, sélectionnez les options les plus récentes ou Visual Studio 2019 dans la liste déroulante des versions de la plateforme de test.

---

Date de publication d’Azure DevOps Server 2019 Patch 2 : 14 mai 2019

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

• CVE-2019-0872 : Vulnérabilité liée aux scripts intersites (XSS) dans Test Plans
• CVE-2019-0971 : Vulnérabilité sur la divulgation d’informations dans l’API Repos
• CVE-2019-0979 : Vulnérabilité liée aux scripts intersites (XSS) dans le hub Utilisateur

---

Date de publication d’Azure DevOps Server 2019 Patch 1 : 9 avril 2019

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

• CVE-2019-0857 : Vulnérabilité d’usurpation d’identité dans le Wiki
• CVE-2019-0866 : Vulnérabilité liée à l’exécution de code à distance dans Pipelines
• CVE-2019-0867 : Vulnérabilité liée aux scripts intersites (XSS) dans Pipelines
• CVE-2019-0868 : Vulnérabilité liée aux scripts intersites (XSS) dans Pipelines
• CVE-2019-0869 : vulnérabilité d’injection HTML dans Pipelines
• CVE-2019-0870 : Vulnérabilité liée aux scripts intersites (XSS) dans Pipelines
• CVE-2019-0871 : Vulnérabilité liée aux scripts intersites (XSS) dans Pipelines
• CVE-2019-0874 : Vulnérabilité de script intersites (XSS) dans Pipelines
• CVE-2019-0875 : Vulnérabilité d’élévation de privilèges dans les tableaux

---

Date de publication d’Azure DevOps Server 2019 : 5 mars 2019

---

Date de publication RC2 : 22 janvier 2019

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

Nous avons ajouté les fonctionnalités suivantes à RC2 :

• Lier des validations GitHub Enterprise et des demandes de tirage à des éléments de travail Azure Boards
• Configurer des builds à l’aide de YAML
• Les annotations de carte incluent des bogues et des types d’éléments de travail personnalisés
• Sélecteur de branches amélioré
• Modifications apportées aux licences de pipeline de déploiement d’artefacts et de gestion des mises en production

---

Date de publication RC1 : 19 novembre 2018

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

Azure DevOps Server 2019 introduit une nouvelle expérience de navigation et de nombreuses nouvelles fonctionnalités. Voici les principales :

• Nouvelle expérience de navigation
• L’extension de la Place de marché Analytics pour la création de rapports est désormais disponible
• Prise en charge d’Azure SQL Database
• Traiter l’héritage sur les nouvelles collections
• Nouveau hub Éléments de travail
• Nouveaux tableaux, backlogs et hubs Sprints
• Nouveau hub de requêtes
• Normaliser les descriptions des demandes de tirage à l’aide de modèles
• Modifier la branche cible d’une demande de tirage (pull request)
• Gérer les pipelines de build à l’aide de la nouvelle page Builds
• Gérer les pipelines de mise en production à l’aide de la nouvelle page Versions
• Visualiser la progression de la mise en production
• Mettre à jour localement votre agent
• Exposer et phaser progressivement des déploiements à l’aide de portes de mise en production
• Sources en amont
• Créer une table des matières pour les pages wiki

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

Annonce d’Azure DevOps Server

Le 10 septembre, nous avons annoncé Azure DevOps comme évolution de Visual Studio Team Services et team Foundation Server. Azure DevOps Server 2019 est notre première version locale avec cette nouvelle marque. Vous trouverez plus d’informations dans notre billet de blog.

Nouvelle expérience de navigation

Nous introduisons une nouvelle navigation pour moderniser l’expérience utilisateur. Cette nouvelle navigation s’est déployée sur le service Azure DevOps et est désormais disponible dans Azure DevOps Server 2019. Pour plus d’informations, consultez notre blog .

Modifications apportées aux licences de pipeline de déploiement d’artefacts et de gestion des mises en production

En fonction des commentaires des utilisateurs, nous apportons deux modifications clés à nos licences avec Azure DevOps Server 2019. Tout d’abord, les clients n’auront plus besoin d’acheter l’extension Artifact pour utiliser Artifacts. Une licence Artifacts sera désormais incluse dans la licence de base. Tous les utilisateurs disposant d’une licence de base leur seront désormais en mesure d’utiliser des artefacts. Deuxièmement, les clients ne seront plus obligés d’acheter des pipelines de déploiement Release Management. Tout comme les pipelines de build, les pipelines de déploiement release Management sont désormais inclus dans Azure DevOps Server 2019.

Prise en charge d’Azure SQL Database

Pour simplifier l’expérience d’exécution d’Azure DevOps 2019 dans Azure, nous avons activé la prise en charge d’Azure SQL Database (usage général S3 et versions ultérieures). Cela vous permettra de tirer parti des fonctionnalités de sauvegarde étendues et des options de mise à l’échelle en fonction de vos besoins tout en réduisant la surcharge administrative liée à l’exécution du service. Notez que votre machine virtuelle hôte doit se trouver dans la même région Azure que votre base de données afin de maintenir la latence faible. Pour plus d’informations, consultez la documentation.

Élément de travail & tester les API SOAP du modèle objet client dans les futures versions

Azure DevOps Server 2019 continue de prendre en charge l’API SOAP de suivi des éléments de travail et le modèle objet client. Toutefois, elle sera marquée comme déconseillée dans les futures versions d’Azure DevOps Server. Vous trouverez plus d’informations dans notre documentation.

Traiter l’héritage sur les nouvelles collections

L’héritage de processus est désormais disponible sur les nouvelles collections. Les utilisateurs devront prendre une décision de conscience sur le modèle de processus lors de la création d’une collection. Consultez notre documentation sur ce que le modèle d’héritage est et sur la façon dont il est différent de XML.

Zone de recherche étendue

Nous comprenons l’importance de la recherche et revenons à la zone de recherche développée sur l’en-tête de produit. En outre, vous pouvez maintenant appeler la zone de recherche en cliquant simplement sur « / » sur n’importe quelle page de service dans Azure DevOps.

Voici la zone de recherche par défaut :

Une fois que vous avez tapé un « / », la zone de recherche développée s’affiche :

Mon menu volant professionnel

Une nouvelle fonctionnalité que nous sommes très heureux d’introduire est le menu volant de mon travail . Nous avons entendu des commentaires indiquant que lorsque vous êtes dans une partie du produit et que vous souhaitez obtenir des informations d’une autre partie, vous ne souhaitez pas perdre votre contexte. Avec cette nouvelle fonctionnalité, vous pouvez accéder à ce menu volant n’importe où dans le produit et vous donnera un aperçu rapide des informations cruciales, notamment vos éléments de travail, vos demandes de tirage et tous les favoris. Avec ce nouveau menu volant, si vous êtes dans repos en bas dans votre code, mais que vous souhaitez vérifier rapidement l’élément de travail sur lequel vous devez travailler ensuite, vous pouvez simplement cliquer sur le menu volant et voir les éléments de travail affectés à vous et récupérer l’élément suivant.

Vous pouvez voir ci-dessous le menu volant mon travail montrant les éléments de travail qui m’ont été attribués :

Ici, vous pouvez voir le deuxième pivot qui montre les demandes de tirage affectées à moi. Dans le menu volant, vous avez également un accès en un clic pour afficher d’autres demandes de tirage :

Ici, vous pouvez voir le dernier pivot, qui est tout ce que vous avez préféré. Cela inclut vos équipes préférées, tableaux de bord, tableaux de bord, backlogs, requêtes et référentiels :

Boards

Lier des validations GitHub Enterprise et des demandes de tirage à des éléments de travail Azure Boards

Teams qui utilisent GitHub Enterprise pour le code et veulent des fonctionnalités de gestion de projet enrichies peuvent désormais intégrer leurs référentiels à Azure Boards. En connectant GitHub et Azure Boards, vous pouvez obtenir toutes les fonctionnalités telles que les backlogs, les tableaux, les outils de planification sprint, plusieurs types d’éléments de travail et avoir toujours un flux de travail qui s’intègre aux flux de travail des développeurs dans GitHub.

La liaison de validations et de demandes de tirage à des éléments de travail est facile. Mentionnez l’élément de travail à l’aide de la syntaxe suivante :

AB#{work item ID}

Mentionnez un élément de travail dans un message de validation, un titre de demande de tirage (pull request title) ou une description de la demande de tirage (pull request) et Azure Boards crée un lien vers cet artefact. Par exemple, considérez un message de validation comme suit :

Adds support for deleting connections. Fixes AB#20.

Cela crée un lien à partir de l’élément de travail #20 vers la validation dans GitHub, qui apparaît dans la section Développement de l’élément de travail. ​

Si les mots « correctif », « correctifs » ou « fixes » précèdent la mention d’élément de travail (comme indiqué ci-dessus), l’élément de travail est déplacé vers l’état terminé lorsque la validation est fusionnée vers le branche par défaut.

Les équipes qui utilisent Azure Pipelines pour générer du code dans GitHub verront également les éléments de travail liés à leurs validations GitHub dans le résumé de la build.

Nouveau hub Éléments de travail

Le Hub Éléments de travail est notre nouveau hub qui servira de maison de vos éléments de travail ! Ici, vous avez de nombreuses vues de liste différentes de vos éléments de travail qui sont délimités pour vous. Vous pouvez voir Affecté à moi pour obtenir rapidement un coup d’œil sur tout le travail affecté à vous ou récemment mis à jour, ce qui vous montre tous les éléments de travail de votre projet qui ont été récemment mis à jour . Toutes vos options de liste sont visibles ci-dessous :

Si vous souhaitez étendre vos listes encore plus loin, vous pouvez filtrer sur le type, l’état, la zone, les balises et le mot clé. Une fois que vous avez votre affichage de liste souhaité, vous pouvez ensuite trier les éléments de travail en cliquant simplement sur l’en-tête de la colonne. Si une colonne est trop étroite pour afficher le contenu complet de la colonne, vous pouvez facilement redimensionner la colonne dans la zone d’en-tête. Ces expériences sont visibles ci-dessous :

Nouveaux tableaux, backlogs et hubs Sprints

Le hub Backlogs a été divisé en trois hubs distincts pour améliorer l’expérience utilisateur. Bien que puissant, l’ancien hub Backlogs accueillait trop de fonctionnalités. Cela a souvent rendu difficile la recherche des fonctionnalités ou des utilisateurs de fonctionnalités. Pour résoudre ce problème, nous avons fractionné le hub Backlogs en :

• Le hub Backlogs abrite désormais uniquement les backlogs d’un projet. Un backlog est une liste de travail hiérarchisée pour l’équipe. Les backlogs fournissent des outils de planification tels que la hiérarchie des éléments de travail, la prévision et une nouvelle expérience de planification sprint.
• Le nouveau hub Boards abrite tous les tableaux Kanban pour un projet. Les tableaux sont utilisés pour communiquer l’état et le flux. Les cartes (éléments de travail) passent de gauche à droite dans le tableau à travers les colonnes définies par l’équipe.
• Le nouveau hub Sprints abrite les fonctionnalités utilisées pour planifier et exécuter un incrément de travail. Chaque sprint contient un backlog sprint, un tableau des tâches et une vue pour gérer et définir la capacité de l’équipe.

Nouveau hub de requêtes

Le nouveau hub de requêtes simplifie la plupart des fonctionnalités de requêtes existantes à partir de l’ancien hub avec une apparence plus moderne, ainsi que de nouvelles fonctionnalités pour faciliter l’accès aux requêtes qui sont importantes pour vous. Voici quelques points forts de la nouvelle expérience :

• Pages d’annuaire avec dernière modification par les informations et possibilité de rechercher des requêtes
• Barre de navigation avec URL uniques pour les dossiers afin de marquer des groupes importants de requêtes
• Accès rapide à vos requêtes favorites à partir de la page de résultats

En savoir plus sur ces mises à jour passionnantes sur notre blog DevOps.

Déplacer des éléments de travail vers un autre projet et modifier un type d’élément de travail

Vous pouvez maintenant modifier le type d’élément de travail ou déplacer des éléments de travail vers un autre projet au sein d’une collection de projets. Ces fonctionnalités nécessitent que l’entrepôt de données soit désactivé. Une fois l’entrepôt de données désactivé, vous pouvez utiliser le service Analytics pour prendre en charge vos besoins en matière de création de rapports. Pour en savoir plus sur la désactivation de l’entrepôt de données, consultez Désactiver l’entrepôt de données et le cube.

Fonctionnalités de planification sprint

Les nouvelles fonctionnalités de planification sprint permettent d’accélérer et d’améliorer l’expérience de planification de sprint.

• Créez votre sprint suivant ou abonnez-vous à une planification de sprint existante directement à partir du hub Sprints .
• Utilisez le nouveau volet Planification de votre backlog pour faire glisser et déplacer des éléments de travail dans les sprints futurs. Le volet Planification inclut les dates de sprint, le nombre d’éléments de travail et l’effort planifié.
• Ajoutez des exigences en haut du tableau des tâches ou utilisez la création rapide pour ajouter au haut, au bas ou à la ligne de choix de votre backlog sprint.
• Utilisez des filtres pour Assignee, Work Item Type, State et Tags pour adapter les vues à vos besoins.

Nouvelles pages d’annuaire

Tous les nouveaux hubs, notamment Backlogs, Boards et Sprints, ont désormais de nouvelles pages d’annuaire organisées avec les sections suivantes :

• Continuer là où vous avez quitté cette nouvelle section vous fournit un lien rapide directement vers le dernier (Tableau | Backlog | Sprint) vous étiez sur.
• Favoris Tous vos tableaux préférés , sprints et backlogs dans toutes les équipes.
• Mes tableaux, backlogs et sprints pour les équipes auxquelles vous appartenez.
• Liste complète de tous vos tableaux, backlogs et sprints.

Menu Options d’affichage

Les nouveaux hubs, notamment Backlogs, Boards et Sprints, ont un nouveau menu Options d’affichage. Il s’agit d’une nouvelle page d’accueil pour toutes les actions permettant de personnaliser le contenu de la mise en page et de la mise en page. Utilisez les options d’affichage pour activer des vues supplémentaires, telles que l’affichage de la hiérarchie dans les backlogs ou la modification de l’option Group By dans un tableau des tâches, pour activer le panneau latéral pour le mappage et la planification des sprints, ou pour explorer les graphiques de détails de travail.

En savoir plus sur ces mises à jour passionnantes, le nouveau volet Profil d’équipe et les Favoris sur notre blog DevOps.

Les annotations de carte incluent des bogues et des types d’éléments de travail personnalisés

Les annotations de carte sont appréciées pour leur affichage de liste de vérification intuitive et leur interaction. Auparavant, les annotations de carte étaient limitées aux types de niveau de backlog par défaut et ne prenaient pas en charge les bogues ou les types personnalisés. Avec la nouvelle version, nous avons supprimé la restriction sur les types d’éléments de travail et ajouté la possibilité d’afficher les bogues et tout type d’élément de travail personnalisé en tant qu’annotation de carte.

Les paramètres de carte pour les annotations de carte ont été développés pour inclure tous les types d’éléments de travail disponibles pour ce niveau de backlog.

Lorsque les annotations pour l’élément de travail sont activées, le nombre de ce type d’élément de travail est inclus dans la carte sous la forme d’une liste de vérification distincte.

La création rapide de types d’éléments de travail activés est également disponible via le menu contextuel de carte.

Déplacer le travail à l’aide des zones et itérations suggérées

Il peut être courant de travailler dans la même zone ou itération et parcourir à plusieurs reprises les hiérarchies lors du déplacement d’éléments de travail. Les contrôles de chemin d’accès zone et itération incluent désormais une liste de valeurs récemment utilisées en tant que suggestions, ce qui vous donne un accès rapide pour définir et passer à l’action.

En outre, les dates d’itération sont incluses à droite du nom afin que vous puissiez rapidement juger quand un élément de travail doit être remis.

Interroger le travail sur l’ensemble de la planification d’itération avec +/- @CurrentIteration

La macro qui aide votre équipe à suivre le @CurrentIteration travail en fonction de votre planification d’itération prend désormais en charge le décalage entier. Gardez facilement des onglets sur le travail qui n’a pas été fermé avec @CurrentIteration - 1, ou regardez le travail prévu pour les itérations futures avec @CurrentIteration + 1. Pour plus d’informations, consultez le billet @CurrentIteration sur le blog Microsoft DevOps.

Clarifier les planifications d’itération des requêtes avec le @CurrentIteration paramètre Team

Si vous avez utilisé la macro dans les @CurrentIteration requêtes dans le passé, vous avez peut-être remarqué que les résultats peuvent varier si le contexte d’équipe change dans Teams avec des planifications d’itération différentes. À présent, lorsque vous créez ou modifiez une requête avec la @CurrentIteration macro, vous devez également sélectionner l’équipe avec la planification d’itération qui est pertinente pour la requête. Avec le paramètre Team, vous pouvez utiliser la @CurrentIteration macro dans la même requête, mais entre les équipes. Un exemple peut être une requête pour les éléments de travail dans deux projets d’équipe différents utilisant des noms d’itération différents et même des planifications. Cela signifie qu’il n’est plus nécessaire de mettre à jour les requêtes au fur et à mesure que les sprints changent ! Pour plus d’informations, consultez le billet @CurrentIteration sur le blog Microsoft DevOps.

Interroger le travail dans les chemins d’accès de zone d’une équipe avec la nouvelle @TeamAreas macro

Dans les paramètres d’une équipe, vous pouvez associer un ou plusieurs chemins d’accès de zone, ce qui vous permet de concentrer les backlogs, les tableaux de bord, les plans, même les tableaux de bord au travail de cette équipe. Si vous souhaitez écrire une requête pour une équipe, vous devez répertorier les chemins d’accès de zone spécifiques pour cette équipe dans les clauses de requête. À présent, une nouvelle macro @TeamAreas est disponible pour vous permettre de référencer facilement les chemins d’accès de zone appartenant à l’équipe spécifiée.

Requête pour les champs de texte enrichi vides

Recherchez les éléments de travail qui ont un champ de texte enrichi vide, tel que Description, à l’aide de la nouvelle opérateur de requête IsEmpty .

Trouver facilement des éléments de travail existants dans les expériences de liaison et de mention

Lorsque vous souhaitez lier deux éléments de travail existants ensemble, vous pouvez maintenant trouver facilement l’élément qui est important pour vous à l’aide de notre nouveau contrôle de recherche d’élément de travail. Le sélecteur de requête a été remplacé par des suggestions inline basées sur vos éléments de travail récemment consultés, ainsi qu’un point d’entrée pour rechercher un élément de travail spécifique par ID ou titre.

Ouvrir les éléments de travail à partir de la recherche

Auparavant, un élément de travail n’a pas pu être ouvert à partir de la page des résultats de la recherche si le volet d’aperçu de l’élément de travail a été désactivé. Cela rendait difficile l’analyse de vos résultats de recherche. Vous pouvez maintenant cliquer sur le titre de l’élément de travail pour ouvrir les éléments de travail dans une fenêtre modale.

Référentiels

Sélecteur de branches amélioré

La plupart des expériences dans Azure Repos vous obligent à sélectionner un dépôt, puis une branche dans ce référentiel. Pour améliorer cette expérience pour les organisations avec un grand nombre de branches, nous déployons un nouveau sélecteur de succursales. Le sélecteur vous permet désormais de sélectionner vos branches préférées ou de rechercher rapidement une branche.

Recevoir des notifications lorsque les stratégies de demande de tirage sont ignorées

Pour les équipes qui utilisent des demandes de tirage (PR) et des stratégies de branche, il peut arriver que les utilisateurs doivent remplacer et contourner ces stratégies , par exemple lors du déploiement d’un correctif logiciel sur un problème de production au milieu de la nuit. Il est judicieux de faire confiance aux développeurs pour faire la bonne chose et d’utiliser la fonctionnalité de remplacement avec parcimonie. En même temps, les équipes ont besoin d’un moyen de vérifier que ces remplacements de stratégie sont utilisés dans les bonnes situations. Pour ce faire, nous avons ajouté un nouveau filtre de notification pour permettre aux utilisateurs et aux équipes de recevoir des alertes par e-mail chaque fois qu’une stratégie est contournée. Commencez par la demande de tirage a été créée ou mise à jour , puis sélectionnez Contournement de stratégie dans la liste des filtres. Les stratégies sélectionnées ont été ignorées en tant que valeur et vous serez averti chaque fois qu’une demande de tirage est terminée, et les stratégies sont ignorées.

Autoriser le contournement des stratégies de branche sans renoncer à la protection Push

Il existe de nombreux scénarios où vous avez parfois besoin de contourner une stratégie de branche : restauration d’une modification à l’origine d’un arrêt de build, application d’un correctif logiciel au milieu de la nuit, etc. Auparavant, nous avons proposé une autorisation (« Exempt de l’application des stratégies ») pour aider les équipes à gérer les utilisateurs auxquels les utilisateurs ont accordé la possibilité de contourner les stratégies de branche lors de la fin d’une demande de tirage. Toutefois, cette autorisation a également accordé la possibilité d’envoyer directement à la branche, en contournant entièrement le processus de demande de tirage.

Pour améliorer cette expérience, nous avons divisé l’ancienne autorisation pour offrir davantage de contrôle aux équipes qui accordent des autorisations de contournement. Il existe deux nouvelles autorisations pour remplacer l’ancienne :

1. Contourner les stratégies lors des demandes de tirage. Les utilisateurs disposant de cette autorisation pourront utiliser l’expérience « Remplacer » pour les demandes de tirage.
2. Contourner les stratégies lors de l’envoi. Les utilisateurs disposant de cette autorisation pourront envoyer (push) directement aux branches dont les stratégies requises sont configurées.

En accordant la première autorisation et en refusant la seconde, un utilisateur sera en mesure d’utiliser l’option de contournement si nécessaire, mais aura toujours la protection contre la transmission accidentelle vers une branche avec des stratégies.

Pour plus d’informations, consultez la documentation Définir les autorisations de branche.

Décrire rapidement les demandes de tirage à l’aide de messages de validation

L’écriture de messages de validation descriptifs ajoute de la valeur à l’historique de n’importe quel dépôt Git. Pour encourager les messages de validation de qualité, les nouvelles demandes de tirage (PULL) qui ont plusieurs validations nécessitent que les contributeurs entrent manuellement un titre.

Les descriptions des demandes de tirage continuent d’être vides par défaut, mais une nouvelle fonctionnalité facilite l’incorporation des messages de validation des validations des validations dans la description de la demande de tirage. Pour ajouter les messages de validation, cliquez simplement sur Ajouter des messages de validation pour ajouter les messages de validation à la fin du texte de description de la demande de tirage.

Créer des demandes de tirage sans équipe par défaut en tant que réviseur

Lors du premier lancement de l’expérience de demande de tirage (PR), nous avons pensé qu’il serait judicieux d’affecter tous les PRS au contexte d’équipe que vous aviez sélectionné lors de la création de la demande de tirage. Ce comportement a été un point de frustration, car beaucoup de personnes n’ont pas remarqué la connexion entre le contexte de l’équipe et l’affectation de demande de tirage.

Dans le cadre des nouvelles modifications de navigation, nous avons profité de la possibilité de modifier cette association par défaut avec les équipes. Vous remarquerez deux modifications :

1. Lors de la création d’une demande de tirage, aucun réviseur n’est ajouté par défaut. La liste des réviseurs dispose d’une fonctionnalité permettant d’ajouter plus facilement des individus et des groupes qui ont été ajoutés aux demandes de tirage récemment. La stratégie des réviseurs requis peut également aider les équipes qui souhaitent s’assurer que des réviseurs spécifiques sont ajoutés pour passer en revue leur code.
2. Le hub Pull Requests a une nouvelle section personnalisable. Par défaut, cette section affiche les demandes de tirage « Affectées à mes équipes », fournissant des fonctionnalités équivalentes à l’ancienne section. Toutefois, si vous appartenez à plusieurs équipes, cette section affiche les demandes de tirage attribuées à l’une de vos équipes. La section est également personnalisable. Cliquez simplement sur l’action « Personnaliser cette vue » près de l’en-tête de section.

Normaliser les descriptions des demandes de tirage à l’aide de modèles

L’écriture de descriptions de bonnes demandes de tirage est un excellent moyen d’aider les réviseurs à savoir ce qu’il faut attendre lors de l’examen du code. Il s’agit également d’un excellent moyen de suivre ce qui doit être effectué pour chaque modification, comme les tests, l’ajout de tests unitaires et la mise à jour de la documentation. Bon nombre d’entre vous demandent que nous ajoutions des modèles de demande de tirage pour faciliter l’écriture de grandes descriptions par les équipes, et nous avons maintenant ajouté cette fonctionnalité.

En plus de prendre en charge un modèle de description de demande de tirage par défaut, les équipes peuvent ajouter plusieurs modèles, qui sont présentés à vous dans un menu de la page créer une demande de tirage. Cliquez simplement sur le bouton Ajouter un modèle pour choisir parmi n’importe quel modèle dans le référentiel pour l’ajouter à la description de la demande de tirage.

Les modèles spécifiques à une branche sont également pris en charge si vous souhaitez appliquer un autre modèle pour une demande de tirage dans une branche spécifique ou un dossier de branche. Par exemple, si vous souhaitez avoir un modèle spécifique à toutes les branches qui commencent par « correctif logiciel / », vous pouvez ajouter un modèle qui sera utilisé pour tous les PR dans ces branches.

Consultez la documentation des modèles de demande de tirage (pull request) pour en savoir plus sur la création et l’utilisation de modèles.

Modifier la branche cible d’une demande de tirage (pull request)

Pour la plupart des équipes, presque toutes les demandes de tirage ciblent la même branche, telle que main ou develop. Toutefois, dans le cas où vous devez cibler une autre branche, il est facile d’oublier de modifier la branche cible par défaut. Avec la nouvelle fonctionnalité permettant de modifier la branche cible d’une demande de tirage active, il s’agit maintenant d’une action simple. Cliquez simplement sur l’icône de crayon près du nom de la branche cible dans l’en-tête de demande de tirage.

Au-delà de la correction d’erreurs, la fonctionnalité permettant de modifier les branches cibles facilite également la « reciblage » d’une demande de tirage lorsque la branche cible a été fusionnée ou supprimée. Envisagez un scénario dans lequel vous avez une demande de tirage ciblant un branche de fonctionnalité qui contient certaines fonctionnalités dont dépendent vos modifications. Vous souhaitez passer en revue vos changements dépendants isolés des autres modifications de la branche de fonctionnalité, de sorte que vous ciblez features/new-featureinitialement . Les réviseurs peuvent alors voir uniquement vos modifications et laisser les commentaires appropriés.

Maintenant, envisagez ce qui se passerait si le branche de fonctionnalité avait également une demande de tirage active et a été fusionné main avant vos modifications ? Auparavant, vous devrez abandonner vos modifications et créer une nouvelle demande de tirage dans main, ou fusionner votre demande de tirage features/new-feature, puis créer une autre demande de tirage à mainpartir de features/new-feature . Avec cette nouvelle action pour mettre à jour la branche cible, vous pouvez simplement modifier la branche cible de features/new-feature mainla demande de tirage en conservant tout le contexte et les commentaires. La modification de la branche cible crée même une nouvelle mise à jour vers la demande de tirage, ce qui facilite l’analyse des différences antérieures avant la modification de la branche cible.

Les auteurs d’extension peuvent interroger le contexte à propos du dépôt actuel

L’un des défis pour un auteur d’une extension de contrôle de version consiste à obtenir le contexte du référentiel affiché à l’utilisateur, tel que le nom, l’ID et l’URL. Pour vous aider, nous avons ajouté le Service VersionControlRepositoryService en tant que service accessible par extension. À l’aide de cela, un auteur d’extension peut rechercher des informations sur le contexte actuel du référentiel Git dans l’interface utilisateur web. Il a actuellement une méthode, getCurrentGitRepository().

• Si un référentiel Git est sélectionné, un objet GitRepository est retourné avec des données de base sur le référentiel (nom, ID et URL)
• Si un référentiel TFVC est sélectionné ou si le service est accessible en dehors des pages Azure Repos, la valeur Null est retournée.

Voici un exemple d’extension qui utilise ce service.

Pipelines

Gérer les pipelines de build à l’aide de la nouvelle page Builds

Nous apportons plusieurs améliorations et déployons une nouvelle version de la page Builds . Cette nouvelle version combine le répertoire de tous vos pipelines de build et la liste des builds actuelles afin que vous puissiez rapidement parcourir les builds de votre projet pour voir son état. Il inclut également une préversion de l’analytique de test pour le pipeline sélectionné.

Gérer les e-mails de génération et de fin de déploiement mieux à l’aide d’une mise en forme améliorée

Les e-mails de saisie semi-automatique de build et de déploiement ont été mis à jour pour être plus filtrables par les règles de messagerie. Maintenant, la ligne d’objet inclut des informations plus pertinentes en un clin d’œil, le corps contient plus de détails et leur style a été actualisé avec la dernière marque.

Les éléments du nouveau format sont les suivants :

• [Build result] [pipeline name] - [repository:branch] - [project name] - [commit]
• [Deployment result] [pipeline name] > [release name] : [stage name]

Voici quelques exemples :

• [Build succeeded] IdentityService.CI - MyRepo:main - MyProject - d3b90b80
• [Deployment succeeded] New release pipeline > NotificationSpecialRelease-1 : Stage 1

Suivez la nouvelle terminologie unifiée d’Azure Pipelines

Tout au long des builds et versions, différents termes ont été utilisés historiquement pour des concepts similaires. Dans d’autres cas, les significations des termes étaient vagues. Par exemple, en indiquant la différence entre un pool d’agents et une file d’attente d’agent.

La terminologie a été unifiée dans Azure Pipelines pour clarifier ses concepts. Vous verrez maintenant les termes unifiés suivants :

Terme précédent	Terme unifié	Signification
Agent hébergé	Agent hébergé par Microsoft	Agent de build/mise en production qui s’exécute sur une infrastructure hébergée dans le cloud gérée par Microsoft.
Agent privé	Agent autohébergé	Agent de build/mise en production qui s’exécute sur un ordinateur fourni et géré par vous.
Pool d’agents	Pool d’agents	Ensemble d’agents au niveau de l’organisation qui peut exécuter des builds ou des versions.
File d’attente de l’agent	Pool d’agents	Ensemble de machines d’agent au niveau du projet capables d’exécuter des builds ou des versions. Il est lié à un pool d’agents au niveau de l’organisation.
Définition de build	Pipeline de build	Ensemble de étapes de génération de bout en bout pour une application.
Build	Build	Instance d’un pipeline de build qui est en cours d’exécution ou qui a été exécuté.
Phase	Travail	Série de tâches qui s’exécutent séquentiellement ou en parallèle sur un agent. Un pipeline de build ou de mise en production peut contenir un travail ou un graphique de plusieurs travaux.
Définition de mise en production	Pipeline de mise en production	Ensemble de étapes de mise en production de bout en bout pour qu’une application soit déployée à travers différentes étapes.
Version release	Version release	Instance d’un pipeline de mise en production qui s’exécute ou a été exécutée.
Environnement	Étape	Entité logique et indépendante qui représente l’emplacement où vous souhaitez déployer une version générée à partir d’un pipeline de mise en production.
Travail/pipeline simultané	Travail parallèle	Un travail parallèle vous permet d’exécuter un travail de génération ou de mise en production unique à la fois dans votre organisation. Avec d’autres travaux parallèles disponibles, vous pouvez exécuter en même temps davantage de travaux de génération et de mise en production.
Point de terminaison de service	Connexion du service	Groupe de paramètres, tels que les informations d’identification, utilisés pour se connecter à des services externes pour exécuter des tâches dans une build ou une version.

Pour plus d’informations, consultez la documentation Concepts .

Gérer les pipelines de mise en production à l’aide de la nouvelle page Versions

Une nouvelle expérience utilisateur entièrement repensée est disponible pour la page d’accueil de la version. Consultez la liste des pipelines de mise en production que vous publiez souvent à gauche. Vous pouvez également rechercher vos pipelines et les favoris.

Passez à l’affichage dossiers pour créer des dossiers pour l’organisation et la sécurité. La sécurité peut être définie au niveau d’un dossier.

Visualiser la progression de la mise en production

La nouvelle vue de progression de la mise en production vous offre des mises à jour actives de la progression du déploiement et un clic vous permet d’accéder à d’autres détails. La nouvelle vue visualise le pipeline de mise en production, ce qui facilite la compréhension de ce qui se passe et expose les détails et les actions appropriés à différentes étapes de la version.

Pipeline, détails des mises en production et environnements

La vue Pipeline affiche les artefacts de la version et des environnements dans lesquels ils seront déployés. La zone Mise en production fournit des détails de publication tels que le déclencheur de mise en production, les versions d’artefact et les balises.

Les environnements sont modélisés de manière à mieux comprendre leur état, ainsi que la progression détaillée. À tout moment, vous pouvez accéder aux journaux en cliquant sur le lien d’état dans l’environnement.

Prédéploiement et post-déploiement

Si des conditions de prédéploiement ou de post-déploiement ont été définies pour un environnement, elles sont indiquées sur l’environnement avec la présence des approbations et des portes. La progression des approbations et des portes s’affiche également dans l’état de l’environnement. Vous pouvez effectuer des actions ou afficher des détails supplémentaires en cliquant sur l’icône de condition de l’environnement qui se bloque sur le côté droit ou gauche de l’environnement.

Commits et éléments de travail

À chaque nouvelle version, vous pouvez voir la liste des validations et des éléments de travail associés pour chaque environnement séparément en cliquant sur l’environnement. Si la liste est longue, utilisez des filtres pour rechercher un élément de validation ou de travail qui vous intéresse.

Progression du déploiement et journaux

Les environnements affichent des mises à jour actives pour les déploiements en cours, notamment le nombre de phases et de tâches terminées et la durée d’exécution. Cliquer sur l’état de l’environnement ouvre une vue contenant les journaux, avec le focus sur ce qui est actuellement actif.

Vous pouvez cliquer dans les journaux pour entrer une vue prioritaire.

Impact de la mise à niveau vers Azure DevOps Server 2019 sur les tâches : Copie de fichiers de machine Windows et PoweShell sur l’ordinateur cible

Les groupes de machines sous Test Hub ont été déconseillés dans TFS 2017 RTM. Avec Azure DevOps Server 2019, le service Groupes de machines n’est plus disponible. Cela aura un impact sur les utilisateurs de la tâche « Copie de fichiers de machine Windows » version 1.* et de la tâche « PowerShell sur les machines cibles » version 1.*. Pour que vos pipelines continuent de fonctionner,

• Vous devez basculer vers la tâche « Copie de fichiers de machine Windows » version 2.* et fournir le nom complet de la machine cible au lieu du nom de l’ordinateur cible.
• Basculez vers la tâche « PowerShell sur l’ordinateur cible » version 2.* ou ultérieure et fournissez le nom complet de l’ordinateur ou de l’ordinateur suivi des ports de gestion à distance Windows (http/https). Par exemple, targetMachine :5985 ou targetMachine :5986

Résultats des tests et extensibilité

Les résultats de l’exécution des tests sont également exposés pour chaque environnement. Cliquer sur les résultats du test ouvre une vue contenant les détails du test, y compris les résultats d’autres extensions qui contribuent au processus.

Les extensions existantes fonctionnent dans cette nouvelle vue, ainsi qu’il existe de nouveaux points d’extensibilité pour permettre aux extensions de développer de surfacer encore plus d’informations pour un environnement. Pour plus d’informations, consultez la documentation sur les contributions et extensions .

Configurer des builds à l’aide de YAML

Les pipelines de build BASÉS sur YAML sont disponibles dans votre serveur Azure DevOps. Automatisez votre pipeline d’intégration continue à l’aide d’un fichier YAML archivé dans votre référentiel. Vous trouverez ici une référence complète pour le schéma YAML.

Pour prendre en charge les pipelines de build basés sur YAML de manière plus transparente, nous avons modifié le comportement par défaut de toutes les nouvelles ressources que vous créez (par exemple, les connexions de service, les groupes de variables, les pools d’agents et les fichiers sécurisés) pour être utilisables dans tous les pipelines de ce projet. Si vous souhaitez un contrôle plus strict sur vos ressources, vous pouvez désactiver le modèle d’autorisation par défaut (voir la figure ci-dessous). Lorsque vous le faites, une personne disposant des autorisations d’utilisation de la ressource doit enregistrer explicitement le pipeline dans l’éditeur web après l’ajout d’une référence de ressource au fichier YAML.

Chaîner des builds associées à l’aide de déclencheurs d’achèvement de build

Les produits volumineux contiennent plusieurs composants qui dépendent les uns des autres. Ces composants sont souvent générés indépendamment. Lorsqu’un composant en amont (une bibliothèque, par exemple) change, les dépendances en aval doivent être générées et validées à nouveau. Teams gère généralement ces dépendances manuellement.

Vous pouvez maintenant déclencher une build à la fin d’une autre build. Les artefacts générés par une build en amont peuvent être téléchargés et utilisés dans la build ultérieure, et vous pouvez également obtenir des données à partir de ces variables : Build.TriggeredBy.BuildId, Build.TriggeredBy.DefinitionId, Build.TriggeredBy.BuildDefinitionName. Pour plus d’informations, consultez la documentation sur les déclencheurs de build.

Gardez à l’esprit que dans certains cas, une build multiphase unique peut répondre à vos besoins. Toutefois, un déclencheur d’achèvement de build est utile si vos besoins incluent différents paramètres de configuration, options ou une autre équipe pour posséder le processus dépendant.

Mettre à jour localement votre agent

Les tâches que vous installez à partir de la galerie nécessitent parfois une version plus récente de l’agent pipelines. Si votre serveur Azure DevOps peut se connecter à Internet, les versions plus récentes sont téléchargées automatiquement. Si ce n’est pas le cas, vous devez mettre à niveau manuellement chaque agent. À compter de cette version, vous pouvez configurer votre serveur Azure DevOps pour rechercher les fichiers de package de l’agent sur son disque local plutôt qu’à partir d’Internet. Cela vous offre une flexibilité et un contrôle sur les versions de l’agent que vous mettent à disposition, sans avoir à exposer votre serveur Azure DevOps à Internet.

URL du badge d’état de la nouvelle build

Les badges de build incorporés dans la page d’accueil d’un référentiel sont un moyen courant d’afficher l’intégrité du référentiel. Même si nous avions des badges de build jusqu’à présent, il y avait quelques problèmes :

• L’URL n’était pas intuitive
• Le badge n’était pas spécifique à une branche
• Il n’y avait aucun moyen pour un utilisateur de cliquer sur le badge pour amener l’utilisateur à la dernière build de cette définition

Nous déployons maintenant une nouvelle API pour les badges de build qui résolvent ces problèmes. La nouvelle API permet aux utilisateurs de publier un état par branche et de les amener à la dernière build de la branche sélectionnée. Vous pouvez obtenir markdown pour la nouvelle URL du badge d’état en sélectionnant l’action de menu Badge État dans la nouvelle page Builds.

Pour la compatibilité descendante, nous continuerons également à honorer les URL de badge de build plus anciennes.

Ajouter des compteurs de build personnalisés à vos builds

Les compteurs de build permettent de générer des nombres et des étiquettes de manière unique. Auparavant, vous pouvez utiliser la variable spéciale $(rev :r) pour y parvenir. Vous pouvez maintenant définir vos propres variables de compteur dans votre définition de build qui sont incrémentées automatiquement chaque fois que vous exécutez une build. Pour ce faire, sous l’onglet variables d’une définition. Cette nouvelle fonctionnalité vous donne plus de puissance de la manière suivante :

• Vous pouvez définir un compteur personnalisé et définir sa valeur initiale. Par exemple, vous pouvez démarrer votre compteur à 100. $(rev :r) commence toujours à 0.
• Vous pouvez utiliser votre propre logique personnalisée pour réinitialiser un compteur. $(rev :r) est lié à la génération du numéro de build et il est réinitialisé automatiquement chaque fois qu’il existe un nouveau préfixe dans le numéro de build.
• Vous pouvez définir plusieurs compteurs par définition.
• Vous pouvez interroger la valeur d’un compteur en dehors d’une build. Par exemple, vous pouvez compter le nombre de builds qui ont été exécutées depuis la dernière réinitialisation à l’aide d’un compteur.

Pour plus d’informations sur les compteurs de build, consultez la documentation sur les variables définies par l’utilisateur.

Validations de la conformité et de la sécurité Azure Policy dans les pipelines

Nous voulons assurer la stabilité et la sécurité des logiciels dès le début du processus de développement tout en regroupant le développement, la sécurité et les opérations. Pour ce faire, nous avons ajouté la prise en charge d’Azure Policy.

Azure Policy permet de gérer et d’éviter des problèmes informatiques avec des définitions de stratégies qui appliquent des règles et des effets pour vos ressources. Lorsque vous utilisez Azure Policy, les ressources restent conformes aux normes de votre entreprise et aux contrats de niveau de service.

Pour respecter les directives de conformité et de sécurité dans le cadre du processus de mise en production, nous avons amélioré notre expérience de déploiement de groupe de ressources Azure. À présent, nous n’avons pas réussi la tâche de déploiement du groupe de ressources Azure avec des erreurs liées à la stratégie pertinentes en cas de violations lors du déploiement de modèles ARM.

En outre, nous avons ajouté le modèle de définition de version d’Azure Policy. Cela permet aux utilisateurs de créer des stratégies Azure et d’affecter ces stratégies aux ressources, aux abonnements ou aux groupes d’administration à partir de la définition de mise en production elle-même.

Générer sur les plateformes Linux/ARM et Windows 32 bits

L’agent multiplateforme Azure Pipelines code source ouvert a toujours été pris en charge sur Windows 64 bits (x64), macOS et Linux. Avec cette version, nous présentons deux nouvelles plateformes prises en charge : Linux/ARM et Windows/32 bits. Ces nouvelles plateformes vous permettent de créer sur des plateformes moins courantes, mais pas moins importantes, telles que Raspberry Pi, une machine Linux/ARM.

Expériences améliorées pour les tests dans les pipelines

L’onglet Tests offre désormais une expérience moderne qui vous fournit des informations de test contextuelles enrichies pour Pipelines. La nouvelle expérience fournit une vue de test en cours, une expérience de débogage de page complète, dans l’historique des tests de contexte, la création de rapports sur l’exécution de tests abandonnées et le résumé du niveau d’exécution.

Afficher l’exécution des tests en cours

Les tests, tels que les tests d’intégration et fonctionnels, peuvent s’exécuter pendant longtemps. Il est donc important de voir l’exécution des tests à tout moment donné. Avec la vue de test en cours, vous n’avez plus besoin d’attendre la fin de l’exécution du test pour connaître le résultat du test. Les résultats sont disponibles en quasi temps réel à mesure qu’ils sont exécutés, ce qui vous permet de prendre des mesures plus rapidement. Vous pouvez déboguer un échec ou abandonner, déposer un bogue ou abandonner le pipeline. La fonctionnalité est actuellement disponible pour le pipeline de génération et de mise en production à l’aide de la tâche de test VS dans la phase Multi Agent, à l’aide de la tâche publier des résultats des résultats des tests ou de publier des résultats de test à l’aide des API. À l’avenir, nous prévoyons d’étendre cette expérience pour l’exécution des tests à l’aide de l’agent unique.

L’affichage ci-dessous montre le résumé des tests en cours dans la nouvelle vue de progression de la version, la création de rapports sur le nombre total de tests et le nombre d’échecs de test à un moment donné.

En cliquant sur le résumé du test en cours ci-dessus, vous pouvez afficher le résumé détaillé des tests, ainsi que les informations de test ayant échoué ou abandonnées dans les plans de test. Le résumé des tests s’actualise à intervalles réguliers avec la possibilité d’actualiser la vue des détails à la demande, en fonction de la disponibilité des nouveaux résultats.

Afficher les détails du débogage des exécutions de test dans la page complète

Les messages d’erreur et les traces de pile sont longs en nature et ont besoin de suffisamment d’immobiliers pour afficher les détails pendant le débogage. Pour bénéficier d’une expérience de débogage immersif, vous pouvez maintenant développer l’affichage de test ou d’exécution de test en mode page complet, tout en étant toujours en mesure d’effectuer les opérations de contexte requises, telles que la création de bogues ou l’association de conditions requises pour le résultat du test actuel.

Afficher l’historique des tests dans le contexte

Historiquement, les équipes doivent accéder au hub d’exécutions pour afficher l’historique d’un résultat de test. Avec la nouvelle expérience, nous apportons l’historique des tests directement dans le contexte dans l’onglet Plans de test pour la génération et la mise en production. Les informations d’historique des tests sont fournies de manière progressive à partir de la définition ou de l’environnement de build actuel pour le test sélectionné, suivie d’autres branches et environnements pour la génération et la mise en production respectivement.

Afficher les tests abandonnés

L’exécution de test peut abandonner en raison de plusieurs raisons telles que le code de test incorrect, la source sous test et les problèmes environnementaux. Quelle que soit la raison de l’abandon, il est important de diagnostiquer le comportement et d’identifier la cause racine. Vous pouvez maintenant afficher les tests abandonnés et les exécutions de test, en même temps que les exécutions terminées dans les plans de test. La fonctionnalité est actuellement disponible pour le pipeline de génération et de mise en production à l’aide de la tâche de test VS en phase Multi Agent ou la publication des résultats de test à l’aide des API. À l’avenir, nous prévoyons d’étendre cette expérience pour l’exécution des tests à l’aide de l’agent unique.

Prise en charge de la traçabilité des tests et des environnements de mise en production dans l’historique des tests

Nous ajoutons la prise en charge de l’affichage de l’historique d’un test automatisé regroupé par différents environnements de mise en production dans lesquels le test est exécuté. Si vous modélisez des environnements de mise en production en tant que pipelines de mise en production ou environnements de test et que vous exécutez des tests dans ces environnements, vous pouvez déterminer si un test passe dans l’environnement de développement, mais échoue dans l’environnement d’intégration. Vous pouvez déterminer s’il passe dans les paramètres régionaux anglais, mais échoue dans un environnement qui a des paramètres régionaux turcs. Pour chaque environnement, vous trouverez l’état du dernier résultat du test et, si le test a échoué sur cet environnement, vous trouverez également la version depuis laquelle le test a échoué.

Passer en revue les résultats des tests résumés

Pendant l’exécution, un test peut générer plusieurs instances de tests qui contribuent au résultat global. Voici quelques exemples : les tests qui sont réexécutés en raison d’échecs, de tests composés d’une combinaison ordonnée d’autres tests (par exemple, test ordonné) ou de tests ayant différentes instances en fonction du paramètre d’entrée fourni (tests pilotés par les données). Étant donné que ces tests sont liés, ils doivent être signalés avec le résultat global dérivé en fonction des résultats individuels des tests. Avec cette mise à jour, nous présentons une version améliorée des résultats des tests présentés sous la forme d’une hiérarchie sous l’onglet Tests d’une version. Examinons un exemple.

Plus tôt, nous avons introduit la possibilité de réexécuter les tests ayant échoué dans la tâche de test VS. Toutefois, nous n’avons signalé que la dernière tentative d’un test, ce qui a quelque peu limité l’utilité de cette fonctionnalité. Nous avons maintenant étendu cette fonctionnalité pour signaler chaque instance de l’exécution de test en tant que tentative. En outre, l’API Gestion des tests prend désormais en charge la possibilité de publier et d’interroger des résultats de test hiérarchiques. Pour plus d’informations, consultez la documentation de l’API résultats des tests.

Afficher les analyses de test dans les pipelines

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 sain. La fonctionnalité d’analyse de test fournit une visibilité quasi en temps réel de vos données de test pour les builds et les pipelines de mise en production. Elle permet d’améliorer l’efficacité de votre pipeline en identifiant les problèmes de qualité répétitifs et à impact élevé.

Vous pouvez regrouper les résultats des tests par différents éléments, identifier les tests clés pour vos fichiers de test ou de branche, ou explorer un test spécifique pour afficher les tendances et comprendre les problèmes de qualité tels que les flakines.

Affichez l’analytique des tests pour les builds et la version, préversion ci-dessous :

Pour plus d’informations, consultez notre documentation.

Simplifier les définitions avec plusieurs tâches sans agent

Les tâches d’une phase sans agent sont orchestrées et exécutées sur le serveur. Les phases sans agent ne nécessitent pas d’agent ni d’ordinateurs cibles. Contrairement aux phases de l’agent, une seule tâche peut être ajoutée à chaque phase sans agent dans les définitions. Cela signifiait que plusieurs phases devaient être ajoutées lorsqu’il y avait plusieurs tâches sans agent dans le processus, ce qui rendait la définition volumineuse. Nous avons assoupli cette restriction, ce qui vous permet de gérer plusieurs tâches dans des phases sans agent. Les tâches de la même phase s’exécutent de manière séquentielle, comme elles le font pour les phases d’agent. Pour plus d’informations, consultez la documentation sur les phases de serveur.

Exposer et phaser progressivement des déploiements à l’aide de portes de mise en production

À l’aide de portes de mise en production, vous pouvez spécifier des critères d’intégrité d’application qui doivent être remplis avant qu’une mise en production soit promue vers l’environnement suivant. Toutes les portes spécifiées sont évaluées régulièrement avant ou après tout déploiement, jusqu’à ce qu’elles réussissent toutes. Quatre types de portes sont disponibles en dehors de la boîte et vous pouvez ajouter d’autres portes à partir de la Place de marché. Vous pourrez vérifier que tous les critères nécessaires pour un déploiement ont été remplis. Pour plus d’informations, consultez la documentation relative aux portes de mise en production.

Maintenez les déploiements en attente jusqu’à ce que les portes réussissent de manière cohérente

Les portes de mise en production permettent l’évaluation automatique des critères d’intégrité avant qu’une mise en production soit promue vers l’environnement suivant. Par défaut, la mise en production progresse après qu’un échantillon réussi pour toutes les portes a été reçu. Même si une porte est erratique et que l’échantillon réussi reçu est bruit, la libération progresse. Pour éviter ces types de problèmes, vous pouvez maintenant configurer la version pour vérifier la cohérence de l’intégrité pendant une durée minimale avant de progresser. Au moment de l’exécution, la mise en production s’assurerait que les évaluations consécutives des portes sont réussies avant d’autoriser la promotion. Le temps total d’évaluation dépend du « temps entre la réévaluation » et est généralement supérieur à la durée minimale configurée. Pour plus d’informations, consultez la documentation relative au contrôle de déploiement release à l’aide de portes .

Déployer automatiquement sur de nouvelles cibles dans un groupe de déploiement

Auparavant, lorsque de nouvelles cibles ont été ajoutées à un groupe de déploiement, un déploiement manuel a été nécessaire pour s’assurer que toutes les cibles ont la même version. Vous pouvez maintenant configurer l’environnement pour déployer automatiquement la dernière version réussie sur les nouvelles cibles. Pour plus d’informations, consultez la documentation groupes de déploiement.

Déployer en continu des builds marquées par traitement post-build

Les déclencheurs de déploiement continu créent une mise en production à la fin de la build. Toutefois, les builds sont parfois post-traitées et la build ne doit être publiée qu’une fois ce traitement terminé. Vous pouvez maintenant tirer parti des balises de génération, qui seraient affectées pendant le post-traitement, dans les filtres de déclencheur de la mise en production.

Définir une variable au moment de la publication

Dans une définition de mise en production, vous pouvez maintenant choisir les variables que vous souhaitez définir lorsque vous créez la version.

La valeur fournie pour la variable lorsque la mise en production est créée est utilisée uniquement pour cette version. Cette fonctionnalité vous permet d’éviter plusieurs étapes pour Create-in-Draft, de mettre à jour les variables dans le brouillon et de déclencher la mise en production avec la variable.

Passer des variables d’environnement aux tâches

Les auteurs de tâches CI/CD peuvent définir une nouvelle propriété, showEnvironmentVariables, dans le task.json pour passer des variables d’environnement à des tâches. Lorsque vous le faites, un contrôle supplémentaire est rendu sur la tâche dans l’éditeur de build. Ceci est disponible pour les tâches PowerShell, Cmd et Bash .

Cela active deux scénarios :

• Une tâche nécessite une variable d’environnement avec la conservation de la casse dans le nom de la variable. Par exemple, dans l’exemple ci-dessus, la variable d’environnement transmise à la tâche serait « foo » et non « FOO ».
• Il permet aux valeurs de secrets d’être transmises de manière sécurisée aux scripts. Il est préférable de transmettre les secrets en tant qu’arguments aux scripts, car le système d’exploitation sur l’agent peut journaliser les appels de processus, y compris leurs arguments.

Cloner les groupes de variables

Nous avons ajouté la prise en charge du clonage de groupes de variables. Chaque fois que vous souhaitez répliquer un groupe de variables et que vous mettez simplement à jour quelques-unes des variables, vous n’avez pas besoin de passer par le processus fastidieux d’ajout de variables un par un. Vous pouvez maintenant rapidement effectuer une copie de votre groupe de variables, mettre à jour les valeurs de manière appropriée et l’enregistrer en tant que nouveau groupe de variables.

Ignorer une porte de mise en production pour un déploiement

Les portes de mise en production permettent l’évaluation automatique des critères d’intégrité avant qu’une mise en production soit promue vers l’environnement suivant. Par défaut, le pipeline de mise en production progresse uniquement lorsque toutes les portes sont saines en même temps. Dans certaines situations, par exemple lors de l’accélération d’une mise en production ou après vérification manuelle de l’intégrité, un approbateur peut ignorer une porte et autoriser la mise en production à progresser même si cette porte n’a pas encore été évaluée comme saine. Documentation sur les portes de mise en production pour plus d’informations.

Effectuer des tests supplémentaires à l’aide d’un déclencheur de mise en production de demande de tirage

Vous avez pu déclencher une build en fonction d’une demande de tirage (PULL Request) et obtenir ces commentaires rapides avant une fusion pendant un certain temps. Vous pouvez maintenant configurer un déclencheur de demande de tirage pour une version. L’état de la mise en production est renvoyé dans le référentiel de codes et peut être affiché directement dans la page de demande de tirage. Cela est utile si vous souhaitez effectuer des tests fonctionnels ou manuels supplémentaires dans le cadre de votre flux de travail de demande de tirage.

Créer une connexion au service Azure avec un principal du service qui effectue l’authentification avec un certificat

Vous pouvez maintenant définir une connexion de service Azure avec un principal de service et un certificat pour l’authentification. Avec la connexion de service Azure prenant désormais en charge le principal de service qui s’authentifie avec un certificat, vous pouvez désormais déployer sur Azure Stack configuré avec AD FS. Pour créer un principal de service avec l’authentification par certificat, reportez-vous à l’article sur la création d’un principal de service qui s’authentifie auprès d’un certificat.

Exécuter à partir du package pris en charge dans les déploiements Azure App Service

La version de la tâche Azure App Service Deploy (4.*) prend désormais en charge RunFromPackage (précédemment appelée RunFromZip).

App Service prend en charge un certain nombre de techniques différentes pour déployer vos fichiers tels que msdeploy (aka WebDeploy), git, ARM et bien plus encore. Mais toutes ces techniques ont une limitation. Vos fichiers sont déployés sous votre dossier wwwroot (en particulier d :\home\site\wwwroot) et le runtime exécute ensuite les fichiers à partir de là.

Avec Run From Package, il n’existe plus d’étape de déploiement qui copie les fichiers individuels dans wwwroot. Au lieu de cela, vous pointez simplement vers un fichier zip, et le fichier zip est monté sur wwwroot en tant que système de fichiers en lecture seule. Cela a plusieurs avantages :

• Réduction des risques de verrouillage lors de la copie de fichiers
• Déploiement possible sur une application de production (après redémarrage)
• Connaissance des fichiers qui sont exécutés dans votre application
• Améliore les performances des déploiements Azure App Service.
• Peut réduire les temps de démarrage à froid, en particulier pour les fonctions JavaScript avec des arborescences de package npm de grande taille.

Déployer des conteneurs Linux avec la tâche de déploiement du serveur d’applications

La version 4.* de la tâche Azure App Service Deploy prend désormais en charge le déploiement de votre propre conteneur personnalisé sur Azure Functions sur Linux.

Le modèle d’hébergement Linux pour Azure Functions est basé sur des conteneurs Docker qui offrent une plus grande flexibilité en termes d’empaquetage et d’exploitation des dépendances spécifiques à l’application. Les fonctions sur Linux peuvent être hébergées dans 2 modes différents :

1. Image conteneur intégrée : vous apportez le code de l’application de fonction et Azure fournit et gère le conteneur (mode image intégré), de sorte qu’aucune connaissance spécifique liée à Docker n’est requise. Cela est pris en charge dans la version existante de la tâche De déploiement App Service.
2. Image conteneur personnalisée : nous avons amélioré la tâche De déploiement App Service pour prendre en charge le déploiement d’images conteneur personnalisées sur Azure Functions sur Linux. Lorsque vos fonctions ont besoin d’une version de langage spécifique ou nécessitent une dépendance ou une configuration spécifique qui n’est pas fournie dans l’image intégrée, vous pouvez générer et déployer une image personnalisée sur Azure Function sur Linux à l’aide d’Azure Pipelines.

La tâche Xcode prend en charge la nouvelle version de Xcode 10

Coïncidant avec la version d’Apple de Xcode 10, vous pouvez maintenant définir vos projets pour générer ou être testés spécifiquement avec Xcode 10. Votre pipeline peut également exécuter des travaux en parallèle avec une matrice de versions Xcode. Vous pouvez utiliser le pool d’agents macOS hébergé par Microsoft pour exécuter ces builds. Consultez les instructions relatives à l’utilisation de Xcode dans Azure Pipelines.

Simplifier le déploiement sur Kubernetes à l’aide de Helm

Helm est un outil qui simplifie l’installation et la gestion des applications Kubernetes. Il a également gagné beaucoup de popularité et de soutien communautaire au cours de l’année dernière. Une tâche Helm en version est désormais disponible pour empaqueter et déployer des graphiques Helm sur Azure Container Service (AKS) ou tout autre cluster Kubernetes.

Avec l’ajout de cette tâche Helm, vous pouvez maintenant configurer un pipeline CI/CD basé sur Helm pour la livraison de conteneurs dans un cluster Kubernetes. Pour plus d’informations, consultez la documentation Déployer à l’aide de Kubernetes sur Azure Container Service .

Contrôler la version helm utilisée dans la version release

La tâche Helm Tool Installer acquiert une version spécifique de Helm à partir d’Internet ou du cache des outils et l’ajoute au PATH de l’agent (hébergé ou privé). Utilisez cette tâche pour modifier la version de Helm utilisée dans les tâches suivantes, telles que la tâche cli .NET Core. L’ajout de cette tâche avant la tâche Helm Deploy dans une définition de build ou de mise en production garantit l’empaquetage et le déploiement de votre application avec la version Helm appropriée. Cette tâche permet également d’installer éventuellement l’outil kubectl , qui est un prérequis pour que Helm fonctionne.

Déployer en continu sur Azure Database pour MySQL

Vous pouvez désormais déployer en continu sur Azure Database pour MySQL - Base de données MySQL d’Azure en tant que service. Gérez vos fichiers de script MySQL dans le contrôle de version et déployez en permanence dans le cadre d’un pipeline de mise en production à l’aide d’une tâche native plutôt que de scripts PowerShell.

Utiliser des tâches windows distantes améliorées basées sur PowerShell

Des tâches nouvelles et améliorées basées sur Windows PowerShell sont disponibles. Ces améliorations incluent plusieurs correctifs de performances et prennent en charge les journaux en direct et les commandes de sortie de la console, telles que Write-Host et Write-Output.

Tâche PowerShell sur cible (version : 3.*) : vous pouvez ajouter un script inline, modifier des options PSSession, contrôler « ErrorActionPreference » et échouer sur une erreur standard.

Tâche de copie de fichiers Azure (version : 2.*) : fournie avec la dernière version d’AzCopy (v7.1.0) qui résout un problème GitHub.

Filtrer des branches pour GitHub Enterprise ou des artefacts Git externes

Lorsque vous publiez des dépôts GitHub Enterprise ou git externes, vous pouvez maintenant configurer les branches spécifiques qui seront publiées. Par exemple, vous pouvez déployer uniquement des builds provenant d’une branche spécifique en production.

Créer des applications écrites en Go

Utilisez la tâche d’installation de l’outil Go pour installer une ou plusieurs versions de Go Tool à la volée. Cette tâche acquiert une version spécifique de Go Tool nécessaire par votre projet et l’ajoute au CHEMIN d’accès de l’agent de build. Si la version de l’outil Go ciblé est déjà installée sur l’agent, cette tâche ignore le processus de téléchargement et d’installation.

La tâche Go vous permet de télécharger des dépendances, de générer ou de tester votre application. Vous pouvez également utiliser cette tâche pour exécuter une commande Go personnalisée de votre choix.

Exécuter des scripts Python inline ou basés sur des fichiers dans votre pipeline

Une nouvelle tâche de script Python simplifie l’exécution de scripts Python dans votre pipeline. La tâche exécute un script à partir d’un fichier Python (.py) dans votre référentiel, ou vous pouvez entrer manuellement un script dans les paramètres de la tâche pour enregistrer dans le cadre de votre pipeline. La tâche utilise la version de Python dans le chemin d’accès, ou vous pouvez spécifier un chemin absolu vers un interpréteur Python à utiliser.

Tirer parti de la génération et du test Xcode améliorés à partir de xcpretty

xcpretty améliore la lisibilité de la sortie xcodebuild et génère des résultats de test au format JUnit. La tâche de génération Xcode utilise désormais automatiquement xcpretty lorsqu’elle est disponible sur l’ordinateur de l’agent, car elle se trouve sur les agents macOS hébergés. Bien que la sortie xcpretty puisse être différente et moins détaillée que la sortie xcodebuild, nous rendons les journaux xcodebuild complets disponibles avec chaque build.

Test Plans

Client Test Runner (Plans de test Azure) pour exécuter des tests manuels pour les applications de bureau

Vous pouvez maintenant utiliser le client Test Runner (Azure Test Plans) pour exécuter des tests manuels pour les applications de bureau. Cela vous aidera à passer de Microsoft Test Manager à Azure Test Plans. Reportez-vous à nos conseils ici. À l’aide du client Test Runner, vous pouvez exécuter vos tests manuels et enregistrer les résultats des tests pour chaque étape de test. Vous disposez également de fonctionnalités de collecte de données telles que la capture d’écran, le journal des actions d’image et l’enregistrement vidéo audio. Si vous rencontrez un problème lors du test, utilisez Test Runner pour créer un bogue avec des étapes de test, des captures d’écran et des commentaires automatiquement inclus dans le bogue.

Test Runner (Plans de test Azure) nécessite un téléchargement unique et une installation de l’exécuteur. Sélectionnez Exécuter pour l’application de bureau, comme indiqué ci-dessous.

Artifacts

Sources amont

Azure DevOps Server 2019 apporte des mises à jour substantielles aux sources en amont disponibles sur vos flux Azure Artifacts :

• Vous pouvez ajouter nuget.org sources en amont aux flux existants créés dans les versions TFS précédentes. Recherchez la bannière au-dessus des packages de votre flux pour plus d’informations, notamment les modifications de comportement dont vous devez être conscient avant la mise à niveau.
• Vous pouvez ajouter d’autres flux Azure DevOps Server en tant que sources en amont à votre flux, ce qui signifie que vous pouvez utiliser des packages NuGet et npm à partir de ces flux via votre flux.

Nous avons également introduit un nouveau rôle dans Azure Artifacts : « Collaborateur ». Un collaborateur peut enregistrer des packages à partir d’une source en amont, mais ne peut pas publier les packages de packages directement dans le flux (par exemple, à l’aide de la publication nuget). Cela vous permet de limiter la publication de packages à un utilisateur approuvé ou au système de génération tout en permettant à vos ingénieurs d’utiliser de nouveaux packages à partir de vos sources en amont.

Suivre les packages

Nous avons encore plus facilement configuré des notifications avec un nouveau bouton Suivre directement sur chaque package. Le bouton Suivre est également compatible avec les vues de mise en production. Si vous suivez un package tout en le examinant par le biais d’une vue, vous obtiendrez uniquement des mises à jour pour les nouvelles versions promues à cette vue.

Modifier les paramètres du flux sans avoir à enregistrer manuellement

Quelques-unes des interactions sur la page des paramètres de flux ont été améliorées. À présent, les modifications que vous apportez, telles que l’ajout d’une autorisation en amont ou d’une autorisation, sont enregistrées immédiatement. Cela signifie que vous n’avez pas à vous soucier de perdre des modifications lorsque vous basculez entre les pivots de paramètres.

Simplifiez l'authentification à l'aide du nouveau fournisseur d’informations d’identification multiplateforme de NuGet

L’interaction avec les flux NuGet authentifiés vient d’être beaucoup mieux. Le nouveau fournisseur d’informations d’identification Azure Artifacts basé sur .NET Core fonctionne avec msbuild, dotnet et nuget(.exe) sur Windows, macOS et Linux. Chaque fois que vous souhaitez utiliser des packages à partir d’un flux Azure Artifacts, le fournisseur d’informations d’identification acquiert et stocke automatiquement un jeton pour le compte du client NuGet que vous utilisez. Vous n’avez plus besoin de stocker et de gérer manuellement un jeton dans un fichier de configuration.

Pour obtenir le nouveau fournisseur, accédez à GitHub et suivez les instructions de votre client et de votre plateforme.

Compressez les symboles lors de la publication sur un partage de fichiers

Nous avons mis à jour la tâche Index &Publish Symbols pour prendre en charge la compression des symboles lorsqu’ils sont publiés sur un partage de fichiers.

Wiki

Publier des fichiers Markdown à partir d’un dépôt Git en tant que Wiki

Les développeurs créent de la documentation pour les « API », les kits de développement logiciel (SDK) et les « documents d’aide à expliquer le code » dans les référentiels de code. Les lecteurs doivent ensuite parcourir le code pour trouver la documentation appropriée. Vous pouvez maintenant simplement publier des fichiers Markdown à partir de référentiels de code et les héberger dans Wiki.

À partir du Wiki, commencez par cliquer sur Publier du code en tant que wiki. Ensuite, vous pouvez spécifier un dossier dans un dépôt Git qui doit être promu.

Une fois que vous avez cliqué sur Publier, tous les fichiers markdown sous le dossier sélectionné seront publiés en tant que wiki. Cela mappe également le chef de la branche au wiki afin que les modifications que vous apportez au référentiel Git soient immédiatement reflétées.

Pour plus d’informations, consultez le billet de blog de la documentation sur le produit.

Lien vers des en-têtes dans une page

Vous pouvez maintenant cliquer sur l’icône de lien en regard de n’importe quel titre de section d’une page wiki pour générer une URL directement vers cette section. Vous pouvez ensuite copier cette URL et la partager avec les membres de l’équipe pour les lier directement à cette section.

Joindre des fichiers et des images dans des dossiers

Lors de la modification des pages wiki hors connexion, il peut être plus facile d’ajouter des pièces jointes et des images de fichier dans le même répertoire que la page wiki. À présent, vous pouvez ajouter une pièce jointe ou une image dans n’importe quel dossier du wiki et le lier à votre page.

Intégrez une vidéo dans un wiki

Vous pouvez maintenant incorporer des vidéos dans une page wiki à partir de services en ligne telles que Microsoft Stream et YouTube. Vous pouvez ajouter l’URL vidéo incorporée à l’aide de la syntaxe suivante :

::: video
<iframe width="560" height="315" src="https://www.youtube.com/embed/7DbslbKsQSk" frameborder="0" allow="autoplay; encrypted-media" allowfullscreen></iframe>
:::

Renommez un wiki

Vous pouvez maintenant renommer votre wiki dans l’interface utilisateur wiki et à l’aide d’API REST. Dans le menu Plus , cliquez sur Renommer le wiki pour donner un nom mémorable à votre wiki.

Ouvrir la page dans un nouvel onglet

Vous pouvez maintenant cliquer avec le bouton droit sur une page wiki et l’ouvrir dans un nouvel onglet, ou simplement appuyer sur Ctrl + clic gauche sur une page wiki pour l’ouvrir dans un nouvel onglet.

Conserver des caractères spéciaux dans les titres de page Wiki

Vous pouvez maintenant créer des pages wiki avec des caractères spéciaux tels que : < > * ? | -. Maintenant, les pages avec des titres tels que « FAQ ? » ou « Guide de configuration » peut être créé dans Wiki. Les caractères suivants sont traduits en chaînes codées en UTF-8 :

Caractère	Chaîne encodée
:	%3A
<	%3C
>	%3E
*	%2A
?	%3F
|	%7C
-	%2D

Afficher les liens rompus

Tous les liens d’un wiki qui ne sont pas liés correctement apparaissent dans une couleur rouge distincte et une icône de lien rompu, ce qui vous donne un indice visuel de tous les liens rompus dans une page wiki.

Corriger les liens rompus lors du déplacement de pages

Les liens de page rompus sont l’une des principales causes d’une mauvaise qualité de page dans n’importe quelle solution de documentation. Précédemment dans Wiki, lorsque vous avez déplacé une page dans l’arborescence ou renommé une page, il peut potentiellement interrompre les liens vers la page à partir d’autres pages et éléments de travail. À présent, vous pouvez rechercher et corriger les liens avant qu’ils ne soient rompus.

Lorsque vous renommez ou déplacez une page, vous serez invité à rechercher les liens absolus ou relatifs affectés.

Vous verrez ensuite une liste des liens de page et des éléments de travail affectés avant de prendre des mesures.

Créer une table des matières pour les pages wiki

Parfois, les pages wiki peuvent être longues, avec du contenu organisé en plusieurs en-têtes. Vous pouvez maintenant ajouter une table des matières à n’importe quelle page qui a au moins un titre à l’aide de la [[_TOC_]] syntaxe.

Vous pouvez également insérer une table des matières en cliquant sur le bouton approprié dans le volet format lors de la modification de la page.

Pour plus d’informations sur l’utilisation de Markdown dans Azure DevOps, consultez la documentation de markdown .

Métadonnées Surface pour les pages wiki et aperçu du code à l’aide de balises YAML

L’ajout de métadonnées à la documentation peut aider les lecteurs et les index de recherche à récupérer et à exposer du contenu significatif. Dans cette mise à jour, tout fichier qui contient un bloc YAML au début du fichier sera transformé en une table de métadonnées d’une tête et d’une ligne. Le bloc YAML doit prendre la forme d’un ensemble YAML valide entre les lignes à trois tirets. Il prend en charge tous les types de données de base, liste, objet en tant que valeur. La syntaxe est prise en charge dans l’aperçu du fichier wiki et du fichier de code.

Exemple de balises YAML :

---
tag: post
title: Hello world
---

Exemple de balises YAML avec liste :

---
tags:
- post
- code
- web
title: Hello world
---

Publier du code en tant que Wiki avec les autorisations de contribution

Auparavant, seuls les utilisateurs disposant d’une autorisation Créer un référentiel sur un dépôt Git pouvaient publier du code en tant que wiki. Cela a rendu les administrateurs de référentiel ou les créateurs un goulot d’étranglement pour toutes les demandes de publication de fichiers Markdown hébergés dans des dépôts git en tant que wikis. À présent, vous pouvez publier du code en tant que wiki si vous disposez simplement de l’autorisation Contribuer sur le référentiel de code.

Reporting

L’extension de la Place de marché Analytics pour la création de rapports est désormais disponible

L’extension de la Place de marché Analytics est désormais disponible pour Azure DevOps Server. L’analytique est l’avenir de la création de rapports pour Azure DevOps et Azure DevOps Server. L’installation de l’extension Analytics fournit des widgets avancés, l’intégration de Power BI et l’accès OData.

Pour plus d’informations, consultez What is Analytics et the Reporting Roadmap. Analytics est disponible en préversion publique. Il contient actuellement des données pour les tableaux et les résultats des tests automatisés via des pipelines. Consultez les données disponibles dans le service Analytics.

Examiner l’historique des builds via un nouveau widget de tableau de bord de génération

Nous avons un widget d’historique de build nouveau et amélioré que vous pouvez ajouter à vos tableaux de bord. Avec ce widget, vous pouvez désormais afficher un historique des builds à partir d’une branche spécifique sur votre tableau de bord et le configurer sur un projet public pour les visiteurs anonymes.

---

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