Notes de publication de Azure DevOps Server 2020 Update 1


| Communauté
| des développeurs Configuration requise et compatibilité
| Termes du contrat de licence
| Blog DevOps
| Hachages SHA-1 |


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

Pour en savoir plus sur l’installation ou la mise à niveau d’un déploiement de Azure DevOps Server, consultez Azure DevOps Server Configuration requise.

Pour télécharger Azure DevOps Server produits, visitez la page téléchargements Azure DevOps Server.

La mise à niveau directe vers Azure DevOps Server 2020 Update 1 RC2 est prise en charge à partir de Azure DevOps Server 2020, 2019 ou Team Foundation Server 2015 ou version ultérieure. Si votre déploiement de TFS est sur TFS 2013 ou une version antérieure, vous devez effectuer certaines étapes intermédiaires avant la mise à niveau vers Azure DevOps Server 2020. Pour plus d’informations, consultez la page d’installation .


Date de publication de Azure DevOps Server 2020,1 RC2:13 avril 2021

Résumé des nouveautés de Azure DevOps Server 2020,1 RC2

Azure DevOps Server 2020,1 RC2 est un cumul de correctifs de bogues. Il comprend toutes les fonctionnalités de la Azure DevOps Server 2020,1 RC1 précédemment publiées.

Date de publication de Azure DevOps Server 2020,1 RC1:23 mars, 2021

Résumé des nouveautés de Azure DevOps Server 2020,1 RC1

Azure DevOps Server 2020,1 RC1 introduit de nombreuses nouvelles fonctionnalités. Voici les principales :

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


Boards

Règles de restriction de transition d’État

Nous continuons de fermer l’écart de parité entre les composants XML hébergé et le modèle de processus hérité. Cette nouvelle règle de type d’élément de travail vous permet de limiter le déplacement des éléments de travail d’un État à un autre. Par exemple, vous pouvez empêcher les bogues de passer de l’un à l’autre à résolu. Au lieu de cela, ils doivent passer de nouveau – > > résolu actif

img

Vous pouvez également créer une règle pour restreindre les transitions d’État par appartenance à un groupe. Par exemple, seuls les utilisateurs du groupe « approbateurs » peuvent déplacer les récits utilisateur du nouveau > approuvé.

Copier l’élément de travail pour copier les enfants

L’une des principales fonctionnalités demandées pour Azure Boards est la possibilité de copier un élément de travail qui copie également les éléments de travail enfants. Nous avons ajouté une nouvelle option pour " inclure les éléments de travail enfants " dans la boîte de dialogue Copier l’élément de travail. Quand cette option est sélectionnée, cette option copie l’élément de travail et copie tous les éléments de travail enfants (jusqu’à 100).

Cette page affiche la nouvelle option dans Azure Boards pour inclure des éléments de travail enfants dans un élément de travail copié.

Règles améliorées pour les champs activés et résolus

Jusqu’à présent, les règles pour activé par, Date d’activation, résolu par et Date de résolution sont un mystère. Elles sont uniquement définies pour les types d’éléments de travail système et sont spécifiques à la valeur d’État « active » et « résolue ». Nous avons modifié la logique afin que ces règles ne soient plus pour un état spécifique. Au lieu de cela, ils sont déclenchés par la catégorie (catégorie d’État) dans laquelle l’État réside. Par exemple, supposons que vous avez un état personnalisé « nécessite un test » dans la catégorie résolu. Lorsque l’élément de travail passe de « actif » à « nécessite un test », les règles résolues par et Date de résolution sont déclenchées.

Cela permet aux clients de créer des valeurs d’état personnalisées tout en générant les champs activé par, Date d’activation, résolu par et Date de résolution , sans qu’il soit nécessaire d’utiliser des règles personnalisées.

Les parties prenantes peuvent déplacer des éléments de travail dans les colonnes du tableau

Les parties prenantes ont toujours été en mesure de modifier l’état des éléments de travail. Mais lorsqu’ils accèdent au tableau kanban, ils ne peuvent pas déplacer les éléments de travail d’une colonne à une autre. Au lieu de cela, les parties prenantes doivent ouvrir chaque élément de travail, une à la fois, et mettre à jour la valeur d’État. Cela a longtemps été un point délicat pour les clients et nous sommes heureux de vous annoncer que vous pouvez désormais déplacer des éléments de travail dans les colonnes du tableau.

Types d’éléments de travail système sur les journaux des travaux en souffrance et les tableaux

Vous pouvez maintenant ajouter un type d’élément de travail système au niveau de backlog de votre choix. Historiquement, ces types d’éléments de travail sont uniquement disponibles à partir de requêtes.

Processus Type d'élément de travail
Agile Problème
Scrum Obstacle
CMMI Demande de modification
Problème
Révision
Risque

L’ajout d’un type d’élément de travail système à un niveau de backlog est simple. Il vous suffit d’accéder à votre processus personnalisé et de cliquer sur l’onglet niveaux de backlog. Sélectionnez le niveau de backlog de votre choix (par exemple : backlog de spécifications) et Choisissez l’option modifier. Ajoutez ensuite le type d’élément de travail.

