Share via

Nouveau widget sprint burndown et sécurité améliorée des pipelines - Sprint 160 Update

  • Article

Dans la mise à jour Sprint 160 d’Azure DevOps, nous avons ajouté un nouveau widget sprint burndown qui prend en charge la gravure par points d’histoire, le nombre de tâches et la somme de champs personnalisés. En outre, nous avons amélioré la sécurité des pipelines en limitant l’étendue des jetons d’accès.

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

Nouveautés d’Azure DevOps

Fonctionnalités

Azure Repos :

Azure Pipelines :

Azure Artifacts :

Création de rapports :

Wiki :

Azure Repos

Administration de la stratégie de branche interpo

Les stratégies de branche sont l’une des fonctionnalités puissantes de Azure Repos qui vous aident à protéger les branches importantes. Bien que la possibilité de définir des stratégies au niveau du projet existe dans l’API REST, il n’y avait pas d’interface utilisateur pour celle-ci. Désormais, les administrateurs peuvent définir des stratégies sur une branche spécifique ou le branche par défaut sur tous les dépôts de leur projet. Par exemple, un administrateur peut exiger deux réviseurs minimum pour toutes les demandes de tirage effectuées dans chaque branche main dans chaque dépôt de son projet. Vous trouverez la fonctionnalité Ajouter une protection de branche dans les paramètres du projet Repos.

Administration de la stratégie de branche interpo.

Azure Pipelines

Expérience utilisateur des pipelines à plusieurs étapes

Nous avons travaillé sur une expérience utilisateur mise à jour pour gérer vos pipelines. Ces mises à jour rendent les pipelines modernes et cohérents avec l’orientation d’Azure DevOps. En outre, ces mises à jour regroupent des pipelines de build classiques et des pipelines YAML à plusieurs étapes dans une expérience unique. Par exemple, les fonctionnalités suivantes sont incluses dans la nouvelle expérience ; affichage et gestion de plusieurs étapes, approbation des exécutions de pipeline, possibilité de faire défiler tout le chemin dans les journaux pendant qu’un pipeline est encore en cours et intégrité par branche d’un pipeline.

Merci à tous ceux qui ont essayé la nouvelle expérience. Si vous ne l’avez pas essayé, activez les pipelines à plusieurs étapes dans les fonctionnalités de préversion. Pour en savoir plus sur les pipelines à plusieurs étapes, consultez la documentation ici .

Expérience utilisateur des pipelines à plusieurs étapes.

Grâce à vos commentaires, nous avons abordé les points suivants dans les deux dernières mises à jour.

  1. Détectabilité de l’affichage des dossiers.
  2. Jumpiness in logs view.
  3. Affichez facilement les journaux des tâches précédentes et actuelles, même lorsqu’une exécution est en cours.
  4. Facilitez la navigation entre les tâches lors de la révision des journaux.

Fonctionnalités incluses dans la nouvelle expérience.

Notes

Dans la prochaine mise à jour, nous prévoyons d’activer cette fonctionnalité par défaut pour tout le monde. Vous aurez toujours la possibilité de refuser la préversion. Quelques semaines après cela, la fonctionnalité sera mise en disponibilité générale.

Orchestrer la stratégie de déploiement canary sur l’environnement pour Kubernetes

L’un des principaux avantages de la livraison continue des mises à jour des applications est la possibilité de pousser rapidement les mises à jour en production pour des microservices spécifiques. Cela vous permet de répondre rapidement aux changements de besoins métier. L’environnement a été introduit comme un concept de première classe permettant l’orchestration des stratégies de déploiement et facilitant les mises en production sans temps d’arrêt. Auparavant, nous prenions en charge la stratégie runOnce qui exécutait les étapes une fois séquentiellement. Grâce à la prise en charge de la stratégie canary dans les pipelines à plusieurs étapes, vous pouvez désormais réduire le risque en déployant lentement la modification dans un petit sous-ensemble. À mesure que vous gagnez en confiance dans la nouvelle version, vous pouvez commencer à la déployer sur plus de serveurs de votre infrastructure et y acheminer davantage d’utilisateurs.

jobs:
- deployment:
  environment: musicCarnivalProd
  pool:
    name: musicCarnivalProdPool 
  strategy:                 
    canary:     
      increments: [10,20] 
      preDeploy:                                    
        steps:          
        - script: initialize, cleanup....  
      deploy:            
        steps:
        - script: echo deploy updates...
        - task: KubernetesManifest@0
          inputs:
            action: $(strategy.action)      
            namespace: 'default'
            strategy: $(strategy.name)
            percentage: $(strategy.increment)
            manifests: 'manifest.yml'
      postRouteTaffic:
        pool: server
        steps:          
        - script: echo monitor application health...  
      on:
        failure:
          steps:
	  - script: echo clean-up, rollback...  
        success:
          steps:
          - script: echo checks passed, notify...

