Processus de contrôle des changements

Lorsque le contrôle des changements est activé pour une tâche dans votre pipeline de développement DevOps, une demande de changement est automatiquement créée et définie sur l'état Évaluer pour demander l'approbation de l'exécution de l'étape ou de la tâche actuelle si un groupe d'affectation est ajouté pour la demande de changement. Il est possible d'approuver automatiquement les demandes de changement en configurant les conditions d'une politique d'approbation des changements.

Vous pouvez configurer les étapes du pipeline de façon à activer les reçus de changement, qui n'interrompent pas le pipeline. Les demandes de changement créées après avoir activé les reçus de changement incluent toutes les données du pipeline, mais il n'est pas nécessaire de les approuver pour poursuivre le pipeline ; les demandes de changement seront par ailleurs définies à l'état Post-implémentation. Si vous créez des demandes de changement sans activer les reçus de changement, le pipeline est mis en pause jusqu'à ce que la demande de changement soit approuvée ; le pipeline reprend une fois l'approbation terminée.

Si vous souhaitez arrêter la transition automatique des états de demande de changement, même lorsque les reçus de changement sont activés, vous devez désactiver la propriété sn_devops.enable_change_receipt_state_transition. Pour plus d'informations, consultez Propriétés du Vélocité de changement DevOps.

Une fois les demandes de changement approuvées, soit automatiquement, soit manuellement, elles passent à l'état Implémenter et la tâche est exécutée. Une fois la tâche exécutée, la demande de changement passe à l'état Fermé, et le code de fermeture indique une réussite si l'exécution de la tâche a réussi ou un échec si l'exécution de la tâche a échoué. Pour en savoir plus sur la personnalisation des états de vos demandes de changement, consultez Processus de demande de changement personnalisé.

Si une demande de changement n'est pas approuvée et est passée à l'état Annulé ou Fermé, la tâche Jenkins, GitHub ou ADO associée est marquée comme ayant échoué et un message s'affiche sur la console :

Pour Jenkins : La tâche [ServiceNow DevOps] n'a pas été approuvée pour être exécutée

Pour GitHub : Erreur : Le changement **** a été créé, mais il a été rejeté ou annulé

Pour ADO : "changeState":"Fermé"

Approbation automatique des demandes de changement à l'aide de flux et de politiques

Vous pouvez automatiser le processus d'approbation des changements pour toutes vos demandes de changement DevOps. Le module Vélocité de changement DevOps utilise des flux et des données DevOps (tels que les éléments de travail, les validations, la couverture du code, la sécurité du code, le risque et les résultats des tests) pour mettre à jour l'état d'une demande de changement et l'approuver automatiquement en fonction des politiques d'approbation de changement. Trois flux sont disponibles dans le système de base que vous pouvez cloner, personnaliser et activer (dans le concepteur de flux). Par défaut, le flux d'approbation manuelle des demandes de changement DevOps est activé. Les flux DevOps ne s'appliquent qu'aux demandes de changement créées automatiquement ou aux demandes de changement dont la réception du changement est désactivée.

Flux

Un flux est un processus automatisé composé d'un déclencheur (qui détermine quand exécuter le flux) et d'une séquence d'actions réutilisables (où les actions exécutent une séquence d'opérations sur vos données). Les flux sont intégrés dans Flow Designer, une ServiceNow AI Platform fonctionnalité qui permet l’automatisation des processus. Pour plus d'informations, consultez Flow Designer.

Vous pouvez utiliser l'un des flux DevOps disponibles dans le système de base comme modèle. Clonez le flux et personnalisez-le en fonction des besoins de votre entreprise. Assurez-vous qu'un seul flux DevOps est à tout moment actif pour éviter les conflits et les erreurs. Un flux DevOps s'applique aux demandes de changement appartenant à la catégorie DevOps ou dont la propriété devops_change est définie sur true. (Une demande de changement DevOps créée automatiquement définit la catégorie sur DevOps par défaut.)

Si une règle métier ou une politique de données provoque une erreur lors de la mise à jour d'un changement dans le flux d'approbation manuelle des demandes de changement DevOps, le flux d'approbation d'automatisation minimale des demandes de changement DevOps ou le flux d'approbation d'automatisation avancée des demandes de changement DevOps, l'erreur correspondante s'affiche dans les notes de travail de la demande de changement et est consignée dans les journaux de la console de l'outil de pipeline.

Pour consulter les directives sur l'utilisation plus efficace des flux, des flux secondaires et des actions, consultez General guidelines for Workflow Studio flows, subflows, and actions.

Politiques d'approbation de changement

Pour plus d'informations sur les politiques d'approbation de changement, consultez Politiques d’approbation de changement.

