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 pour tous les clients dans le cadre de la mise à jour sprint 172.

Consultez la liste des fonctionnalités ci-dessous pour plus d’informations.

Fonctionnalités

Azure Boards

• Règles de restriction de transition d’état
• Copier un é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 exclusive
• Filtres de phases pour les déclencheurs de ressources de pipeline
• Déclencheurs webhook génériques pour les pipelines YAML
• Prise en charge et traçabilité des problèmes de déclencheur de ressource YAML
• Bannière pour les incidents de site en direct impactant les pipelines

Azure Artifacts

• Possibilité de créer des flux étendus à 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 en disponibilité générale pour tous les clients. Cette nouvelle règle de type d’élément de travail vous permet d’empêcher le déplacement d’éléments de travail d’un état à un autre. Par exemple, vous pouvez empêcher les bogues d’aller de Nouveau à Résolu. Au lieu de cela, ils doivent passer 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 les récits utilisateur à partir de Nouveau -> Approuvé.

Copier un é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 « Inclure des éléments de travail enfants » à la boîte de dialogue copier un élément de travail. Lorsqu’elle 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. Ils sont définis 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 destinées à 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 ayez un état personnalisé de « Tests des besoins » dans la catégorie Résolu. Lorsque l’élément de travail passe de « Actif » à « Tests de besoins », les règles Résolu par et Date résolue 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 Activated By, Activated Date, Resolved By et Date résolue , sans avoir besoin d’utiliser des 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 :

Processus	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 à n’importe quel niveau de backlog.

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

Azure Pipelines

Stratégie de verrouillage de déploiement exclusive

Avec cette mise à jour, vous pouvez vous assurer qu’une seule exécution est déployée dans un environnement à la fois. En choisissant le « verrou exclusif » case activée sur un environnement, une seule exécution se poursuit. Les exécutions suivantes qui souhaitent effectuer un déploiement dans cet environnement seront suspendues. Une fois l’exécution avec le verrou exclusif terminé, la dernière exécution se poursuit. Toutes les exécutions intermédiaires seront annulées.

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

Dans ce sprint, nous avons ajouté la prise en charge des « étapes » en tant que 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 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 build et des packages) grâce auxquelles vous pouvez consommer des artefacts et activer des déclencheurs automatisés. Toutefois, jusqu’à présent, vous ne pouviez pas 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 de webhook dans les pipelines YAML pour permettre l’intégration de l’automatisation de pipeline à n’importe quel service externe. Vous pouvez vous abonner à n’importe quel événement externe via ses webhooks (GitHub, GitHub Enterprise, Nexus, Aritfactory, etc.) et déclencher vos pipelines.

Voici les étapes pour configurer les déclencheurs de 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/<Organisation> ADO/_apis/public/distributedtask/webhooks/<Nom >webHook?api-version=6.0-preview »
   • Secret : cette option est facultative. Si vous devez sécuriser votre charge utile JSON, indiquez 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 la charge utile pour la vérification de la demande. Par exemple, dans le cas de GitHub, l’en-tête de requête sera « 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 (cette opération est facultative). 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 de webhook, vous devez définir une ressource webhook dans votre pipeline et la pointer vers la connexion de service webhook entrante. 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 de 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

Cela peut prêter à confusion lorsque les déclencheurs de pipeline ne s’exécutent pas comme prévu. Pour vous aider à mieux comprendre cela, nous avons ajouté un nouvel élément de menu dans la page de définition du pipeline appelé « Problèmes de déclencheur », où des informations sont exposées sur la raison pour laquelle les déclencheurs ne s’exécutent pas.

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 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 ne s’exécute pas. Chaque fois que cela se produit, un avertissement est mis en évidence afin que vous puissiez 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, qui peuvent avoir un impact sur vos pipelines.

Azure Artifacts

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

Nous rétablissons la possibilité pour les clients de créer et de gérer des flux organization par le biais de 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 Étendue.

Bien que nous vous recommandons d’utiliser des flux d’étendue de projet en alignement avec le reste des offres Azure DevOps, vous pouvez à nouveau créer, gérer et utiliser des flux organization par le biais de l’interface utilisateur et de 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 d’aide pour signaler un problème ou fournir une suggestion.

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

Merci,

Aaron Hallberg