La stratégie canary pour Kuberenetes va d’abord déployer les modifications avec 10 % de pods suivis de 20 % tout en surveillant l’intégrité pendant postRouteTraffic. Si tout se passe bien, il sera promu à 100%.

Nous recherchons des commentaires sur la prise en charge des ressources de machine virtuelle dans les environnements et l’exécution d’une stratégie de déploiement propagée sur plusieurs machines. Contactez-nous pour vous inscrire.

Stratégies d’approbation pour les pipelines YAML

Dans les pipelines YAML, nous suivons une configuration d’approbation contrôlée par le propriétaire des ressources. Les propriétaires de ressources configurent les approbations sur la ressource et tous les pipelines qui utilisent la pause de ressource pour les approbations avant le début de la phase de consommation de la ressource. Il est courant que les propriétaires d’applications basées sur SOX empêchent le demandeur du déploiement d’approuver leurs propres déploiements.

Vous pouvez maintenant utiliser des options d’approbation avancées pour configurer des stratégies d’approbation comme le demandeur ne doit pas approuver, exiger l’approbation d’un sous-ensemble d’utilisateurs et le délai d’approbation.

Stratégies d’approbation pour les pipelines YAML.

ACR en tant que ressource de pipeline de première classe

Si vous devez utiliser une image conteneur publiée sur ACR (Azure Container Registry) dans le cadre de votre pipeline et déclencher votre pipeline chaque fois qu’une nouvelle image est publiée, vous pouvez utiliser la ressource de conteneur ACR.

resources:
  containers:
  - container: MyACR  #container resource alias
    type: ACR
    azureSubscription: RMPM  #ARM service connection
    resourceGroup: contosoRG
    registry: contosodemo
    repository: alphaworkz
    trigger: 
      tags:
        include: 
        - production

En outre, les métadonnées d’image ACR sont accessibles à l’aide de variables prédéfinies. La liste suivante inclut les variables ACR disponibles pour définir une ressource de conteneur ACR dans votre pipeline.

resources.container.<Alias>.type
resources.container.<Alias>.registry
resources.container.<Alias>.repository
resources.container.<Alias>.tag 
resources.container.<Alias>.digest
resources.container.<Alias>.URI
resources.container.<Alias>.location

Métadonnées de ressources de pipeline en tant que variables prédéfinies

Nous avons ajouté des variables prédéfinies pour les ressources de pipelines YAML dans le pipeline. Voici la liste des variables de ressources de pipeline disponibles.

resources.pipeline.<Alias>.projectName 
resources.pipeline.<Alias>.projectID 
resources.pipeline.<Alias>.pipelineName 
resources.pipeline.<Alias>.pipelineID 
resources.pipeline.<Alias>.runName 
resources.pipeline.<Alias>.runID
resources.pipeline.<Alias>.runURI
resources.pipeline.<Alias>.sourceBranch 
resources.pipeline.<Alias>.sourceCommit
resources.pipeline.<Alias>.sourceProvider 
resources.pipeline.<Alias>.requestedFor
resources.pipeline.<Alias>.requestedForID

Traçabilité des pipelines et des ressources ACR

Nous garantissons une traçabilité E2E complète lorsque des pipelines et des ressources de conteneur ACR sont utilisés dans un pipeline. Pour chaque ressource consommée par votre pipeline YAML, vous pouvez effectuer un suivi vers les commits, les éléments de travail et les artefacts.

Dans la vue récapitulative de l’exécution du pipeline, vous pouvez voir :

  • Version de ressource qui a déclenché l’exécution. À présent, votre pipeline peut être déclenché à la fin d’une autre exécution de pipeline Azure ou lorsqu’une image conteneur est envoyée à ACR.

    Version de ressource qui a déclenché l’exécution.

  • Commits consommés par le pipeline. Vous pouvez également trouver la répartition des commits par chaque ressource consommée par le pipeline.

    Commits qui sont consommés par le pipeline.

  • Éléments de travail associés à chaque ressource consommée par le pipeline.

  • Artefacts disponibles pour être utilisés par l’exécution.

    Artefacts disponibles pour être utilisés par l’exécution.

Dans la vue déploiements de l’environnement, vous pouvez voir les commits et les éléments de travail pour chaque ressource déployée dans l’environnement.

Valide et les éléments de travail pour chaque ressource déployée dans l’environnement.

