Accélérer votre DevOps processus de changement
Activez la fonctionnalité d’accélération du changement pour la création automatique de demandes de changement dans votre pipeline et utilisez les flux et les politiques d’approbation Vélocité de changement DevOps de changement pour automatiser l’approbation sous certaines conditions.
Vous pouvez afficher les détails des demandes de changement actives en accédant à .
Processus de contrôle des changements
Lorsque le contrôle des changements est activé pour une tâche de votre DevOps pipeline de développement, une demande de changement est automatiquement créée et définie sur l’état Évaluation 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. Les demandes de changement peuvent être approuvées automatiquement en configurant les conditions d’une politique d’approbation de changement.
Les étapes du pipeline peuvent être configurées pour activer les reçus de changement, ce qui ne met pas en pause le pipeline. Les demandes de changement créées avec les reçus de changement activés incluent toutes les données du pipeline, mais ne nécessitent pas d’approbation pour continuer dans le pipeline et la demande de changement sera dans les états post-implémentation. Pour les demandes de changement créées sans activer la réception du changement, le pipeline sera mis en pause jusqu’à ce que la demande de changement soit approuvée, puis le pipeline reprendra.
Si vous souhaitez arrêter la transition automatique des états des demandes de changement même lorsque le reçu de changement est activé, 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 approuvées, automatiquement ou manuellement, les demandes de changement 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é avec le code Fermer comme Réussi en cas d’exécution de tâche réussie ou En échec en cas d’erreur lors de l’exécution de la tâche. Pour plus d’informations sur la personnalisation de vos états de demande de changement, voir Processus de demande de changement personnalisé.
Si une demande de changement n’est pas approuvée et passe à l’état Annulé ou Fermé, la tâche associée Jenkins, GitHub ou ADO est marquée comme ayant échoué et un message de console s’affiche :
Pour Jenkins : [ServiceNow DevOps] L’exécution de la tâche n’a pas été approuvée
Pour GitHub : erreur : **** Le changement a été créé, mais le changement est soit rejeté, soit 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 de changement pour toutes vos demandes de changement DevOps. La 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 Concepteur de flux). Par défaut, le flux d’approbation manuelle de demande 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 spécifie quand exécuter le flux) et d’une séquence d’actions réutilisables (où les actions effectuent une séquence d’opérations sur vos données). Les flux sont intégrés dans Flow Designer, une fonctionnalité qui permet l’automatisation ServiceNow AI Platform 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 de vos besoins professionnels. Assurez-vous qu’un seul flux DevOps est à l’état actif à tout moment pour éviter les conflits et les erreurs. Un flux DevOps est applicable aux demandes de changement qui ont la catégorie DevOps ou si la propriété devops_change est définie sur vrai. (Une demande de changement DevOps créée automatiquement définit la catégorie sur DevOps par défaut).
- Si la demande de changement DevOps est approuvée, le flux met à jour l’état d’exécution de l’étape sur Approuvé, et l’état de la demande de changement est mis à jour sur Implémenter. Après cela, le pipeline reprendra.
- Si la demande de changement DevOps est rejetée, le flux met à jour l’état d’exécution de l’étape sur rejeté et l’état de la demande de changement est mis à jour sur nouveau. Après cela, le pipeline sera interrompu.
- Si la demande de changement DevOps est annulée, le flux met à jour l’état d’exécution de l’étape sur Annulé par l’utilisateur, et la demande de changement est mise à jour sur Annulé. Après cela, le pipeline sera annulé.
Si une règle métier ou une politique de données entraîne une erreur lors de la mise à jour d’un changement dans le flux d’approbation manuelle de demande de changement DevOps, le flux d’approbation d’automatisation minimale de demande de changement DevOps ou le flux d’approbation d’automatisation avancée de demande 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.
| Flux DevOps | Comportement par défaut |
|---|---|
| Flux d’approbation manuelle de demande de changement DevOps | Ce flux est activé par défaut. Avec ce flux, les demandes de changement DevOps doivent passer par un processus d’approbation manuel, où le flux attend que la demande de changement atteigne un état éligible (état rejeté, implémenté ou implémentation spécifique). Lorsqu’il est atteint, ce flux met à jour l’état de l’exécution de l’étape en fonction de l’état de la demande de changement. Si la demande de changement est basée sur le type, le flux attendra que le changement soit rejeté, implémenté ou annulé. Si la demande de changement est basée sur un modèle, le flux attendra que le changement soit rejeté, annulé ou atteigne l’un des états d’implémentation définis dans le modèle ou l’état d’implémentation spécifié dans la propriété DevOps. Ce flux ne se déclenche pas pour les demandes de changement DevOps dont le modèle est un modèle de changement DevOps du système de base (DevOps ou DevOps simplifié) afin d’éviter les conflits et les erreurs. Vous pouvez cloner ce flux et le personnaliser pour apporter des changements. Assurez-vous que les autres flux DevOps sont désactivés. |
| Demande de changement DevOps : flux d’approbation d’automatisation minimale | Ce flux rassemble les données DevOps et exécute la politique d’automatisation minimale de demande de changement DevOps, qui détermine si le changement doit être rejeté automatiquement, approuvé automatiquement ou envoyé pour approbation manuelle. Ce flux est déclenché pour les demandes de changement DevOps dont le type ou le modèle est défini sur normal. Activez ce flux si vous souhaitez automatiser les approbations de demande de changement, mais démarrez de manière minimale. Vous pouvez cloner ce flux et le personnaliser pour apporter des changements. Assurez-vous que les autres flux DevOps sont désactivés. Vous pouvez également ajouter l’action DevOps : mettre à jour le motif de la décision de la politique d’automatisation minimale à ce flux pour mettre à jour les décisions de politique sur le commentaire de changement d’exécution de l’étape et les notes de travail de demande de changement afin de connaître les raisons de la décision. Vous pouvez ajouter cette action à l’intérieur de chaque bloc de décision et spécifier l’entrée requise. |
| Demande de changement DevOps : flux d’approbation d’automatisation avancée | Ce flux rassemble les données DevOps et exécute la politique d’automatisation avancée des demandes de changement DevOps, qui détermine si le changement doit être rejeté automatiquement, approuvé automatiquement ou envoyé pour approbation manuelle. Ce flux est déclenché pour les demandes de changement DevOps dont le type ou le modèle est défini sur normal. Si la demande de changement DevOps est approuvée, le flux met à jour la demande de changement vers l’état planifié et la date de début planifiée est utilisée pour définir la date de début de la demande de changement. À la date de début de la demande de changement, le flux mettra à jour l’état de la demande de changement à implémenter. Après cela, le pipeline reprendra. Activez ce flux si vous souhaitez automatiser les approbations de demandes de changement avec une politique de changement robuste. Vous pouvez cloner ce flux et le personnaliser pour apporter des changements. Assurez-vous que les autres flux DevOps sont désactivés. |
| Flux d’automatisation des changements de démonstration DevOps | Lorsque les données de démonstration sont installées, le flux d’automatisation des changements de démonstration DevOps est disponible où le type normal de demande de changement ou la demande de changement de modèle normal peut être approuvé automatiquement en fonction des politiques de décision. Dans le cadre des données de démonstration, les politiques de décision disponibles sont les suivantes :
|
Pour lire des instructions sur l’utilisation plus efficace des flux, des flux secondaires et des actions, reportez-vous à la section General guidelines for Workflow Studio flows, subflows, and actions.
Politiques d'approbation de changement
- Entrée de politique : sources variables évaluées dans une condition.
- Décisions : détermine si la définition de l’approbation de changement doit être appliquée en fonction des conditions.
- Définitions d’approbation : définit le type d’approbation qui peut être appliqué.
- Politique de changement de modèle DevOps
- Politique d’automatisation minimale de demande de changement DevOps
- Politique d’automatisation avancée de demande de changement DevOps
Pour plus d’informations sur les politiques d’approbation de changement, reportez-vous à la section Politiques d’approbation de changement.
Les flux d’approbation automatisés DevOps utilisent des politiques d’approbation de changement 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 du 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.
Par défaut, la politique d’automatisation minimale de demande de changement DevOps comporte les conditions et critères suivants : Conditions de la
Par défaut, la politique d’automatisation avancée de demande de changement DevOps comporte les conditions et critères suivants :
- Approbation automatique : si les conditions spécifiées dans la politique sont remplies, la demande de changement est automatiquement approuvée.
- Rejet automatique : si une ou plusieurs des conditions spécifiées dans la politique ne sont pas remplies, la demande de changement est automatiquement rejetée.
- Approbation manuelle : si une ou plusieurs conditions nécessitent une approbation manuelle d’un utilisateur ou d’un groupe, cela est spécifié dans la politique. Les notifications sont envoyées par la politique aux utilisateurs ou groupes appropriés pour accélérer l’approbation manuelle et faire progresser la demande de changement.
Vous pouvez appliquer votre politique d’approbation de changement dans l’action 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 sur l’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 :
- Politique d’approbation de changement introuvable. La demande de changement a été rejetée ( %s).
- %s est inactif. La demande de changement a été rejetée ( %s).
- Aucune décision mise en correspondance. %s a été ignoré ( %s).
- Aucune approbation n’a été générée à partir de décisions mises en correspondance. %s a été ignoré ( %s).
- La demande de changement a été rejetée par %s ( %s).
- La demande de changement a été approuvée par %s ( %s).
if (APPROVED.equals(state))
38 message = String.format(APPROVED_MSG, policyName, actionLabel);Flux secondaire du gestionnaire des changements par défaut
- Demandé par
- Justification
- Plan d'implémentation
- Plan de retour en arrière
- Plan de tests
- Description brève
- Description
- Date de début
- Date de fin
- Analyse de l’impact du risque
Le flux secondaire Gestionnaire des changements par défaut remplace les valeurs de champ qui ont été renseignées à l’aide d’un modèle lors de la création de l’enregistrement de 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és
Le type de demande de changement correspond à la table de demande de changement dans le périmètre global.
Listes connexes de demandes de changement automatique
- Validations
- Validations associées à la demande de changement.
- Éléments de travail
- Éléments de travail associés à la demande de changement.
- Versions de l'artefact
Liste des versions d’artefacts associées au package lié à l’exécution du pipeline pour les packages créés avant l’approbation de la demande de changement.
Si aucun package n’est lié à l’exécution du pipeline, la liste est vide.
- Résumés de tests (remplace la liste connexe Résultats des tests)
Liste des résumés de tests pour une exécution de pipeline associée à l’exécution d’un artefact, d’un package ou d’une tâche avant la demande de changement.
Voir Résultats des tests pour plus de détails.
- Résumé de la qualité logicielle
- Liste des résumés de qualité logicielle pour une exécution de pipeline associée à l’exécution d’un artefact, d’un package ou d’une tâche avant la demande de changement.
- Synthèses de Security
- Liste des résumés de sécurité pour une exécution de pipeline associée à l’exécution d’un artefact, d’un package ou d’une tâche avant la demande de changement.Remarque :Les résultats de l’analyse de Security sur l’enregistrement de changement associé à une exécution de pipeline avec un package lié sont également affichés dans l’onglet Synthèses de sécurité.
Processus de demande de changement personnalisé
Ces propriétés de changement DevOps sont disponibles pour personnaliser votre flux de demande de changement.
- État de l'implémentation de la demande de changement DevOps
- État post-implémentation de la demande de changement DevOps
- État de l'annulation de la demande de changement DevOps
- Texte d'approbation de la demande de changement DevOps
Pour personnaliser votre flux de demande de changement, vous devez d’abord créer un . Par exemple, DevOps_Implement (valeur : 10).
Ensuite, ajoutez la liste de choix à .
Une fois que vous avez créé la liste de choix et que vous l’avez ajoutée à l’include de script, vous pouvez mettre à jour les propriétés de changement DevOps avec les nouvelles valeurs de 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 basé sur le DevOps score de risque 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 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 à l’étape de création de package :
Aucun résultat de test n’est affiché, car un package n’est pas encore lié à l’exécution du pipeline.
- Si la demande de changement est créée à une étape postérieure à l’étape de création du package :
Les résumés des tests de construction incluent ceux associés aux étapes postérieures à l’étape de création de package, jusqu’à l’étape contrôlée par les changements.
- Si la demande de changement est créée à l’étape de création de package :
- Les versions de l’artefact sont enregistrées, mais aucun package n’est créé.
- Si la demande de changement est créée à l’étape de la version d’artefact :
Aucun résultat de test ne sera affiché, 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 à une étape postérieure à l’étape de version de l’artefact :
Les résumés des tests de construction incluent ceux de l’étape de version de l’artefact, ainsi que les étapes suivantes, jusqu’à l’étape contrôlée des changements.
- Si la demande de changement est créée à l’étape de la version d’artefact :
- Les versions de l’artefact et le package sont créés dans le pipeline.
- Si la demande de changement fait partie de l’étape après les étapes de création de version d’artefact et de package :
Les résumés des tests de construction incluent ceux associés à l’étape de création de 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 la demande de changement est créée dans une étape (et non la création d’un package) après l’étape de la version de l’artefact, mais avant l’étape de création du package ;
- ou la demande de changement fait partie de l’étape de création de package et les versions d’artefacts sont créées dans le cadre d’une étape antérieure :
Les résumés des tests de construction comprennent ceux associés à l’étape de version de l’artefact, ainsi que les étapes suivantes, jusqu’à l’étape contrôlée par le changement.
- Si la demande de changement fait partie de l’étape après les étapes de création de version d’artefact et de package :
Vue des exécutions de pipelines
Vous pouvez afficher l’activité du pipeline en accédant à .