backlogs

Azure Boards limite référentiel de l’application GitHub levée

La limite référentiel pour l' application Azure Boards dans la place de marché GitHub a été augmentée de 100 à 250.

Personnaliser l’état de l’élément de travail lorsque la requête de tirage est fusionnée

Tous les flux de travail ne sont pas identiques. Certains clients souhaitent fermer leurs éléments de travail associés lorsqu’une requête de tirage est terminée. D’autres souhaitent définir les éléments de travail à un autre État à valider avant la fermeture. Nous devons autoriser les deux.

Nous avons une nouvelle fonctionnalité qui vous permet de définir les éléments de travail à l’état souhaité lorsque la requête de tirage est fusionnée et terminée. Pour ce faire, nous allons analyser la description de la demande de tirage (pull request) et rechercher la valeur d’État suivie de la #mention du ou des éléments de travail. Dans cet exemple, nous définissons deux récits utilisateur sur résolu et fermons deux tâches.

work-item-state

Vous pouvez maintenant facilement effectuer le suivi de vos dépendances de build dans le projet, en liant simplement votre élément de travail à une build, à une build, ou intégrée à la Build.

link work items

Description de la modification (texte d’aide) sur les champs système

Vous avez toujours pu modifier la description des champs personnalisés. Toutefois, pour les champs système tels que priorité, gravité et activité, la description n’est pas modifiable. Il s’agissait d’un écart de fonctionnalités entre le XML hébergé et hérité qui empêchait certains clients de migrer vers le modèle hérité. Vous pouvez maintenant modifier la description dans les champs système. La valeur modifiée n’affecte que ce champ dans le processus et pour ce type d’élément de travail. Cela vous donne la possibilité d’avoir des descriptions différentes pour le même champ sur différents types d’éléments de travail.

edit description

Personnaliser l’état de l’élément de travail lorsque la requête de tirage est fusionnée

Les requêtes de tirage font souvent référence à plusieurs éléments de travail. Lorsque vous créez ou mettez à jour une requête de tirage, vous pouvez fermer certaines d’entre elles, résoudre certaines d’entre elles et garder le reste ouvert. Vous pouvez maintenant utiliser des commentaires tels que ceux illustrés dans la figure ci-dessous pour y parvenir. Pour plus d’informations, consultez la documentation.

Customize state

Champ parent dans le tableau de tâches

En raison d’une demande populaire, vous pouvez maintenant ajouter le champ parent aux cartes enfant et parente dans le tableau de tâches.

parent field task board

Suppression de la règle « Affecté à » dans le type d’élément de travail bogue

Il existe plusieurs règles système masquées pour tous les différents types d’éléments de travail dans agile, Scrum et CMMI. Ces règles ont existé depuis plus de dix ans et ont généralement fonctionné correctement sans aucune réclamation. Toutefois, il existe quelques règles qui ont exécuté leur accueil. Une règle en particulier a entraîné beaucoup de difficultés pour les clients nouveaux et existants et nous avons décidé qu’il était temps de la supprimer. Cette règle existe sur le type d’élément de travail bogue dans le processus agile.

« Définissez la valeur assignée sur créé par lorsque l’état passe à résolu »

Nous avons reçu beaucoup de commentaires sur cette règle. En réponse, nous avons supprimé cette règle du type d’élément de travail bogue dans le processus agile. Cette modification affecte chaque projet à l’aide d’un processus agile hérité ou personnalisé hérité. Pour les clients qui aiment et dépendent de cette règle actuelle, consultez notre billet de blog sur les étapes que vous pouvez suivre pour rajouter la règle dans à l’aide de règles personnalisées.

Éléments supprimés sur la page d’éléments de travail

La page éléments de travail est l’endroit idéal pour trouver rapidement les éléments que vous avez créés ou qui vous sont assignés, entre autres choses. Il fournit plusieurs tableaux croisés dynamiques et filtres personnalisés. L’une des principales plaintes pour le tableau croisé dynamique « assigné à moi » est qu’elle affiche les éléments de travail supprimés (autrement dit, les éléments de travail à l’état supprimé). Et nous sommes d’accord ! Les éléments supprimés sont du travail qui n’est plus de valeur et qui, par conséquent, a été supprimé du backlog, donc son inclusion dans cette vue n’est pas utile.

Vous pouvez maintenant masquer tous les éléments supprimés du tableau croisé dynamique qui m’est assigné sur la page éléments de travail.

Repos

Préférence du nom de la branche par défaut

Azure Repos offre désormais un nom de branche par défaut personnalisable pour git. Dans paramètres du référentiel, vous pouvez choisir n’importe quel nom de branche juridique à utiliser lorsqu’un dépôt est initialisé. Azure Repos a toujours pris en charge la modification du nom de branche par défaut pour un référentiel existant. Pour plus d’informations, consultez gérer les branches .

 default-branch-name