Autorisation simplifiée des ressources dans les pipelines YAML

Une ressource est tout ce qui est utilisé par un pipeline qui se trouve en dehors du pipeline. Les ressources doivent être autorisées avant de pouvoir être utilisées. Auparavant, lors de l’utilisation de ressources non autorisées dans un pipeline YAML, elle a échoué avec une erreur d’autorisation de ressource. Vous deviez autoriser les ressources à partir de la page de résumé de l’exécution ayant échoué. En outre, le pipeline a échoué s’il utilisait une variable qui faisait référence à une ressource non autorisée.

Nous allons maintenant faciliter la gestion des autorisations de ressources. Au lieu d’échouer l’exécution, l’exécution attend des autorisations sur les ressources au début de l’étape de consommation de la ressource. Un propriétaire de ressource peut afficher le pipeline et autoriser la ressource à partir de la page Sécurité.

Autorisation simplifiée des ressources dans les pipelines YAML.

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

Chaque travail qui s’exécute dans Azure Pipelines obtient un jeton d’accès. Le jeton d’accès est utilisé par les tâches et par vos scripts pour rappeler Azure DevOps. Par exemple, nous utilisons le jeton d’accès pour obtenir du code source, charger des journaux, des résultats de test, des artefacts 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 avons ajouté les améliorations suivantes.

  • Empêcher le jeton d’accéder aux ressources en dehors d’un projet d’équipe

    Jusqu’à présent, l’étendue par défaut de tous les pipelines était la collection de projets d’équipe. Vous pouvez modifier l’étendue pour qu’elle soit le projet d’équipe dans les pipelines de build classiques. Toutefois, vous ne disposiez pas de ce contrôle pour les pipelines de version classique ou YAML. Avec cette mise à jour, nous introduisons un paramètre de organization pour forcer chaque travail à obtenir un jeton d’étendue de projet, quel que soit ce qui est configuré dans le pipeline. Nous avons également ajouté le paramètre au niveau du projet. À présent, ce paramètre est automatiquement activé pour chaque nouveau projet et organization que vous créez.

    Notes

    Le paramètre organization remplace le paramètre de projet.

    L’activation de ce paramètre dans des projets et organisations existants peut entraîner l’échec de certains pipelines si vos pipelines accèdent à des ressources extérieures au projet d’équipe à l’aide de jetons d’accès. Pour atténuer les défaillances de pipeline, vous pouvez accorder explicitement à Project Build Service Account l’accès à la ressource souhaitée. Nous vous recommandons vivement d’activer ces paramètres de sécurité.

  • Supprimer certaines autorisations pour le jeton d’accès

    Par défaut, nous accordons un certain nombre d’autorisations au jeton d’accès, l’une de ces autorisations étant les builds de file d’attente. Avec cette mise à jour, nous avons supprimé cette autorisation sur le jeton d’accès. Si vos pipelines ont besoin de cette autorisation, vous pouvez l’accorder explicitement au compte de service Project Build ou au comptede service de build de la collection de projets en fonction du jeton que vous utilisez.

Évaluer les case activée des artefacts

Vous pouvez maintenant définir un ensemble de stratégies et ajouter l’évaluation de stratégie en tant que case activée sur un environnement pour les artefacts d’images conteneur. Lorsqu’un pipeline s’exécute, l’exécution s’interrompt avant de démarrer une étape qui utilise l’environnement. La stratégie spécifiée est évaluée par rapport aux métadonnées disponibles pour l’image en cours de déploiement. Le case activée passe lorsque la stratégie réussit et marque l’étape comme ayant échoué si le case activée échoue.

Évaluez le case activée de l’artefact.

Prise en charge de Markdown dans les messages d’erreur de test automatisés

Nous prenons désormais en charge Markdown dans les messages d’erreur pour les tests automatisés. Vous pouvez facilement mettre en forme des messages d’erreur pour la série de tests et les résultats du test afin d’améliorer la lisibilité et de faciliter la résolution des problèmes d’échec dans Azure Pipelines. La syntaxe Markdown prise en charge est disponible ici.

Prise en charge de Markdown dans les messages d’erreur de test automatisés.

Diagnostic des planifications cron dans YAML

Nous avons constaté une augmentation constante de l’utilisation de la syntaxe cron pour spécifier des planifications dans vos pipelines YAML. Lorsque nous avons écouté vos commentaires, nous avons appris qu’il était difficile pour vous de déterminer si Azure Pipelines avait traité votre syntaxe correctement. Auparavant, vous devrez attendre l’heure réelle de l’exécution planifiée pour déboguer les problèmes de planification. Pour vous aider à diagnostiquer les erreurs de branche/syntaxe, nous avons ajouté un nouveau menu d’action pour le pipeline. Les exécutions planifiées dans le menu Exécuter le pipeline vous donnent un aperçu des quelques exécutions planifiées à venir pour votre pipeline afin de vous aider à diagnostiquer les erreurs avec vos planifications cron.

