Restreindre les transitions d’état d’élément de travail

Après plusieurs sprints en préversion, nous annonçons maintenant la publication générale des règles de restriction de transition d’état à tous les clients dans le cadre de la mise à jour Sprint 172.

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

Fonctionnalités

Azure Boards

• Règles de restriction de transition d’état
• Copier l’élément de travail pour copier des enfants
• Règles améliorées pour les champs activés et résolus
• Types d’éléments de travail système sur les backlogs et les tableaux (préversion privée)

Azure Pipelines

• Stratégie de verrouillage de déploiement exclusif
• Filtres d’étapes pour les déclencheurs de ressources de pipeline
• Déclencheurs webhook génériques pour les pipelines YAML
• Problèmes liés au déclencheur de ressources YAML et à la traçabilité
• Bannière pour les incidents de site en direct impactant les pipelines

Azure Artifacts

• Possibilité de créer des flux au niveau de l’organisation à partir de l’interface utilisateur

Azure Boards

Règles de restriction de transition d’état

Après plusieurs sprints de préversion privée, les règles de restriction de transition d’état sont désormais généralement disponibles pour tous les clients. Cette nouvelle règle de type d’élément de travail vous permet de limiter le déplacement d’éléments de travail d’un état à un autre. Par exemple, vous pouvez restreindre les bogues d’aller de Nouveau à Résolu. Au lieu de cela, ils doivent aller de Nouveau -> Actif -> Résolu

Vous pouvez également créer une règle pour restreindre les transitions d’état par appartenance au groupe. Par exemple, seuls les utilisateurs du groupe « Approbateurs » peuvent déplacer des récits utilisateur à partir de Nouveau -> Approuvé.

Copier l’élément de travail pour copier des 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. Dans ce sprint, nous avons ajouté une nouvelle option pour « Inclure des éléments de travail enfants » dans la boîte de dialogue Copier l’élément de travail. Lorsque 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).

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

Jusqu’à présent, les règles pour Activated By, Activated Date, Resolved By et Resolved Date ont été un mystère. Elles sont définies uniquement pour les types d’éléments de travail système et sont spécifiques à la valeur d’état « Active » et « Résolu ». Dans sprint 172, 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 réside l’état. Par exemple, supposons que vous disposez d’un état personnalisé de « Tests des besoins » dans la catégorie résolue. Lorsque l’élément de travail passe de « Actif » à « Tests des besoins », les règles De date résolues et By sont déclenchées.

Cela permet aux clients de créer des valeurs d’état personnalisées et de générer toujours les champs Activé par, Date activée, Résolu par et Date résolue, sans avoir à utiliser de règles personnalisées.

Types d’éléments de travail système sur les backlogs et les tableaux (préversion privée)

Depuis la création du modèle de processus d’héritage, plusieurs types d’éléments de travail ont été exclus de l’ajout aux tableaux et aux backlogs. Ces types d’éléments de travail sont les suivants :

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

À partir de ce sprint, nous permettons une préversion privée pour les clients qui souhaitent permettre à ces types d’éléments de travail d’être disponibles au niveau du backlog.

Si vous souhaitez afficher un aperçu de cette fonctionnalité, veuillez nous envoyer un e-mail avec le nom de votre organisation et nous pouvons vous donner accès.

Azure Pipelines

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 sur un environnement à la fois. En choisissant la vérification « Verrouillage exclusif » sur un environnement, une seule exécution se poursuit. Les exécutions suivantes qui souhaitent être déployées sur cet environnement seront suspendues. Une fois l’exécution terminée avec le verrou exclusif, la dernière exécution se poursuit. Toutes les exécutions intermédiaires seront annulées.

Filtres d’étapes pour les déclencheurs de ressources de pipeline

Dans ce sprint, nous avons ajouté la prise en charge des « étapes » comme filtre pour les ressources de pipeline dans YAML. Avec ce filtre, vous n’avez pas besoin d’attendre que l’ensemble du pipeline CI soit terminé pour déclencher votre pipeline CD. Vous pouvez maintenant choisir de déclencher votre pipeline CD à la fin d’une étape spécifique de votre pipeline CI.

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 correctement terminées dans votre pipeline CI, une nouvelle exécution est automatiquement déclenchée pour votre pipeline CD.

Déclencheurs webhook génériques pour les pipelines YAML

Aujourd’hui, nous disposons de différentes ressources (telles que des pipelines, des conteneurs, des builds et des packages) via lesquelles 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 événements ou services externes. Dans cette version, nous introduisons 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 à tous les événements externes via ses webhooks (GitHub, GitHub Enterprise, Nexus, Artifactory, etc.) et déclencher vos pipelines.

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

1. Configurez un webhook sur votre service externe. Lorsque vous créez votre webhook, vous devez fournir les informations suivantes :

   • URL de la demande - «https://dev.azure.com/< Organisation> ADO/_apis/public/distributedtask/webhooks/<Nom> webHook ?api-version=6.0-preview »
   • Secret : cela est facultatif. Si vous devez sécuriser votre charge utile JSON, fournissez la valeur secret

2. Créez une connexion de service « Webhook entrant ». Il s’agit d’un nouveau type de connexion de service 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 requête qui contient la valeur de hachage de charge utile pour la vérification de la demande. Par exemple, dans le cas de GitHub, l’en-tête de requête est « X-Hub-Signature »
   • Secret : le secret est utilisé pour analyser le hachage de charge utile utilisé pour la vérification de la requête entrante (facultatif). Si vous avez utilisé un secret pour créer votre webhook, vous devez fournir la même clé secrète

   

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 webhook dans votre pipeline et la 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 consommer 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}}

4. 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 abonnés à l’événement webhook.

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

Il peut être déroutant lorsque les déclencheurs de pipeline ne parviennent pas à s’exécuter comme prévu. Pour mieux comprendre cela, nous avons ajouté un nouvel élément de menu dans la page de définition de pipeline appelée « Problèmes de déclencheur » où les informations sont exposées concernant la raison pour laquelle les déclencheurs ne s’exécutent pas.

Les déclencheurs de ressources peuvent ne pas s’exécuter 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 n’est pas configuré du tout. Celles-ci sont exposées sous forme d’erreurs.

2. Si les conditions du déclencheur ne sont pas mises en correspondance, le déclencheur n’est pas exécuté. Chaque fois que cela se produit, un avertissement est exposé afin de comprendre pourquoi les conditions n’ont pas été mises en correspondance.

   

Bannière pour les incidents de site en direct impactant les pipelines

Nous avons ajouté une bannière d’avertissement à la page pipelines pour alerter les utilisateurs des incidents en cours dans votre région, ce qui peut avoir un impact sur vos pipelines.

Azure Artifacts

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

Nous ramenons la possibilité pour les clients de créer et de gérer des flux étendus à l’organisation via l’interface utilisateur web pour les services locaux et hébergés.

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

Bien que nous vous recommandons d’utiliser 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 organisation via l’interface utilisateur et diverses API REST. Pour plus d’informations, consultez notre documentation sur les flux.

É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,

Aaron Hallberg