Remarque : Si vous n’activez pas cette fonctionnalité, vos référentiels seront initialisés avec le nom par défaut de Azure Repos. Pour le moment, la valeur par défaut est Master. Pour honorer l’engagement de Microsoft envers, et les demandes des clients pour, la langue inclusive, nous allons joindre les pairs de l' industrie à la modification de cette valeur par défaut. Cette modification aura lieu plus tard cet été. Si vous souhaitez continuer à utiliser Master, vous devez activer cette fonctionnalité et la définir sur Master.

Paramètre au niveau de l’Organisation pour la branche par défaut

Il existe désormais un paramètre au niveau de la collection pour le nom de votre branche initiale préférée pour les nouveaux dépôts. Si un projet n’a pas choisi de nom de branche initial, ce paramètre au niveau de l’organisation sera utilisé. Si vous n’avez pas spécifié le nom de la branche initiale dans les paramètres de l’organisation ou les paramètres du projet, les nouveaux référentiels utilisent une valeur par défaut Azure DevOps définie.

branch setting for org level

Ajouter une nouvelle étendue d’authentification pour les commentaires des demandes de tirage

Cette version ajoute une nouvelle étendue OAuth pour la lecture et l’écriture de commentaires de requête de tirage. Si vous avez un bot ou une automatisation qui doit uniquement interagir avec des commentaires, vous pouvez lui attribuer un PAT avec uniquement cette étendue. Ce processus réduit le rayon de l’explosion si l’automatisation a un bogue ou si le jeton a été compromis.

Améliorations de l’expérience de requête de tirage

La nouvelle expérience de requête de tirage a été améliorée avec les éléments suivants :

  • Rendre les vérifications facultatives plus visibles

Les clients utilisent des vérifications facultatives pour attirer l’attention d’un développeur sur des problèmes potentiels. Dans l’expérience précédente, elle était évidente lorsque ces vérifications échouent. Toutefois, ce n’est pas le cas dans l’expérience de la version préliminaire. Une coche verte importante sur les vérifications requises masque les échecs dans les vérifications facultatives. Les utilisateurs ne pouvaient découvrir que les vérifications facultatives ayant échoué en ouvrant le panneau vérifications. Les développeurs ne le font pas souvent lorsqu’il n’existe aucune indication de problème. Dans ce déploiement, nous avons rendu le statut des vérifications facultatives plus visible dans le résumé.


show the optional checks


  • Ctrl + clics sur les éléments de menu

Les menus d’onglet sur une demande de tirage ne prennent pas en charge Ctrl + clic. Les utilisateurs ouvrent souvent de nouveaux onglets de navigateur lorsqu’ils examinent une requête de tirage. Ce problème a été résolu.

  • Emplacement de l’annotation [+]

La liste d’arborescence des fichiers dans une demande de tirage (PR) affiche une annotation [+] pour aider les auteurs et les réviseurs à identifier les nouveaux fichiers. Étant donné que l’annotation était après les points de suspension, elle n’était souvent pas visible pour les noms de fichiers plus longs.


show locations of annotations

  • Informations de temporisation de la liste déroulante des mises à jour PR

La liste déroulante permettant de sélectionner mettre à jour et comparer des fichiers dans une demande de tirage a perdu un élément important dans l’expérience d’aperçu. Il n’a pas affiché quand cette mise à jour a été effectuée. Ce problème a été résolu.


PR updates dropdown missing timing information

      • Amélioration de la disposition des filtres de commentaires * *

Lorsque vous filtrez des commentaires sur la page Résumé d’une requête de tirage, la liste déroulante était à droite, mais le texte est aligné à gauche. Ce problème a été résolu.


Improved comment filter layout

  • Navigation vers les validations parentes

Sous la page validations, vous pouvez comparer les modifications apportées à une validation particulière avec sa validation parente. Toutefois, vous pouvez accéder à la validation parente et mieux comprendre comment cette validation diffère de son propre parent. Cela est souvent nécessaire lorsque vous souhaitez comprendre toutes les modifications apportées à une version. Nous avons ajouté une carte parent (s) à une validation pour vous aider à y parvenir.


Navigation to parent commits

  • Plus d’espace pour les dossiers et les fichiers avec des noms longs dans l’onglet fichiers PR

Les dossiers et les fichiers portant des noms longs ont été coupés en raison d’un manque d’espacement horizontal dans l’arborescence de fichiers. Nous avons récupéré de l’espace supplémentaire dans l’arborescence en modifiant la mise en retrait de l’arborescence pour qu’elle corresponde au nœud racine et en masquant le bouton de sélection dans la page, à l’exception de hover.

Image de la nouvelle arborescence de fichiers :


More space for folders and files

Image de l’arborescence de fichiers lorsque vous pointez sur un répertoire :


Name display

  • Conserver la position de défilement lors du redimensionnement du volet diff dans l’onglet fichiers PR

Lors du redimensionnement du volet diff côte à côte dans l’onglet fichiers PR, l’emplacement de défilement de l’utilisateur est perdu. Ce problème a été résolu ; l’emplacement de défilement de l’utilisateur est maintenant conservé sur un redimensionnement du volet diff.

  • Rechercher une validation sur un appareil mobile