Diagnostic des planifications cron dans YAML.

Mises à jour à la tâche de déploiement de modèle ARM

Auparavant, nous n’avons pas filtré les connexions de service dans la tâche de déploiement de modèle ARM. Cela peut entraîner l’échec du déploiement si vous sélectionnez une connexion de service de portée inférieure pour effectuer des déploiements de modèles ARM dans une étendue plus large. À présent, nous avons ajouté le filtrage des connexions de service pour filtrer les connexions de service à portée inférieure en fonction de l’étendue de déploiement que vous choisissez.

Sécurité au niveau du projet pour les connexions de service

Avec cette mise à jour, nous avons ajouté la sécurité au niveau du hub pour les connexions de service. Vous pouvez désormais ajouter/supprimer des utilisateurs, attribuer des rôles et gérer l’accès dans un emplacement centralisé pour toutes les connexions de service.

Sécurité au niveau du projet pour les connexions de service.

Pool Ubuntu 18.04

Azure Pipelines prend désormais en charge l’exécution de vos travaux sur Ubuntu 18.04. Nous avons mis à jour le pool Azure Pipelines hébergé par Microsoft pour inclure l’image Ubuntu-18.04. Maintenant, lorsque vous référencez ubuntu-latest un pool dans vos pipelines YAML, cela signifie ubuntu-18.04 et non ubuntu-16.04. Vous pouvez toujours cibler des images 16.04 dans vos travaux en utilisant ubuntu-16.04 explicitement.

Tâches canary basées sur l’interface Service Mesh dans KubernetesManifest

Auparavant, lorsque la stratégie canary était spécifiée dans la tâche KubernetesManifest, la tâche créait des charges de travail de base et canary dont les réplicas égalaient à un pourcentage des réplicas utilisés pour les charges de travail stables. Cela n’était pas exactement la même chose que le fractionnement du trafic jusqu’au pourcentage souhaité au niveau de la demande. Pour ce faire, nous avons ajouté la prise en charge des déploiements canary basés sur l’interface Service Mesh à la tâche KubernetesManifest.

L’abstraction de l’interface Service Mesh permet une configuration plug-and-play avec des fournisseurs de maillage de services tels que Linkerd et Istio. À présent, la tâche KubernetesManifest enlève le travail difficile de mappage des objets TrafficSplit de SMI aux services stables, de référence et de canaris pendant le cycle de vie de la stratégie de déploiement. Le pourcentage souhaité de fractionnement du trafic entre stable, ligne de base et canary est plus précis, car le pourcentage de fractionnement du trafic est contrôlé sur les requêtes dans le plan de maillage de service.

Voici un exemple d’exécution de déploiements canary basés sur SMI.

- deployment: Deployment
    displayName: Deployment
    pool:
      vmImage: $(vmImage)
    environment: ignite.smi
    strategy:
      canary:
        increments: [25, 50]
        preDeploy:
          steps:
          - task: KubernetesManifest@0
            displayName: Create/update secret
            inputs:
              action: createSecret
              namespace: smi
              secretName: $(secretName)
              dockerRegistryEndpoint: $(dockerRegistryServiceConnection)
        deploy:
          steps:
          - checkout: self
          - task: KubernetesManifest@0
            displayName: Deploy canary
            inputs:
              action: $(strategy.action)
              namespace: smi
              strategy: $(strategy.name)
              trafficSplitMethod: smi
              percentage: $(strategy.increment)
              baselineAndCanaryReplicas: 1
              manifests: |
                manifests/deployment.yml
                manifests/service.yml
              imagePullSecrets: $(secretName)
              containers: '$(containerRegistry)/$(imageRepository):$(Build.BuildId)'
        postRouteTraffic:
          pool: server
          steps:
            - task: Delay@1
              inputs:
                delayForMinutes: '2'

ReviewApp dans l’environnement

ReviewApp déploie chaque demande de tirage à partir de votre dépôt Git vers une ressource d’environnement dynamique. Les réviseurs peuvent voir à quoi ressemblent ces modifications et travailler avec d’autres services dépendants avant qu’elles ne soient fusionnées dans la branche main et déployées en production. Cela vous permettra de créer et de gérer facilement des ressources reviewApp et de tirer parti de toutes les fonctionnalités de traçabilité et de diagnostic des fonctionnalités de l’environnement. En utilisant le mot clé reviewApp, vous pouvez créer un clone d’une ressource (créer dynamiquement une ressource en fonction d’une ressource existante dans un environnement) et ajouter la nouvelle ressource à l’environnement.

