Nouveau widget sprint burndown et amélioration de la sécurité des pipelines - Mise à jour sprint 160

Dans la mise à jour Sprint 160 d’Azure DevOps, nous avons ajouté un nouveau widget sprint burndown qui prend en charge la combustion par points de récit, le nombre de tâches et la somme des 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 :

• Administration de stratégie de branche interdépôt

Azure Pipelines :

• Expérience utilisateur de pipelines multi-index
• Orchestration de stratégie de déploiement avec contrôle de validité pour Kubernetes
• Stratégies d’approbation pour pipelines YAML
• ACR en tant que ressource de pipeline de première classe
• Métadonnées de ressources de pipeline en tant que variables prédéfinies
• Traçabilité des pipelines et des ressources ACR
• Autorisation de ressources simplifiée dans les pipelines YAML
• Amélioration de la sécurité des pipelines en limitant l’étendue des jetons d’accès
• Évaluation de contrôle d’artefact
• Prise en charge de markdown dans les messages d’erreur de test automatisé
• Diagnostics de planifications cron dans YAML
• Mises à jour de la tâche de déploiement de modèle ARM
• sécurité au niveau du projet pour les connexions de service
• Pool Ubuntu 18.04
• Déploiements avec contrôle de validité basés sur SMI (Service Mesh Interface) dans la tâche KubernetesManifest
• ReviewApp dans environnement

Azure Artifacts :

• Expérience de connexion à un flux mise à jour
• Flux publics désormais généralement disponibles avec prise en charge en amont
• Création de flux ayant pour étendue un projet à partir du portail

Création de rapports :

• Widget Sprint Burndown avec tout ce que vous avez demandé

Wiki :

• Défilement synchrone pour l’édition des pages wiki
• Visites de page pour les pages wiki

Azure Repos

Administration de stratégie de branche interdépôt

Les stratégies de branche sont l’une des fonctionnalités puissantes d’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. À présent, les administrateurs peuvent définir des stratégies sur une branche spécifique ou le branche par défaut sur tous les référentiels de leur projet. Par exemple, un administrateur peut exiger deux réviseurs minimum pour toutes les demandes de tirage effectuées dans chaque branche principale dans chaque référentiel de leur projet. Vous trouverez la fonctionnalité Ajouter une protection de branche dans les paramètres du projet Repos.

Azure Pipelines

Expérience utilisateur de pipelines multi-index

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 la direction d’Azure DevOps. De plus, ces mises à jour rassemblent des pipelines de build classiques et des pipelines YAML à plusieurs étapes en une seule expérience. 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 tous les chemins dans les journaux pendant qu’un pipeline est toujours en cours et l’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 en préversion. Pour en savoir plus sur les pipelines à plusieurs étapes, consultez la documentation ici .

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

1. Détectabilité de l’affichage dossiers.
2. Jumpiness dans l’affichage des journaux.
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 l’examen des journaux.

Remarque

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

Orchestration de stratégie de déploiement avec contrôle de validité pour Kubernetes

L’un des principaux avantages de la livraison continue des mises à jour des applications est la possibilité d’envoyer rapidement des mises à jour en production pour des microservices spécifiques. Cela vous donne la possibilité de répondre rapidement aux changements apportés aux besoins de l’entreprise. L’environnement a été introduit en tant que 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 avons pris en charge la stratégie runOnce qui a exécuté 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 vers un petit sous-ensemble. À mesure que vous gagnez en confiance dans la nouvelle version, vous pouvez commencer à le déployer sur davantage de serveurs dans votre infrastructure et acheminer davantage d’utilisateurs vers celui-ci.

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'
      postRouteTraffic:
        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 Kubernetes déploie d’abord les modifications avec 10 % de pods suivis de 20 % lors de la surveillance de l’intégrité pendant postRouteTraffic. Si tout va bien, il va promouvoir à 100%.

Stratégies d’approbation pour 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 l’étape consommant la ressource. Il est courant pour les propriétaires d’applications basés sur SOX de restreindre le demandeur du déploiement d’approuver leurs propres déploiements.

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

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

Si vous devez utiliser une image conteneur publiée dans ACR (Azure Container Registry) dans le cadre de votre pipeline et déclencher votre pipeline chaque fois qu’une nouvelle image a été 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 

De plus, 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 ressource 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 assurons une traçabilité E2E complète lorsque les pipelines et les ressources de conteneur ACR sont utilisés dans un pipeline. Pour chaque ressource consommée par votre pipeline YAML, vous pouvez effectuer le suivi des validations, des éléments de travail et des 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.

  

• Validations consommées par le pipeline. Vous pouvez également trouver la répartition des validations par chaque ressource consommée 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.

  

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

Autorisation de ressources simplifiée 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 récapitulative de l’exécution ayant échoué. En outre, le pipeline a échoué s’il utilise une variable qui a référencé 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 les autorisations sur les ressources au début de l’étape consommant la ressource. Un propriétaire de ressource peut afficher le pipeline et autoriser la ressource à partir de la page Sécurité.

