Améliorations apportées à YAML dans Azure Pipelines - Sprint 142 Update

Dans la mise à jour Sprint 142 d’Azure DevOps, plusieurs améliorations ont été apportées à YAML, telles que l’ajout de compteurs personnalisés à vos builds, la spécification de branches à générer pour les demandes de tirage et l’utilisation de modèles inline. Nous avons également activé la nouvelle navigation pour tous les utilisateurs, introduit un thème sombre et amélioré les expériences de liaison et de pièces jointes dans Azure Boards.

Pour plus d’informations, consultez la liste des fonctionnalités ci-dessous.

Fonctionnalités

Général :

• La nouvelle navigation est activée pour tous les utilisateurs
• Thème sombre

Azure Boards :

• Organiser les documents de référence avec des pièces jointes d’éléments de travail plus riches
• Gérer les dépendances en liant des éléments de travail entre vos organisations
• Ouvrir des éléments de travail à partir de la recherche

Azure Repos :

• Les auteurs d’extension peuvent interroger le contexte sur le dépôt actuel

Azure Pipelines :

• Ajouter des compteurs de build personnalisés à vos builds
• Utiliser YAML pour spécifier les branches à générer pour les demandes de tirage
• Utiliser des expressions de modèle YAML inline
• Améliorer la résolution des problèmes avec le journal d’initialisation du pipeline
• Rétention par défaut pour les pipelines YAML
• Générer sur des plateformes Linux/ARM et Windows 32 bits
• Cloner des groupes de variables
• Consultez commits et éléments de travail pour toutes les sources liées
• Exécuter à partir du package pris en charge dans les déploiements Azure App Service
• Déployer des conteneurs Linux avec la tâche De déploiement App Server

Azure Test Plans :

• Client Azure Test Runner pour exécuter des tests manuels pour les applications de bureau

Azure Artifacts :

• Préversion publique des artefacts de pipeline

Wiki :

• Publier du code en tant que wiki avec des autorisations De contribution

Administration :

• Les PAT appliquent le CAP

Général

La nouvelle navigation est activée pour tous les utilisateurs

Nous avons activé notre nouvelle navigation pour tous les utilisateurs ! Il s’agit d’une étape majeure dans le déploiement de notre nouvelle conception de produit. Bien que nous passions tout le monde au nouveau modèle de navigation avec cette version, les utilisateurs pourront toujours refuser et utiliser l’ancienne navigation jusqu’au 16 janvier 2019. Vous pouvez vous désabonner en sélectionnant Fonctionnalités d’aperçu dans le menu sous votre avatar en haut à droite de chaque page.

Pour plus d’informations, consultez le billet de blog Mise à jour de navigation .

Thème foncé

L’une de nos demandes de fonctionnalités de longue date a été d’offrir un thème sombre. Nous sommes heureux de vous informer que cela est désormais disponible dans le cadre de la nouvelle navigation. Vous pouvez activer le thème sombre en sélectionnant Thème dans le menu sous votre avatar en haut à droite de chaque page.

Azure Boards

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

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

Gérer les dépendances en liant des éléments de travail entre vos organisations

La liaison d’un travail lié ou dépendant vous offre un contexte plus large dans le travail que vous effectuez le suivi et vous aide à gérer les dépendances avec d’autres équipes. Grâce aux liens pour le travail à distance, vous pouvez désormais effectuer le suivi du travail entre les organisations au sein de votre entreprise. Copiez simplement l’URL d’un élément de travail existant, accédez à un autre élément de travail et créez un lien à l’aide de l’un des trois nouveaux types de liens : Consumes From, Produces For et Remote Related. Pour plus d’informations sur la traçabilité dans Azure Boards, consultez la documentation relative à la liaison d’éléments de travail.

Notes

Les autorisations sont respectées dans les deux organisations Azure DevOps, qui doivent toutes deux être soutenues par le même locataire Azure AD.

Lorsque vous commencez à gérer plusieurs dépendances, utilisez le nouveau champ Nombre de liens distants dans Requêtes pour répertorier les éléments de travail qui ont des dépendances distantes dans votre projet, ou envisagez d’installer l’extension Dependency Tracker . Cette extension, qui a été créée par le groupe Windows de Microsoft pour répondre à leurs besoins d’échelle, s’appuie sur des liens distants pour afficher une hiérarchie riche et une représentation graphique de vos dépendances.

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