Lorsque vous affichez la page de validations sur un appareil mobile, la zone de recherche est manquante dans la nouvelle expérience. Par conséquent, il est difficile de trouver une validation par son hachage et de l’ouvrir. Ce problème a été résolu.


Search for a commit on a mobile device

  • Utilisation améliorée de l’espace pour le nouveau fichier PR diff mobile View

Nous avons mis à jour cette page pour améliorer l’utilisation de l’espace afin que les utilisateurs puissent voir davantage de fichiers dans les vues mobiles au lieu d’avoir 40% de l’écran par un en-tête.


Improved usage of space new PR filename

  • Images améliorées en mode Résumé des demandes de tirage

Les images modifiées dans une demande de tirage n’étaient pas affichées dans la vue Résumé des demandes de tirage, mais s’affichaient correctement dans la vue des fichiers PR. Ce problème a été résolu.

  • Expérience de branche améliorée lors de la création d’une demande de tirage

Avant cette mise à jour, cette expérience n’était pas idéale car elle comparait les modifications avec la branche par défaut du référentiel au lieu de la branche de comparaison.


branch experience enhancement

Pipelines

Plateforme supplémentaire de l’agent : ARM64

Nous avons ajouté Linux/ARM64 à la liste des plateformes prises en charge pour l’agent Azure Pipelines. Bien que les modifications du code soient minimes, un grand nombre de travaux en arrière-plan devaient être exécutés en premier, et nous sommes ravis d’annoncer sa publication.

Prise en charge des filtres de balises pour les ressources de pipeline

Nous avons maintenant ajouté « Tags » dans les pipelines YAML. Vous pouvez utiliser des balises pour définir le pipeline CI à exécuter ou quand déclencher automatiquement.

resources:
  pipelines:
  - pipeline: MyCIAlias
    project: Fabrikam
    source: Farbrikam-CI
    branch: master
    tags:              ### This filter is used for resolving default version
    - Production       ### Tags are AND'ed
    trigger:
      tags:            ### This filter is used for triggering the pipeline run
      - Production     ### Tags are AND'ed
      - Signed

L’extrait de code ci-dessus montre que des balises peuvent être utilisées pour déterminer la version par défaut du pipeline d’intégration continue (intégration continue) à exécuter lorsque l’exécution du pipeline de CD (déploiement continu) n’est pas déclenchée par une autre source/ressource ou un déclencheur d’exécution planifié.

Par exemple, si vous avez un déclencheur planifié défini pour votre pipeline de CD que vous souhaitez exécuter uniquement si votre CI contient la balise de production, les balises dans la section déclencheurs garantissent que le pipeline de CD est déclenché uniquement si la condition de marquage est satisfaite par l’événement d’achèvement CI.

Contrôler les tâches autorisées dans les pipelines

Vous pouvez désormais désactiver les tâches de la place de marché. Certaines d’entre elles peuvent autoriser des extensions Marketplace, mais pas les tâches de pipeline qu’elles apportent. Pour un meilleur contrôle, nous vous autorisons également à désactiver indépendamment toutes les tâches intégrées (à l’exception de l’extraction, qui est une action spéciale). Lorsque ces deux paramètres sont activés, les seules tâches autorisées à s’exécuter dans un pipeline sont celles qui sont chargées à l’aide de TFX. Visitez https://dev.azure.com/<your_org>/_settings/pipelinessettings et recherchez la section intitulée « restrictions de tâches » pour commencer.

Stratégie de verrouillage de déploiement exclusif

Avec cette mise à jour, vous pouvez vous assurer qu’une seule exécution est déployée dans un environnement à la fois. En choisissant la vérification « verrou exclusif » sur un environnement, une seule exécution se poursuit. Les exécutions suivantes qui veulent être déployées sur cet environnement sont suspendues. Une fois l’exécution du verrou exclusif terminée, la dernière exécution se poursuit. Toutes les exécutions intermédiaires seront annulées.

Dans la page Ajouter une vérification, sélectionnez verrou exclusif pour vous assurer qu’une seule exécution est déployée dans un environnement à la fois.

Filtres de phases pour les déclencheurs de ressource de pipeline

Nous avons ajouté la prise en charge de « étapes » en tant que filtre pour les ressources de pipeline dans YAML. Avec ce filtre, vous n’avez pas besoin d’attendre la fin du pipeline CI entier pour déclencher votre pipeline de CD. Vous pouvez maintenant choisir de déclencher votre pipeline de CD après l’achèvement d’une étape spécifique dans votre pipeline d’intégration continue.

resources:
  pipelines:
  - pipeline: MyCIAlias  
    project: Fabrikam  
    source: Farbrikam-CI  
    trigger:    
      stages:            ### This stage filter is used when evaluating conditions for triggering your CD pipeline
      - PreProduction    ### stages are AND'ed. On successful completion of all the stages provided, your CD pipeline will be triggered. 
      - Production

Lorsque les étapes fournies dans le filtre de déclencheur sont terminées avec succès dans votre pipeline d’intégration continue, une nouvelle exécution est automatiquement déclenchée pour votre pipeline de CD.

Déclencheurs génériques basés sur webhook pour les pipelines YAML