Les flux d'approbation automatisés DevOps utilisent des politiques d'approbation des changements et des données DevOps (telles que les éléments de travail, les validations, les demandes d'extraction, les résumés de tests, les résumés de sécurité et les résumés de qualité) pour mettre à jour automatiquement l'état de l'enregistrement de changement et l'état d'exécution de l'étape sur Approuvé, Rejeté ou Annulé. Vous pouvez afficher et modifier ces politiques en fonction des besoins de votre entreprise, ou créer les vôtres dans la table de décision. Consultez les tables de décision suivantes.

La politique d'automatisation minimale des demandes de changement DevOps comporte les conditions et critères suivants par défaut :

La politique d'automatisation avancée des demandes de changement DevOps comporte les conditions et critères suivants par défaut :

Vous pouvez appliquer votre politique d'approbation du changement avec l'action de Studio de workflow Gestion des changements pour contrôler le processus d'approbation d'une demande de changement. Pour en savoir plus, Utiliser l'action de flux Appliquer la politique d'approbation de changement.

Notes de travail d'approbation de changement

Lorsqu'une demande de changement est mise à jour en fonction d'un flux et d'une politique d'approbation de changement, les notes de travail associées à la demande de changement sont mises à jour avec l'un des messages codés en dur suivants :

if (APPROVED.equals(state))
38 message = String.format(APPROVED_MSG, policyName, actionLabel);

Flux secondaire du gestionnaire des changements par défaut

Le flux secondaire du gestionnaire des changements par défaut remplace les valeurs de champ renseignées à l'aide d'un modèle lors de la création de l'enregistrement de la demande de changement.

Si vous le souhaitez, vous pouvez écrire un flux secondaire personnalisé à la place de ce flux en modifiant les [sn_devops.change_request_handler_subflow] DevOps property.

Modèles de demandes de changement personnalisées

Le type de demande de changement correspond à la table de demandes de changement dans le champ d'application global.

Listes connexes de demandes de changement automatiques

Processus de demande de changement personnalisé

Ces propriétés de changement DevOps sont disponibles pour personnaliser votre flux de demande de changement.

Pour personnaliser votre flux de demande de changement, vous devez d’abord créer un Définition du système > Liste de choix. Par exemple, DevOps_Implement (valeur - 10).

Ensuite, ajoutez la liste de choix à Définition du système > Script include > ChangeRequestStateHandlerSNC.

Après avoir créé la liste de choix et l'avoir ajoutée à l'include de script, vous pouvez mettre à jour les propriétés de changement DevOps avec les nouvelles valeurs de la liste de choix. Par exemple, DevOps change request implement state -10.

Condition de risque DevOps

Vous pouvez utiliser le calcul du risque et de l'impact DevOps en fonction du score des risques du validateur.

Cette condition est désactivée par défaut.

Liste connexe Résultats des tests

Répertorie les tests qui ont été exécutés dans un pipeline après la création d'un package. Si aucun package n'a été créé, la liste inclut les tests qui ont été exécutés après la création d'une version d'artefact.

Scénarios :

Un package est créé dans le pipeline, mais aucune version d'artefact n'est enregistrée.

• Si la demande de changement est créée lors de l'étape de création du package :

  Aucun résultat de test ne s'affiche, car aucun package n'est encore lié à l'exécution du pipeline.

• Si la demande de changement est créée dans une étape postérieure à l'étape de création du package :

  Les résumés des tests de version incluent ceux associés aux étapes postérieures à l'étape de création du package jusqu'à l'étape contrôlée par le changement.

Les versions d'artefact sont enregistrées, mais aucun package n'est créé.

• Si la demande de changement est créée au cours de l'étape de version d'artefact :

  Aucun résultat de test ne s'affiche, car aucun test n'est associé tant que l'exécution de la tâche n'est pas terminée.

• Si la demande de changement est créée dans une étape postérieure à l'étape de version d'artefact :

  Les résumés des tests de version incluent ceux de l'étape de version d'artefact, ainsi que les étapes suivantes, jusqu'à l'étape contrôlée par le changement.

Les versions d'artefact et le package sont créés dans le pipeline.

• Si la demande de changement fait partie de l'étape postérieure aux étapes de version d'artefact et de création du package :

  Les résumés des tests de version incluent ceux associés à l'étape de création du package, ainsi que les étapes suivantes, jusqu'à l'étape contrôlée par le changement.

• Si la demande de changement fait partie de l'étape de création du package et que les versions d'artefact sont créées dans le cadre d'une étape antérieure ;
  • ou si la demande de changement est créée dans une étape (hormis la création du package) postérieure à l'étape de version d'artefact, mais antérieure à l'étape de création du package ;
  • ou si la demande de changement fait partie de l'étape de création du package et les versions d'artefact sont créées dans le cadre d'une étape antérieure :

  Les résumés des tests de version incluent ceux associés à l'étape de version d'artefact, ainsi que les étapes suivantes, jusqu'à l'étape contrôlée par le changement.

Vue Exécutions de pipelines

Vous pouvez afficher l’activité du pipeline en accédant à DevOps > Orchestrer > Exécutions de pipelines.