Création d’une demande de changement avec erreurs de récupération de données DevOps

Créez des demandes de changement même avec des erreurs lors de la récupération de données DevOps.

Vue d’ensemble de la création d’une demande de changement

Remarque :

La création d’une demande de changement avec erreurs de récupération de données DevOps n’est prise en charge que pour Azure DevOps, GitHub ActionsGitLab, et Jenkins les pipelines.

Vous pouvez créer une demande de changement avec ou sans erreurs lors de la récupération de données DevOps. Cette fonctionnalité peut être contrôlée par la propriété Activer la création de demandes de changement, même avec des erreurs dans la propriété de récupération de données DevOps . Lorsque la propriété Activer la création de demandes de changement, même avec des erreurs dans la récupération de données DevOps , est activée et qu’une erreur se produit lors de la récupération de données DevOps telles que des éléments de travail, des validations, des résumés de tests ou des résumés de sécurité, la demande de changement correspondante est toujours créée. Les données pouvant être récupérées seront toujours associées à la demande de changement. Pour les données qui ne peuvent pas être récupérées, le motif de l’erreur est notifié à l’utilisateur dans la console tierce, et les mêmes informations sont également ajoutées dans le champ Commentaires sur le changement de l’enregistrement d’exécution de l’étape et dans les notes de travail sur le changement.

Si la propriété Activer la création de demandes de changement même avec des erreurs dans la récupération de données DevOps n’est pas activée, une demande de changement est créée uniquement lorsqu’il n’y a aucune erreur dans une étape d’une exécution de pipeline. Lorsqu’une erreur se produit, le pipeline est abandonné et le motif de l’erreur est ajouté dans le champ Détails de traitement de l’événement entrant, et la même chose est notifiée à l’utilisateur dans la console tierce.

Pour plus d'informations, consultez Propriétés du Vélocité de changement DevOps.

Approbation des demandes de changement avec des erreurs de récupération de données DevOps

Pour les demandes de changement créées avec des erreurs de récupération de données DevOps, l’entrée de is_change_with_partial_data politique est définie sur Vrai pour toutes les politiques d’approbation de changement. Seule une décision d’approbation de changement manuelle est appliquée à ces changements afin que vous puissiez approuver ou rejeter le changement après avoir vérifié manuellement les données DevOps qu’il contient. Dans le flux secondaire Collecter les données de politique de changement DevOps, l’action Is change with partial data détermine si un changement est créé avec des erreurs de récupération de données DevOps ou non.

Interface utilisateur du pipeline pour les demandes de changement avec des erreurs de récupération de données DevOps

Lorsqu’une demande de changement est créée avec des erreurs de récupération de données DevOps, la carte spécifiant l’étape où l’erreur s’est produite s’affiche dans la couleur jaune.

Remarque :

Si votre pipeline de version (CI) est configuré pour déclencher un pipeline de mise en production (CD) et qu’un changement est créé dans le pipeline de mise en production, les données sont collectées à partir du pipeline de version et associées à la demande de changement. Il peut arriver que la vélocité de changement ServiceNow DevOps reçoive et traite les événements de pipeline de mise en production avant les événements de pipeline de version. Dans ce cas, le changement est créé avec les données DevOps du pipeline de version, même si une erreur s’est produite lors de la récupération de certaines données. Vous pouvez observer ce comportement même si l’option Activer la création de demandes de changement, même avec des erreurs dans la propriété de récupération de données DevOps est activée. En outre, l’entrée de is_change_with_partial_data politique sera fausse dans ce cas et le processus d’approbation sera appliqué de la manière dont il est défini dans les flux d’approbation, contrairement à toujours manuel en cas de demandes de changement avec des erreurs de récupération de données DevOps.

Délai d’expiration du rappel