Auparavant, un élément de travail ne pouvait pas être ouvert à partir de la page des résultats de la recherche si le volet d’aperçu de l’élément de travail était désactivé. Cela compliquerait l’analyse des résultats de votre 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. Cette fonctionnalité a été prioritaire à partir de UserVoice.

Azure Repos

Les auteurs d’extension peuvent interroger le contexte sur le dépôt actuel

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

• Si un dépôt Git est sélectionné, un objet GitRepository est retourné avec des données de base sur le dépôt (nom, ID et URL)
• Si un dépôt 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.

Azure Pipelines

Ajouter des compteurs de build personnalisés à vos builds

Les compteurs de build permettent de numéroter et d’étiqueter les builds de manière unique. Auparavant, vous pouviez utiliser la variable spéciale $(rev:r) pour ce faire. 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. Vous effectuez cette opération sous l’onglet variables d’une définition. Cette nouvelle fonctionnalité vous donne plus de puissance des manières suivantes :

• Vous pouvez définir un compteur personnalisé et définir sa valeur de départ. Pour instance 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. Pour instance, vous pouvez compter le nombre de builds 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.

Utiliser YAML pour spécifier les branches à générer pour les demandes de tirage

Les pipelines YAML peuvent spécifier les branches à générer pour les demandes de tirage (pull requests). Vous pouvez choisir des branches à inclure et à exclure. Cette fonctionnalité était auparavant disponible dans l’interface utilisateur web. En le déplaçant vers le fichier YAML, il fait partie de votre workflow config-as-code.

Un exemple d’utilisation de déclencheurs de demande de tirage peut ressembler à ceci :

pr:
  branches:
    include:
    - features/*
    exclude:
    - features/experimental/*
  paths:
    include:
    - **/*.cs

steps:
- script: echo My PR build!

Utiliser des expressions de modèle YAML inline

Les modèles YAML sont un moyen puissant de réutiliser des parties de pipelines. En plus de factoriser le code commun, les expressions de modèle vous permettent de modifier les valeurs et de contrôler ce que YAML est inclus. Jusqu’à présent, une expression de modèle devait occuper la valeur entière dans une expression YAML. Cet exemple fonctionne, car l’expression est la valeur entière de la propriété de la solution .

- task: msbuild@1
  inputs:
    solution: ${{ parameters.solution }}

Nous avons maintenant assoupli la restriction et autorisé les modèles inline comme vous le voyez dans l’exemple ci-dessous.

- script: echo The solution file is ${{ parameters.solution }}

Améliorer la résolution des problèmes avec le journal d’initialisation du pipeline

Lorsqu’un pipeline s’exécute, Azure Pipelines doit s’assurer que la définition du pipeline est correcte, décider des travaux à planifier, demander aux agents d’exécuter les travaux, etc. Jusqu’à présent, ce processus était totalement opaque, de sorte que lorsque les choses ont mal tourné, il était presque impossible pour un client de résoudre le problème. Nous introduisons un nouveau type de journal, appelé journal d’initialisation du pipeline, qui rend ces détails visibles. Vous pouvez accéder au journal d’initialisation du pipeline en choisissant l’option Télécharger tous les journaux sur une build terminée.

Rétention par défaut pour les pipelines YAML

Nous travaillons sur un moyen pour les utilisateurs de configurer des stratégies de rétention pour les pipelines YAML. Tant que cette nouvelle fonctionnalité n’est pas disponible, nous avons augmenté la rétention par défaut de toutes les builds YAML à 30 jours, car de nombreux utilisateurs souhaitent conserver leurs builds pendant plus longtemps que la rétention par défaut de 10 jours précédente. Nous avons supprimé l’onglet rétention dans l’éditeur pour les pipelines YAML jusqu’à ce que le nouveau modèle soit en place.

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

L’agent multiplateforme Azure Pipelines open source a toujours été pris en charge sur Windows, macOS et Linux 64 bits (x64). Ce sprint, nous introduisons deux nouvelles plateformes prises en charge : Linux/ARM et Windows/32 bits. Ces nouvelles plateformes vous donnent la possibilité de créer sur des plateformes moins courantes, mais non moins importantes, telles que le Raspberry Pi, une machine Linux/ARM.

