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 de burndown de sprint qui prend en charge le burndown par story points, le nombre de tâches et la totalisation 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 :

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

Azure Pipelines :

• Expérience utilisateur des pipelines multi-étapes
• 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. Désormais, les administrateurs peuvent définir des stratégies sur une branche spécifique ou sur la branche par défaut, sur tous les référentiels de leur projet. Par exemple, un administrateur peut exiger un minimum de deux réviseurs pour toutes les pull requests effectuées dans chaque branche principale de chaque dépôt dans son projet. Vous trouverez la fonctionnalité Ajouter une protection de branche dans les paramètres du projet Repos.

Azure Pipelines

Expérience utilisateur des pipelines multi-é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 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 interface : la visualisation et la gestion de plusieurs étapes, l'approbation des parcours de pipelines, la possibilité de faire défiler les journaux jusqu'en arrière lorsqu'un pipeline est toujours en cours, et l'état de santé d'un pipeline par branche.

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écouvrabilité de la vue des dossiers.
2. Affichage en dents de scie dans la vue 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.

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éploiera d'abord les changements avec 10 % de pods suivis de 20 % tout en surveillant la santé pendant postRouteTraffic. Si tout se passe bien, elle passera à 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 ressource font une pause pour les approbations avant le début de l'étape consommant la ressource. Il est courant que les propriétaires d'applications basées sur la loi SOX empêchent 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 pipeline 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 utilisée par votre pipeline YAML, vous pouvez retracer les validations, les éléments de travail et les artefacts.

Dans la vue récapitulative de l'exécution du pipeline, vous trouverez les éléments suivants :

• 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 de conteneur est publiée sur Azure Container Registry.

  

• Les commits consommés par le pipeline. Vous y trouverez également la répartition des commits par ressource consommée par le pipeline.

  

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

• Les artefacts disponibles à l'utilisation durant l'exécution.

  

Dans la vue des 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.

Autorisation de ressources simplifiée dans les pipelines YAML

Une ressource est tout élément utilisé par un pipeline provenant de l'extérieur 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 avez dû autoriser les ressources à partir de la page récapitulative de l'exécution qui a échoué. En outre, le pipeline échouerait 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 attendra les autorisations sur les ressources au début de l'étape qui consomme 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 interagir avec Azure DevOps. Par exemple, nous utilisons le jeton d'accès pour obtenir le code source, charger les journaux d'activité, les résultats des tests, les artefacts ou pour 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 de l'équipe. Vous pouvez modifier l'étendue pour qu'elle corresponde au projet de l'équipe dans les pipelines de build classiques. Cependant, vous ne disposiez pas de ce contrôle pour les pipelines de release classique ou YAML. Avec cette mise à jour, nous introduisons un paramètre d'organisation pour forcer chaque travail à obtenir un jeton de projet, peu importe la configuration du 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 l'accès du Project Build Service Account explicitement à 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 de permissions au jeton d'accès, l'une de ces permissions étant Builds en 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 la collection de projets, selon le jeton que vous utilisez.

Évaluation de contrôle d’artefact

Vous pouvez désormais définir un ensemble de stratégies et ajouter l'évaluation de la stratégie en tant que contrôle d'un environnement pour les artefacts d'image conteneur. Lors de l'exécution d'un pipeline, l'exécution s'interrompt avant de débuter 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 déployée. Le contrôle réussit lorsque la politique est appliquée avec succès et marque l’étape comme échouée si le contrôle échoue.

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.

Diagnostic des horaires cron dans des fichiers 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 deviez attendre l'heure réelle de l'exécution programmée pour résoudre les problèmes de programmation. 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 les images 16.04 dans vos travaux en utilisant explicitement ubuntu-16.04.

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

Auparavant, lorsque la stratégie de contrôle de validité était spécifiée dans la tâche KubernetesManifest, la tâche créait des charges de travail de base et de contrôle de validité 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. Désormais, la tâche KubernetesManifest élimine la pénibilité du mappage des objets TrafficSplit de SMI pour les services stables, de référence et de contrôle de validité au cours du cycle de vie de la stratégie de déploiement. Le pourcentage souhaité de répartition du trafic entre les services stables, de référence et de contrôle de validité est plus précis car la répartition du trafic en pourcentage est contrôlée sur les requêtes dans le plan de maillage des services.

Ce qui suit est un exemple d'exécution de déploiements de contrôle de validité basés sur SMI de manière continue.

- 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 pull request de votre dépôt Git vers un 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: MainNamespace

Artifacts d'Azure

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 élargi la gamme d'outils pour lesquels nous fournissons des instructions.

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

La préversion publique des flux publics a été très bien accueillie et a fait l'objet de nombreux 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 ayant la possibilité de remonter des flux privés et des flux propres à un projet.

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

Lorsque nous avons mis en place des flux publics, nous avons également mis en place des flux 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. Le sélecteur de flux vous permet également de voir quels flux sont liés à un projet et quels flux sont liés à une organisation.

Rapports

Widget Sprint Burndown avec tout ce que vous avez demandé

Le nouveau widget Burndown du sprint permet de mesurer le burndown des Story Points, du nombre de tâches ou de la somme des champs personnalisés. Vous pouvez même créer un burndown de sprint pour les fonctionnalités ou les épopées. Le widget affiche le burndown moyen, le pourcentage d'achèvement et l'augmentation de la portée. 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 informations intéressantes prêtes à être affichées, nous vous permettons de les 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 .

Site collaboratif 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.

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.

Étapes suivantes

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

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