Voici un exemple d’extrait de code YAML de l’utilisation de reviewApp sous environnements.

jobs:
- deployment:
  environment: 
     name: smarthotel-dev      
     resourceName: $(System.PullRequest.PullRequestId) 
  pool:
    name: 'ubuntu-latest'
  strategy:                 
    runOnce:            
      pre-deploy: 
        steps:       
        - reviewApp: MasterNamespace

Azure Artifacts

Mise à jour de l’expérience se connecter au flux

La boîte de dialogue Se connecter au flux est la voie d’accès à l’utilisation d’Azure Artifacts ; il contient des informations sur la configuration des clients et des dépôts pour envoyer et extraire des packages à partir de flux dans Azure DevOps. Nous avons mis à jour la boîte de dialogue pour ajouter des informations détaillées sur la configuration et développé les outils que nous donnons des instructions.

Les flux publics sont désormais en disponibilité générale avec amont prise en charge

La préversion publique des flux publics a reçu beaucoup d’adoption et de commentaires. Dans cette mise à jour, nous avons étendu des fonctionnalités supplémentaires à la disponibilité générale. Vous pouvez maintenant définir un flux public en tant que source amont à partir d’un flux privé. Vous pouvez simplifier vos fichiers de configuration en étant en mesure de amont à la fois vers et depuis des flux privés et étendus au projet.

Créer des flux d’étendue de projet à partir du portail

Lorsque nous avons publié des flux publics, nous avons également publié des flux dans l’étendue du projet. Jusqu’à présent, les flux délimités par le projet pouvaient être créés via des API REST ou en créant un flux public, puis en activant le projet privé. À présent, vous pouvez créer des flux d’étendue de projet directement dans le portail à partir de n’importe quel projet si vous disposez des autorisations nécessaires. Vous pouvez également voir quels flux sont des projets et lesquels sont organization dans le sélecteur de flux.

Rapports

Un widget Sprint Burndown avec tout ce que vous avez demandé

Le nouveau widget Sprint Burndown prend en charge la gravure par points d’histoire, le nombre de tâches ou la somme de champs personnalisés. Vous pouvez même créer un burndown sprint pour les fonctionnalités ou les epics. Le widget affiche le burndown moyen, le % terminé et l’augmentation de l’étendue. Vous pouvez configurer l’équipe, ce qui vous permet d’afficher les burndowns de sprint pour plusieurs équipes sur le même tableau de bord. Avec toutes ces excellentes informations à afficher, nous vous permet de les redimensionner jusqu’à 10 x 10 sur le tableau de bord.

Widget Sprint Burndown.

Pour l’essayer, vous pouvez l’ajouter à partir du catalogue de widgets, ou en modifiant la configuration du widget Sprint Burndown existant et en cochant la case Essayer la nouvelle version maintenant .

Notes

Le nouveau widget utilise Analytics. Nous avons conservé l’ancien Sprint Burndown au cas où vous n’aviez pas accès à Analytics.

Wiki

Défilement synchrone pour la modification des pages wiki

La modification des pages wiki est désormais plus facile grâce au défilement synchrone entre le volet de modification et d’aperçu. Le défilement d’un côté fait défiler automatiquement l’autre côté pour mapper les sections correspondantes. Vous pouvez désactiver le défilement synchrone avec le bouton bascule.

Défilement synchrone pour la modification des pages wiki.

Notes

L’état du bouton bascule de défilement synchrone est enregistré par utilisateur et organization.

Visites de pages pour les pages wiki

Vous pouvez maintenant obtenir des insights sur les visites de pages wiki. L’API REST vous permet d’accéder aux informations des visites de page au cours des 30 derniers jours. Vous pouvez utiliser ces données pour créer des rapports pour vos pages wiki. En outre, vous pouvez stocker ces données dans votre source de données et créer des tableaux de bord pour obtenir des insights spécifiques tels que les pages les plus consultées.

Vous verrez également un nombre agrégé de visites de pages pour les 30 derniers jours dans chaque page.

Visites de pages pour les pages wiki.

Notes

Une visite de page est définie comme une vue de page par un utilisateur donné dans un intervalle de 15 minutes.

Étapes suivantes

Notes

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

Accédez à Azure DevOps et jetez un coup d’œil.

Accédez à Azure DevOps

Comment fournir des commentaires

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

Faire une suggestion

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

Merci,

Jeff Beehler