Aujourd’hui, nous disposons de plusieurs ressources (telles que des pipelines, des conteneurs, des builds et des packages) par le biais desquelles vous pouvez consommer des artefacts et activer des déclencheurs automatisés. Toutefois, jusqu’à présent, vous n’avez pas pu automatiser votre processus de déploiement en fonction d’autres services ou événements externes. Dans cette version, nous avons introduit la prise en charge des déclencheurs webhook dans les pipelines YAML pour permettre l’intégration de l’automatisation des pipelines à n’importe quel service externe. Vous pouvez vous abonner à des événements externes par le biais de ses webhooks (GitHub, GitHub Enterprise, connexion, Aritfactory, etc.) et déclencher vos pipelines.

Voici les étapes à suivre pour configurer les déclencheurs webhook :

  1. Configurez un webhook sur votre service externe. Lors de la création de votre webhook, vous devez fournir les informations suivantes :

    • URL de la demande : " https://dev.azure.com/ /_apis/public/distributedtask/webhooks/<nom du webhook> ? API-version = 6.0-version préliminaire"
    • Secret : facultatif. Si vous devez sécuriser votre charge utile JSON, fournissez la valeur de secret
  2. Créer une connexion de service « webhook entrant ». Il s’agit d’un type de connexion de service récemment introduit qui vous permettra de définir trois informations importantes :

    • Nom du webhook: le nom du webhook doit correspondre au webhook créé dans votre service externe.
    • En-tête http : nom de l’en-tête http dans la demande qui contient la valeur de hachage de la charge utile pour la vérification de la demande. Par exemple, dans le cas de GitHub, l’en-tête de la demande sera «X-Hub-signature»
    • Secret : le secret est utilisé pour analyser le hachage de charge utile utilisé pour la vérification de la demande entrante (facultatif). Si vous avez utilisé un secret pour créer votre webhook, vous devrez fournir la même clé secrète

    Dans la page modifier la connexion de service, configurez les déclencheurs webhook.

  3. Un nouveau type de ressource appelé webhooks est introduit dans les pipelines YAML. Pour vous abonner à un événement webhook, vous devez définir une ressource de webhook dans votre pipeline et la faire pointer vers la connexion du service webhook entrant. Vous pouvez également définir des filtres supplémentaires sur la ressource webhook en fonction des données de charge utile JSON pour personnaliser davantage les déclencheurs pour chaque pipeline, et vous pouvez utiliser les données de charge utile sous la forme de variables dans vos travaux.

resources:
  webhooks:
    - webhook: MyWebhookTrigger          ### Webhook alias
      connection: MyWebhookConnection    ### Incoming webhook service connection
      filters:
        - path: repositoryName      ### JSON path in the payload
          value: maven-releases     ### Expected value in the path provided
        - path: action
          value: CREATED
steps:
- task: PowerShell@2
  inputs:
    targetType: 'inline'
    ### JSON payload data is available in the form of ${{ parameters.<WebhookAlias>.<JSONPath>}}
    script: |
      Write-Host ${{ parameters.MyWebhookTrigger.repositoryName}}
      Write-Host ${{ parameters.MyWebhookTrigger.component.group}}
  1. Chaque fois qu’un événement webhook est reçu par la connexion du service webhook entrant, une nouvelle exécution est déclenchée pour tous les pipelines souscrits à l’événement webhook.

Prise en charge et traçabilité des problèmes de déclencheur de ressource YAML

Cela peut être confus lorsque les déclencheurs de pipeline ne parviennent pas à s’exécuter comme vous l’attendez. Pour mieux comprendre cela, nous avons ajouté un nouvel élément de menu dans la page de définition du pipeline appelé « déclencheur Problems », où les informations sont signalées en fonction de la raison pour laquelle les déclencheurs ne sont pas exécutés.

L’exécution des déclencheurs de ressources peut échouer pour deux raisons.

  1. Si la source de la connexion de service fournie n’est pas valide ou s’il existe des erreurs de syntaxe dans le déclencheur, le déclencheur ne sera pas configuré du tout. Ils sont exposés en tant qu’erreurs.

  2. Si les conditions du déclencheur ne sont pas mises en correspondance, le déclencheur ne s’exécute pas. Chaque fois que cela se produit, un avertissement s’affiche pour vous permettre de comprendre pourquoi les conditions n’ont pas été mises en correspondance.

    Cette page de définition de pipeline appelée problèmes de déclencheur affiche des informations sur les raisons pour lesquelles les déclencheurs ne sont pas exécutés.

Déclencheurs à plusieurs référentiel

Vous pouvez spécifier plusieurs référentiels dans un fichier YAML et provoquer le déclenchement d’un pipeline par les mises à jour de l’un des référentiels. Cette fonctionnalité est utile, par exemple, dans les scénarios suivants :

  • Vous consommez un outil ou une bibliothèque à partir d’un référentiel différent. Vous souhaitez exécuter des tests pour votre application chaque fois que l’outil ou la bibliothèque est mis à jour.
  • Vous conservez votre fichier YAML dans un dépôt distinct du code de l’application. Vous souhaitez déclencher le pipeline chaque fois qu’une mise à jour est envoyée au référentiel d’applications.