Si un événement entrant passe à l’état En attente pendant l’exécution d’un pipeline, le système tente de traiter le changement jusqu’à ce que la valeur de délai d’expiration de la sn_devops.change _request_callback_timeout propriété soit dépassée, après quoi le pipeline est abandonné. Le motif de l’erreur s’affiche dans les journaux de la console de votre outil tiers. Lorsqu’un pipeline est annulé en raison du délai d’expiration de rappel, les mêmes informations sont ajoutées dans l’enregistrement de rappel de l’exécution de l’étape correspondante. Vous pouvez contacter votre administrateur DevOps pour augmenter la valeur du délai d’expiration dans la sn_devops.change_request_callback_timeout propriété. La valeur par défaut de cette propriété est de 120 minutes et la valeur minimale est de 60 minutes. Pour plus d'informations, consultez Propriétés du Vélocité de changement DevOps.

Remarque :

Si vous utilisez l’action personnalisée d’automatisation des changements GitHub ou l’action personnalisée d’automatisation des changements GitLab Docker dans votre pipeline correspondant pour créer des demandes de changement, vous devez fournir l’intervalle dans l’action personnalisée, ce qui permet à GitHub ou GitLab d’interroger ServiceNow DevOps pour connaître l’état du changement. Lorsque le changement atteint un état approprié dans ServiceNow dans l’intervalle spécifié, l’état approprié, en fonction du résultat du changement, est envoyé au pipeline GitHub ou GitLab, qui reprend ou abandonne le pipeline. Voir Actions personnalisées ServiceNow DevOps à partir de GitHub Marketplace et Implémenter des actions personnalisées pour les pipelines utilisant une image de conteneur Docker générique pour plus de détails. Ainsi, lorsque votre pipeline avec l’action personnalisée de changement est exécuté, et si l’une des notifications d’étapes de GitHub ou GitLab n’a pas atteint ServiceNow DevOps, l’association du rappel, de l’exécution d’étape et de l’exécution de tâche ne se produit pas dans ServiceNow DevOps. Comme l’association n’est pas disponible, le changement ne sera pas créé et ServiceNow DevOps attendra que l’association soit en place. Dans le même temps, GitHub ou GitLab interroge ServiceNow pour connaître l’état du changement jusqu’à ce que l’heure spécifiée dans l’intervalle soit atteinte. Si l’intervalle est dépassé et que le délai d’expiration spécifié dans la sn_devops.change_request_callback_timeout propriété est atteint, ServiceNow DevOps ne mettra pas fin à votre pipeline comme il le devrait, mais le laissera pour le délai d’expiration par défaut défini dans l’étape GitHub ou GitLab qui finira par mettre fin au pipeline. L’information importante dans ce scénario est que ServiceNow DevOps ne sera pas en mesure de notifier l’utilisateur que les événements d’étape n’ont pas atteint ServiceNow DevOps dans les journaux de la console GitHub ou GitLab.

Mise à niveau

Après la mise à niveau, la propriété sera définie sur faux par défaut. Votre processus de changement actuel fonctionnera tel quel, mais la seule différence que vous verrez est que, lorsqu’une erreur se produit lors de la récupération des données DevOps, le pipeline est abandonné (au lieu d’attendre indéfiniment) et la raison de l’erreur est ajoutée dans le champ Détails du traitement de l’événement entrant, et la même chose est notifiée à l’utilisateur dans la console tierce. Si vous souhaitez créer des demandes de changement avec des erreurs lors de la récupération des données DevOps et également ne pas faire échouer votre pipeline, vous pouvez activer la propriété Activer la création de demandes de changement même avec des erreurs dans la récupération de données DevOps . Cela apporte de la valeur à vos approbateurs de changement et à vos équipes AppDev en obtenant les changements créés automatiquement avec des preuves DevOps qui sont rassemblées et notifiées de manière appropriée dans la demande de changement, les notes de travail et les journaux de console tiers avec des erreurs ou des données qui peuvent être manquantes.

Limitation

Si la propriété Activer la création de demandes de changement même avec des erreurs dans la récupération de données DevOps est activée et que l’étape du package d’artefacts ADO dans votre pipeline entraîne une erreur, le changement sera créé sans artefacts ADO qui lui sont associés, mais l’erreur correspondante ne sera pas notifiée dans les notes de travail, ni dans les commentaires sur le changement d’exécution de l’étape, ni dans le journal de la console ADO.