Création d’une demande de changement avec des 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.

Création de changement avec vue d’ensemble des données DevOps

Remarque :

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

Vous pouvez créer une demande de changement avec ou sans erreurs dans 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 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 les éléments de travail, les validations, les résumés de tests ou les 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 dans l’enregistrement d’exécution de l’étape et dans les notes de travail du 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 n’est créée que lorsqu’il n’y a aucune erreur dans aucune é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 du traitement de l’événement entrant, puis notifié à l’utilisateur dans la console tierce.

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

Approbation des demandes de changement comportant 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 manuel 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 Collecte des 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 en 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 sera créé avec les données DevOps du pipeline de version, même s’il y a une erreur lors de la récupération de certaines données. Vous pouvez observer ce comportement même 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. 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 dans l’état En attente pendant une exécution de pipeline, le système tente de traiter le changement jusqu’à ce que la valeur du 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 d’un délai 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 Changements de vélocité 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 de l’action personnalisée, ce qui permet à GitHub ou GitLab d’interroger ServiceNow DevOps pour 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 de la place de marché GitHub et ServiceNow Actions personnalisées pour GitLab 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’étape de GitHub ou GitLab n’a pas atteint ServiceNow DevOps, l’association du rappel, de l’exécution des étapes et de l’exécution des tâches ne se produit pas dans ServiceNow DevOps. Comme l’association n’est pas disponible, le changement n’est pas créé et ServiceNow DevOps attend que l’association soit en place. En même temps, GitHub ou GitLab interroge ServiceNow sur l’état du changement jusqu’à ce que l’heure spécifiée dans l’intervalle soit atteinte. Si l’intervalle est réussi et que le délai d’expiration spécifié dans la sn_devops.change_request_callback_timeout propriété est atteint, ServiceNow DevOps n’arrête pas votre pipeline comme il se doit, mais le laisse pour le délai d’expiration par défaut défini dans l’étape GitHub ou GitLab qui finira par arrêter le pipeline. L’information importante dans ce scénario est que ServiceNow DevOps ne sera pas en mesure d’informer 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 false 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 le motif de l’erreur est ajouté 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 comportant des erreurs lors de la récupération des données DevOps et 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 créant automatiquement les changements avec les preuves DevOps recueillies et notifiées de manière appropriée dans la demande de changement, les notes de travail et les journaux de console tiers contenant 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 de package d’artefact ADO dans votre pipeline entraîne une erreur, le changement est créé sans artefacts ADO associés, mais l’erreur correspondante n’est pas notifiée dans les notes de travail, les commentaires sur le changement d’exécution de l’étape ou dans le journal de la console ADO.