Avec cette mise à jour, les déclencheurs référentiel ne fonctionnent que pour les dépôts Git dans Azure Repos. Ils ne fonctionnent pas pour les ressources de référentiel GitHub ou BitBucket.

Voici un exemple qui montre comment définir plusieurs ressources de référentiel dans un pipeline et comment configurer des déclencheurs sur chacun d’eux.

trigger:
- main

resources:
  repositories:
  - repository: tools
    type: git
    name: MyProject/tools
    ref: main
    trigger:
      branches:
        include:
        - main
        - release

Dans cet exemple, le pipeline est déclenché s’il existe des mises à jour pour :

  • main branche dans le self référentiel contenant le fichier YAML
  • main ou release branches dans tools référentiel

Pour plus d’informations, consultez plusieurs dépôts dans votre pipeline.

Améliorations des téléchargements du journal de l’agent

Lorsqu’un agent cesse de communiquer avec le serveur Azure Pipelines, le travail qu’il exécutait devient abandonné. Si vous observez les journaux de la console de streaming, vous pouvez avoir obtenu des indices sur ce que l’agent faisait juste avant de cesser de répondre. Mais si ce n’est pas le cas, ou si vous actualisez la page, les journaux de la console ont disparu. Avec cette version, si l’agent ne répond plus avant d’envoyer ses journaux complets, nous conservons les journaux de la console comme étant la meilleure chose. Les journaux de la console sont limités à 1000 caractères par ligne et peuvent parfois être incomplets, mais ils sont beaucoup plus utiles que rien ! L’examen de ces journaux peut vous aider à dépanner vos propres pipelines, et il aide certainement nos ingénieurs de support technique lors de la résolution des problèmes.

Vous pouvez également monter des volumes de conteneur en lecture seule

Lorsque vous exécutez un travail de conteneur dans Azure Pipelines, plusieurs volumes contenant l’espace de travail, les tâches et d’autres éléments sont mappés en tant que volumes. Ces volumes disposent par défaut d’un accès en lecture/écriture. Pour une sécurité accrue, vous pouvez monter les volumes en lecture seule en modifiant votre spécification de conteneur dans YAML. Chaque clé sous mountReadOnly peut avoir la valeur true pour lecture seule (la valeur par défaut est false ).

resources:
  containers:
    - container: example
      image: ubuntu:18.04
      mountReadOnly:
        externals: true
        tasks: true
        tools: true
        work: false

Contrôle affiné sur le démarrage/l’arrêt d’un conteneur

En général, nous vous recommandons d’autoriser Azure Pipelines à gérer le cycle de vie de vos conteneurs de travaux et de services. Toutefois, dans certains scénarios rares, vous souhaiterez peut-être les démarrer et les arrêter vous-même. Avec cette version, nous avons créé cette fonctionnalité dans la tâche d’ancrage.

Voici un exemple de pipeline utilisant la nouvelle fonctionnalité :

resources:
  containers:
    - container: builder
      image: ubuntu:18.04
steps:
  - script: echo "I can run inside the container (it starts by default)"
    target:
      container: builder
  - task: Docker@2
    inputs:
      command: stop
      container: builder
# if any step tried to run in the container here, it would fail

En outre, nous incluons la liste des conteneurs dans une variable de pipeline, Agent.ContainerMapping . Vous pouvez utiliser cette valeur si vous souhaitez examiner la liste des conteneurs dans un script, par exemple. Elle contient un objet JSON converti mappant le nom de la ressource (« générateur » de l’exemple ci-dessus) à l’ID de conteneur géré par l’agent.

Décompresser des groupes de tâches pour chaque étape

Lorsque l’agent exécute un travail, il télécharge tout d’abord tous les groupes de tâches requis par les étapes du travail. Normalement, pour des performances optimales, elle décompresse les tâches une fois par tâche, même si la tâche est utilisée en plusieurs étapes. Si vous avez des doutes sur le code non approuvé modifiant le contenu non compressé, vous pouvez échanger un peu de performances en faisant en sorte que l’agent décompresse la tâche à chaque utilisation. Pour activer ce mode, transmettez --alwaysextracttask l’agent lors de la configuration de l’agent.

Améliorer la sécurité des versions en limitant l’étendue des jetons d’accès

En s’appuyant sur notre initiative pour améliorer les paramètres de sécurité de Azure Pipelines, nous prenons désormais en charge la limitation de l’étendue des jetons d’accès pour les mises en production.

Chaque travail qui s’exécute dans les versions de reçoit un jeton d’accès. Le jeton d’accès est utilisé par les tâches et par vos scripts pour effectuer un rappel dans Azure DevOps. Par exemple, nous utilisons le jeton d’accès pour obtenir le code source, télécharger des artefacts, télécharger des journaux, des résultats de tests ou pour effectuer des appels REST dans Azure DevOps. Un nouveau jeton d’accès est généré pour chaque travail, et il expire une fois le travail terminé.

Avec cette mise à jour, nous nous appuyons sur l’amélioration de la sécurité du pipeline en limitant l’étendue des jetons d’accès et en étendant les mêmes mises en production classiques.