Cloner des groupes de variables

Nous avons ajouté la prise en charge du clonage des groupes de variables. Chaque fois que vous souhaitez répliquer un groupe de variables et simplement mettre à jour quelques-unes des variables, vous n’avez pas besoin de passer par le processus fastidieux d’ajout de variables une par une. 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.

Notes

Les valeurs des variables secrètes ne sont pas copiées lorsque vous clonez un groupe de variables. Vous devez mettre à jour les variables chiffrées, puis enregistrer le groupe de variables cloné.

Consultez commits et éléments de travail pour toutes les sources liées

Poursuivant notre engagement en faveur d’une meilleure traçabilité, nous sommes heureux d’annoncer que les clients peuvent désormais voir les détails des éléments de validation et de travail pour tous les artefacts liés au pipeline. Par défaut, la validation et l’élément de travail sont comparés au dernier déploiement à la même étape. Toutefois, vous pouvez comparer avec n’importe quel autre déploiement précédent si nécessaire.

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

La version Azure App Service Deploy task (4.*) prend désormais en charge RunFromPackage (anciennement RunFromZip).

App Service prend en charge un certain nombre de techniques différentes pour déployer vos fichiers, telles 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 Exécuter à partir du package, il n’existe plus d’étape de déploiement qui copie les fichiers individuels dans wwwroot. Au lieu de cela, vous le 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 App Server

La version 4.* de la tâche Azure App Service Deploy prend désormais en charge le déploiement de votre propre conteneur personnalisé pour 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 App Service tâche De déploiement.
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 d’une dépendance ou d’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.

Azure Test Plans

Client Azure Test Runner pour exécuter des tests manuels pour les applications de bureau

Vous pouvez maintenant utiliser le client Azure Test Runner (ATR) 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 ATR, 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.

ATR nécessite un téléchargement et une installation ponctuels de l’exécuteur. Sélectionnez Exécuter pour l’application de bureau comme indiqué ci-dessous.

Azure Artifacts

Préversion publique des artefacts de pipeline

Nous publions une préversion publique des artefacts de pipeline, un nouveau type d’artefact hautement évolutif conçu pour une utilisation avec Azure Pipelines. Pipeline Artifacts est basé sur la même technologie que celle utilisée par la fonctionnalité packages universels récemment annoncée et peut réduire considérablement le temps nécessaire pour stocker les sorties de build pour les builds de grande taille.

Wiki

Publier du code en tant que wiki avec des autorisations De contribution

Auparavant, seuls les utilisateurs disposant de l’autorisation Créer un dépôt sur un dépôt Git pouvaient publier du code en tant que wiki. Cela a fait des administrateurs ou des créateurs de dépôt 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 dépôt de code.

Administration

Les PAT appliquent le CAP

En février 2017, nous avons annoncé la prise en charge de la stratégie d’accès conditionnel (CAP) Azure Active Directory, mais il y avait une limitation selon laquelle d’autres mécanismes d’authentification, tels que les jetons d’accès personnels, n’appliqueraient pas cap. Nous sommes heureux d’annoncer que nous avons comblé cette lacune et Qu’Azure DevOps honorera désormais les stratégies d’isolation IP CAP lors de l’utilisation de PAT, de clés SSH, d’informations d’identification d’authentification alternatives et d’OAuth. Les administrateurs n’ont rien à faire pour tirer parti de cette fonctionnalité. Elle est automatiquement appliquée à toutes les stratégies existantes.

Étapes suivantes

Notes

Ces fonctionnalités seront déployées au cours des deux à trois prochaines semaines.

Découvrez les nouvelles fonctionnalités ci-dessous et accédez à Azure DevOps pour les essayer par vous-même.

Accédez à Azure DevOps

Comment fournir des commentaires

Nous aimerions savoir ce que vous pensez de ces fonctionnalités. Utilisez le menu de commentaires pour signaler un problème ou fournir une suggestion.

Vous pouvez également obtenir des conseils et répondre à vos questions par la communauté sur Stack Overflow.

Merci,

Aaron Bjork