Amélioration de la sécurité des pipelines 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 dans 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 effectuer des appels REST dans Azure DevOps. Un nouveau jeton d’accès est généré pour chaque travail et 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 n’avez pas ce contrôle pour les pipelines YAML ou version classique. Avec cette mise à jour, nous introduisons un paramètre d’organisation pour forcer chaque travail à obtenir un jeton dans l’étendue du projet, quel que soit le paramètre configuré dans le pipeline. Nous avons également ajouté le paramètre au niveau du projet. À présent, chaque nouveau projet et organisation que vous créez aura automatiquement activé ce paramètre.

  Remarque

  Le paramètre d’organisation remplace le paramètre de projet.

  L’activation de ce paramètre dans les projets et organisations existants peut entraîner l’échec de certains pipelines si vos pipelines accèdent aux ressources qui se trouvent en dehors du projet d’équipe à l’aide de jetons d’accès. Pour atténuer les échecs de pipeline, vous pouvez accorder explicitement l’accès au compte de service de build project à 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 est les builds File d’attente. Avec cette mise à jour, nous avons supprimé cette autorisation pour le jeton d’accès. Si vos pipelines ont besoin de cette autorisation, vous pouvez l’accorder explicitement au compte de service de génération de projet ou au compte de service de génération de regroupement de projets en fonction du jeton que vous utilisez.

Évaluation de contrôle d’artefact

Vous pouvez maintenant définir un ensemble de stratégies et ajouter l’évaluation de la stratégie en tant que vérification d’un environnement pour les artefacts d’image conteneur. Lorsqu’un pipeline s’exécute, l’exécution s’interrompt avant de démarrer une phase qui utilise l’environnement. La stratégie spécifiée est évaluée par rapport aux métadonnées disponibles pour l’image déployée. La vérification réussit lorsque la stratégie réussit et marque l’étape comme ayant échoué en cas d’échec de la vérification.

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

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 l’exécution de test et le résultat de test afin d’améliorer la lisibilité et de faciliter la résolution des problèmes de l’échec dans Azure Pipelines. La syntaxe Markdown prise en charge est disponible ici.

Diagnostics de 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. Comme nous avons écouté vos commentaires, nous avons entendu dire 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 prochaines exécutions planifiées pour votre pipeline pour vous aider à diagnostiquer les erreurs avec vos planifications cron.

Mises à jour de 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 d’étendue 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 à étendue 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. À présent, vous pouvez ajouter/supprimer des utilisateurs, attribuer des rôles et gérer l’accès à un emplacement centralisé pour toutes 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 à l’aide ubuntu-16.04 explicitement.

Déploiements avec contrôle de validité basés sur SMI (Service Mesh Interface) dans la tâche KubernetesManifest

Auparavant, lorsque la stratégie canary était spécifiée dans la tâche KubernetesManifest, la tâche créerait des charges de travail de référence et de canari dont les réplicas étaient égaux à un pourcentage des réplicas utilisés pour les charges de travail stables. Ce n’était pas exactement le même que le fractionnement du trafic jusqu’au pourcentage souhaité au niveau de la requête. Pour résoudre ce problème, 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. Maintenant, la tâche KubernetesManifest enlève le travail dur du mappage des objets TrafficSplit de SMI aux services stables, de référence et de canari 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 fractionnement du trafic de pourcentage est contrôlé sur les requêtes dans le plan de maillage de service.

Voici un exemple d’exécution des déploiements canary basés sur SMI de manière propagée.

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

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

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

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

Azure Artifacts

Expérience de connexion à un flux mise à jour

La boîte de dialogue Se connecter au flux est l’entrée à l’aide d’Azure Artifacts ; il contient des informations sur la configuration des clients et des référentiels 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 pour utilisant des instructions.

Flux publics désormais généralement disponibles avec prise en charge en amont

La préversion publique des flux publics a reçu une grande adoption et des commentaires. Dans cette mise à jour, nous avons étendu des fonctionnalités supplémentaires à la disponibilité générale. À présent, vous pouvez définir un flux public en tant que source en amont à partir d’un flux privé. Vous pouvez simplifier vos fichiers de configuration en étant en mesure d’effectuer des opérations en amont à la fois vers et à partir de flux privés et dans l’étendue du projet.

Création de flux ayant pour étendue un projet à partir du portail

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

Reporting

Widget Sprint Burndown avec tout ce que vous avez demandé

Le nouveau widget Sprint Burndown prend en charge la combustion par points d’histoire, le nombre de tâches ou en additionnant des champs personnalisés. Vous pouvez même créer un burndown sprint pour fonctionnalités ou épopées. Le widget affiche l’augmentation moyenne de l’avancement, du pourcentage complet et de l’étendue. Vous pouvez configurer l’équipe, ce qui vous permet d’afficher des burndowns sprint pour plusieurs équipes sur le même tableau de bord. Avec toutes ces informations intéressantes à afficher, nous vous permet de le redimensionner jusqu’à 10 x 10 sur le tableau de bord.

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 .

Remarque

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

Wiki

Défilement synchrone pour l’édition des pages wiki

La modification des pages wiki est désormais plus facile avec le défilement synchrone entre la modification et le volet 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.

Remarque

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

Visites de pages pour les pages wiki

Vous pouvez maintenant obtenir des informations sur les visites de pages pour les pages wiki. L’API REST vous permet d’accéder aux informations de visite 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 comme les pages les plus consultées.

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

Remarque

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éder à 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.

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

Merci,

Jeff Beehler