Cette fonctionnalité est activée par défaut pour les nouveaux projets et Collections. Pour les regroupements existants, vous devez les activer dans les paramètres de regroupement > pipelines > paramètres. > limiter l’étendue de l’autorisation du travail au projet actuel pour les pipelines de mise en service. En savoir plus ici.

Améliorations de l’API YAML preview

Vous pouvez maintenant afficher un aperçu de la YAML complète d’un pipeline sans l’exécuter. En outre, nous avons créé une nouvelle URL dédiée pour la fonctionnalité de préversion. Vous pouvez maintenant effectuer une publication sur https://dev.azure.com/{collection}/{project}/_apis/pipelines/{pipelineId}/preview pour récupérer le corps YAML finalisé. Cette nouvelle API prend les mêmes paramètres que la mise en file d’attente d’une exécution, mais ne requiert plus l' " autorisation builds de file d’attente " .

Exécuter ce travail suivant

Avez-vous déjà eu un ensemble vos résolutions que vous deviez déployer à ce moment -là, mais qui devaient attendre derrière les travaux ci et PR ? Avec cette version, nous allons maintenant vous permettre de prendre en main la priorité d’un travail mis en file d’attente. Les utilisateurs disposant de l’autorisation « gérer » sur le pool (généralement administrateurs du pool) voient un nouveau bouton « Exécuter suivant » sur la page des détails du travail. Si vous cliquez sur le bouton, la tâche sera exécutée dès que possible. (Vous aurez toujours besoin d’un parallélisme disponible et d’un agent approprié, bien sûr.)

Expressions de modèle autorisées dans le resources bloc YAML

Auparavant, les expressions au moment de la compilation () n' ${{ }} étaient pas autorisées dans la resources section d’un fichier Azure pipelines YAML. Avec cette version, nous avons levé cette restriction pour les conteneurs. Cela vous permet d’utiliser le contenu des paramètres d’exécution à l’intérieur de vos ressources, par exemple pour choisir un conteneur au moment de la file d’attente. Nous prévoyons d’étendre cette prise en charge à d’autres ressources au fil du temps.

Contrôle des mises à jour automatiques des tâches à partir de Marketplace

Lorsque vous écrivez un pipeline YAML, vous spécifiez normalement uniquement le numéro de version principale des tâches incluses. Cela permet à vos pipelines de prendre automatiquement les derniers ajouts de fonctionnalités et les correctifs de bogues. Parfois, vous devrez peut-être revenir à une version précédente d’une tâche et, avec cette mise à jour, nous avons ajouté la possibilité de le faire. Vous pouvez maintenant spécifier une version de tâche majeure. minor. patch complète dans vos pipelines YAML.

Nous vous déconseillons de faire cela régulièrement et de l’utiliser uniquement comme solution de contournement temporaire lorsque vous constatez qu’une tâche plus récente rompt vos pipelines. En outre, cette opération n’installe pas une version antérieure d’une tâche à partir de la place de marché. Il doit déjà exister dans votre collection, sinon votre pipeline échouera.

Exemple :

steps:
- task: MyTask@1  # a normal, major-version only reference
- task: MyOtherTask@2.3.4   # pinned to a precise version

Prise en charge de node 10 dans l’agent et les tâches

Étant donné que le nœud 6 n’est plus pris en charge, nous migrons les tâches pour qu’elles fonctionnent avec le nœud 10. Pour cette mise à jour, nous avons migré près de 50% des tâches intégrées vers le nœud 10. L’agent peut maintenant exécuter les tâches node 6 et node 10. Dans une prochaine mise à jour, nous supprimerons entièrement le nœud 6 de l’agent. Pour préparer la suppression du nœud 6 de l’agent, nous vous demanderons de mettre à jour vos extensions internes et vos tâches personnalisées pour utiliser également le nœud 10. Pour utiliser le nœud 10 pour votre tâche, dans, task.json sous execution , mettez à jour de Node vers Node10 .

Améliorer la conversion YAML dans le concepteur de builds classique

Avec cette version, nous introduisons une nouvelle fonctionnalité « exporter vers YAML » pour les pipelines de génération de concepteur. Enregistrez la définition de votre pipeline, puis recherchez « exporter vers YAML » dans le ... menu.

La nouvelle fonction d’exportation remplace la fonction « View As YAML » précédemment trouvée dans le concepteur de builds classique. Cette fonction était incomplète car elle pouvait uniquement inspecter le contenu de l’interface utilisateur Web sur la build, ce qui provoquait parfois des YAML incorrects en cours de génération. La nouvelle fonction d’exportation prend en compte exactement la manière dont le pipeline sera traité et génère des YAML avec une fidélité complète au pipeline du concepteur.

Nouvelle conversion de plateforme Web – paramètres de référentiel

Nous avons converti les deux pages de paramètres du référentiel en une expérience unique qui a été mise à niveau vers une nouvelle plate-forme Web. Cette mise à niveau rend non seulement l’expérience plus rapide et plus moderne, mais ces pages fournissent également un point d’entrée unique pour toutes les stratégies du niveau du projet au niveau de la branche.

Nouvelle conversion de plateforme Web.

Avec cette nouvelle expérience, la navigation pour les projets avec un grand nombre de référentiels est devenue plus facile en raison de temps de chargement plus rapides et d’un filtre de recherche ajouté. Vous pouvez également afficher les stratégies de niveau projet et la liste des stratégies référentiel sous l’onglet stratégies.

Affichez les stratégies référentiel sous l’onglet stratégies.

Si vous cliquez sur un référentiel, vous pouvez afficher les stratégies et les autorisations définies au niveau du référentiel. Dans l’onglet stratégies, vous pouvez afficher une liste de toutes les branches sur lesquelles la stratégie est définie. Maintenant, cliquez sur la branche pour afficher les stratégies tout en ne quittant jamais la page Paramètres du référentiel.

Sélectionnez branche pour afficher les stratégies.

Désormais, lorsque des stratégies sont héritées d’une étendue supérieure à celle que vous utilisez, nous vous montrons où la stratégie a été héritée à côté de chaque stratégie individuelle. Vous pouvez également accéder à la page dans laquelle la stratégie de niveau supérieur a été définie en cliquant sur le nom de l’étendue.

Indique l’emplacement d’héritage de la stratégie.

La page de stratégie elle-même a également été mise à niveau vers la nouvelle plate-forme Web avec des sections réductibles. Pour améliorer l’expérience de recherche d’une validation de build spécifique, d’un contrôle d’État ou d’une stratégie de réviseur automatique, nous avons ajouté des filtres de recherche pour chaque section.

Filtres de recherche pour chaque section.

Intégration de la gestion des modifications ServiceNow avec les pipelines YAML

L' application Azure pipelines pour ServiceNow vous permet d’intégrer la gestion des modifications Azure pipelines et ServiceNow. Avec cette mise à jour, nous nous engageons à faire en Azure Pipelines sorte que le processus de gestion des modifications géré dans ServiceNow prenne en charge les pipelines YAML.

En configurant la vérification « ServiceNow change Management » sur une ressource, vous pouvez maintenant suspendre la modification à approuver avant de déployer la build sur cette ressource. Vous pouvez créer automatiquement une nouvelle modification pour une étape ou attendre une demande de modification existante.


ServiceNow Change Management Integration

Vous pouvez également ajouter la UpdateServiceNowChangeRequest tâche dans un travail de serveur pour mettre à jour la demande de modification avec l’état du déploiement, remarques, etc.

Artifacts

Possibilité de créer des flux à l’échelle de l’organisation à partir de l’interface utilisateur

Nous revenons à la possibilité pour les clients de créer et de gérer des flux étendus au regroupement par le biais de l’interface utilisateur Web pour les services local et hébergés.

Vous pouvez maintenant créer des flux à l’échelle de l’organisation via l’interface utilisateur, en accédant à artefacts-> créer un flux et en choisissant un type de flux dans l’étendue.

Créez des flux étendus de collection en sélectionnant artefacts, puis créer un flux et en sélectionnant un type de flux dans l’étendue.

Bien que nous recommandions l’utilisation des flux d’étendue de projet en alignement avec les autres offres Azure DevOps, vous pouvez à nouveau créer, gérer et utiliser des flux d’étendue de collection via l’interface utilisateur et diverses API REST. Pour plus d’informations, consultez notre documentation sur les flux.

Mettre à jour l’API REST de version de package maintenant disponible pour les packages Maven

Vous pouvez maintenant utiliser l' " API REST de la version de package Azure artifacts Update " pour mettre à jour les versions de package Maven. Auparavant, vous pouviez utiliser l’API REST pour mettre à jour des versions de package pour NuGet, Maven, NPM et Universal Packages, mais pas pour les packages Maven.

Pour mettre à jour les packages Maven, utilisez la commande HTTP PATCH comme suit.

PATCH https://pkgs.dev.azure.com/{collection}/{project?}/\_apis/packaging/feeds/{feedId}/maven/groups/{groupId}/artifacts/{artifactId}/versions/{packageVersion}?api-version=5.1-preview.1

Vous pouvez définir les éléments suivants :

Paramètres d’URI

Nom Dans Obligatoire Type Description
artifactId path TRUE string ID d’artefact du package
feed path TRUE string Nom ou ID du flux
groupId path TRUE string ID de groupe du package
collection path TRUE string Nom de la collection Azure DevOps
version path TRUE string Version du package
project path string ID de projet ou nom de projet
api-version query TRUE string Version de l’API à utiliser. Cette valeur doit être définie sur '5,1-preview. 1' pour utiliser cette version de l’API

Corps de la demande

Nom Type Description
views JsonPatchOperation Vue à laquelle la version du package sera ajoutée

Pour plus d’informations, reportez-vous à la documentation de l' API REST lorsqu’elle est mise à jour.

Commentaires

Nous aimerions connaître votre opinion ! Vous pouvez signaler un problème ou fournir une idée et le suivre par le biais de la communauté des développeurs et obtenir des conseils sur Stack Overflow.


Haut de page