Modèles de changement DevOps
Vélocité de changement DevOps vous permet d'utiliser des modèles de changement adaptés qui offrent une plus grande flexibilité lors de la définition des modèles ou des processus de changement pour refléter les pratiques de développement modernes.
Vue d'ensemble du modèle de changement DevOps
Important :
Pour les demandes de changement DevOps, utilisez la fonctionnalité Gestion des changements - Modèles de changement, qui offre une plus grande flexibilité pour activer le flux de processus de changement d'une manière optimisée pour des cas d'utilisation spécifiques. Pour plus d'informations, consultez Modèles de changement. Le modèle Gestion des changements - État hérité est également pris en charge. Pour plus d'informations, consultez legacy: modèle d’état et transitions.
Important :
Les modèles de changement DevOps et simplifiés DevOps ne sont pas pris en charge pour les demandes de changement d'outil Argo CD et Split.
Utilisez des modèles de changement adaptés à vos besoins avec une suite de flux succincts et d'actions de flux intégrées dans le concepteur de flux pour des cas d'utilisation spécifiques. Au lieu d'utiliser les processus de changement hérités basés sur ITIL, qui sont prédéfinis dans les workflows de changement (Normal, Standard et Urgence), vous pouvez effectuer une transition sélective vers un large éventail de modèles optimisés adaptés à des cas d'utilisation spécifiques. Les modèles de changement peuvent être créés avec des états et des règles qui déterminent les transitions entre les états. Pour en savoir plus sur les modèles de changement, consultez Modèles de changement.
Vous pouvez utiliser n'importe lequel des modèles de changement du système de base, y compris les modèles de changement DevOps ou simplifiés DevOps. Pour créer une demande de changement basée sur des modèles, vous pouvez configurer le champ Modèle dans le formulaire Étape de ServiceNow, ou transmettre le sys_id ou le nom du modèle dans l'étape de changement à partir de votre pipeline d'orchestration.
Modèles de changement DevOps du système de base
Deux modèles de changement, appelés DevOps et simplifié DevOps, sont inclus dans le système de base et sont activés par défaut pour vous permettre de créer une demande de changement basée sur des modèles.
- Marqueur de compatibilité de type
-
La propriété de compatibilité de type com.snc.change_management.change_model.type_compatibility permet de déterminer le type de demandes de changement (basées sur les types ou les modèles) qui vont être créées. Accédez à Propriétés système > Toutes les propriétés pour définir la valeur de cette propriété. Cette propriété est définie par défaut sur la valeur False. Cette propriété active la compatibilité des types de changements pour les modèles de changement. Lorsqu'elle est définie sur true, il est possible de créer la demande de changement en tant que workflow basé sur le type ou en tant que modèles de changement. Lorsqu'elle est définie sur false, la demande de changement est créée uniquement à l'aide du modèle de changement.
La demande de changement est créée en fonction de la combinaison de configuration définie dans les tables suivantes lorsque la propriété est définie sur true ou false.
Tableau 1. Lorsque la propriété de compatibilité des types est définie sur True Attribut de changement configuré dans l'étape de pipeline dans ServiceNow Attribut de changement transmis dans le pipeline Attribut de changement pris en compte dans la création de la demande de changement Modèle de changement : <tout modèle de changement sélectionné> Ni le modèle ni le type de changement ne sont transmis. Une demande de changement basée sur un modèle est créée Modèle de changement : <tout modèle de changement sélectionné> Le type est transmis. Par exemple, Normal { "attributes": { "type": "normal" } }Une demande de changement basée sur le type est créée Modèle de changement : <tout modèle de changement sélectionné> par exemple, Modèle 1. Un modèle différent est transmis. Par exemple, Modèle 2.{ "attributes": { "chg_model": { "name": "Model 2" } } }Le changement est créé en fonction du Modèle 2 Modèle de changement : non spécifié
Type de changement : <tout type de changement sélectionné>
Ni le modèle ni le type de changement ne sont transmis Une demande de changement basée sur le type est créée Type de changement : <tout type de changement sélectionné> Le modèle est transmis. { "attributes": { "chg_model": { "name": "DevOps" } } }Une demande de changement basée sur un modèle est créée Type de changement : <tout type de changement sélectionné>. Par exemple, Normal Un type différent est transmis. Par exemple, Urgence.{ "attributes": { "type": "emergency" } }La demande de changement est créée en fonction du type Urgence. Tableau 2. Lorsque la propriété de compatibilité des types est définie sur False Attribut de changement configuré dans l'étape de pipeline dans ServiceNow Attribut de changement transmis dans le pipeline Attribut de changement pris en compte dans la création de la demande de changement Modèle de changement : <tout modèle de changement sélectionné> Ni le modèle ni le type de changement ne sont transmis Une demande de changement basée sur un modèle est créée Modèle de changement : <tout modèle de changement sélectionné> Le type est transmis. Par exemple, Normal { "attributes": { "type": "normal" } }Erreur Impossible de créer la demande de changement, car le marqueur de compatibilité des types est désactivé. Activez le marqueur de compatibilité des types dans les propriétés système ou configurez le modèle de changement dans l'enregistrement d'étape dans ServiceNow, ou saisissez le sys id du modèle de changement approprié dans le pipeline.
Pour en savoir plus sur la résolution de cette erreur, voir Erreurs courantes dans Vélocité de changement DevOps.
Modèle de changement : <tout modèle de changement sélectionné> par exemple, Modèle 1. Un modèle différent est transmis. Par exemple, Modèle 2.{ "attributes": { "chg_model": { "name": "Model 2" } } }Le changement est créé en fonction du Modèle 2 Modèle de changement : non spécifié
Type de changement : <tout type de changement sélectionné>
Ni le modèle ni le type de changement ne sont transmis. Erreur Impossible de créer une demande de changement, car le type de changement ou le modèle de changement n'est pas configuré pour le pipeline.
Pour en savoir plus sur la résolution de cette erreur, consultez Erreurs courantes dans Vélocité de changement DevOps.
Type de changement : <tout type de changement sélectionné> Le modèle est transmis. { "attributes": { "chg_model": { "name": "DevOps" } } }Une demande de changement basée sur un modèle est créée Type de changement : <tout type de changement sélectionné>. Par exemple, Normal Un type différent est transmis. Par exemple, Urgence.{ "attributes": { "type": "emergency" } }Erreur Impossible de créer la demande de changement, car le marqueur de compatibilité des types est désactivé. Activez le marqueur de compatibilité des types dans les propriétés système ou configurez le modèle de changement dans l'enregistrement d'étape dans ServiceNow, ou saisissez le sys id du modèle de changement approprié dans le pipeline.
Pour en savoir plus sur la résolution de cette erreur, consultez Erreurs courantes dans Vélocité de changement DevOps.
- Configurer les modèles DevOps
-
La valeur du champ États d'implémentation des modèles de changement du système de base est définie sur Implémentation, et le champ Enregistrement prédéfini est défini sur Type=Normal par défaut. Les états disponibles pour le modèle de changement DevOps sont les suivants : Nouveau, Évaluer, Autoriser, Planifié, Implémenter, Réviser, Fermé et Annulé. De plus, les états disponibles pour le modèle de changement simplifié DevOps sont les suivants : Nouveau, Autoriser, Planifié, Implémenter, Réviser, Fermé et Annulé. En fonction de vos besoins, vous pouvez modifier les modèles de changement et configurer les états et les transitions selon votre cas d'utilisation spécifique.
Figure 1. Modèle de changement DevOps Figure 2. Modèle de changement simplifié DevOps Pour créer votre propre modèle au lieu d'utiliser les modèles DevOps du système de base, consultez les instructions de la section Créer un modèle de changement.
Vous pouvez utiliser des préréglages d'enregistrement pour configurer les détails de changement de votre modèle de changement. Chaque fois qu'un changement est créé, ces valeurs sont automatiquement définies sur le changement. Vous pouvez définir un préréglage d'enregistrement pour n'importe quel champ de changement existant dans la demande de changement.
La logique suivante est prise en compte pour préremplir les détails du changement lors de la création d'une demande de changement.- Si vous avez configuré les détails du changement dans le préréglage d'enregistrement, vous ne pouvez pas remplacer cette valeur en transmettant les détails du changement à partir du pipeline.
- Si les détails du changement ne sont pas configurés dans le préréglage d'enregistrement, les valeurs transmises à partir du pipeline sont prises en compte pour préremplir les détails dans la demande de changement.
- Si les détails du changement ne sont ni configurés dans le préréglage d'enregistrement, ni transmis à partir du pipeline, les valeurs configurées dans le formulaire Étape de ServiceNow sont prises en compte.
Détails du changement configurés dans le préréglage d'enregistrement de ServiceNow Détails du changement configurés dans le formulaire Étape de ServiceNow Détails du changement transmis dans le pipeline Les détails du changement sont préremplis lors de la création du changement Groupe d'affectation : rapport DevOps Groupe d'affectation : non spécifié Groupe d'affectation : non spécifié Le groupe d'affectation est prérempli à partir du préréglage d'enregistrement dans la demande de changement Groupe d'affectation : non configuré Groupe d'affectation : non spécifié Groupe d'affectation : rapport DevOps Le groupe d'affectation est prérempli à partir du pipeline dans la demande de changement Groupe d'affectation : non configuré Groupe d'affectation : rapport DevOps Groupe d'affectation : non spécifié Le groupe d'affectation est prérempli à partir du formulaire Étape dans la demande de changement
Modèle de changement DevOps
Le modèle de changement DevOps contient des flux dans le système de base pour les transitions d'états et les approbations de changements. Chaque état du modèle DevOps a ses propres flux, et chaque flux est déclenché lorsque les conditions requises sont remplies. L'approbation des changements (automatique ou manuelle) est basée sur la politique de changement du modèle DevOps. Par défaut, seule la décision d'approbation manuelle est activée pour la politique de changement de modèle DevOps du système de base. Lorsque vous êtes prêt à automatiser les approbations, vous pouvez modifier la politique. Les flux suivants expliquent le comportement d'approbation des transitions d'états et des changements.- Changement - DevOps - Nouveau : lorsque la demande de changement est créée à l'état Nouveau, ce flux est déclenché. S'il possède un groupe d'affectation, ce flux met à jour l'état du changement sur Évaluer.
- Changement - DevOps - Évaluer : lorsque la demande de changement est à l'état Évaluer, ce flux est déclenché. Il existe deux actions clés dans ce flux : Collecte des données de politique de changement DevOps et Appliquer la politique d'approbation de changement ; toutes deux sont utilisées pour récupérer les données DevOps associées à la demande de changement et vérifier si la demande de changement doit être approuvée automatiquement, rejetée automatiquement ou envoyée pour approbation manuelle. L'approbation du changement (automatique ou manuelle) se produit dans le cadre de ce flux, dans l'action Appliquer la politique d'approbation de changement basée sur la politique de changement du modèle DevOps. Si le changement est approuvé (automatiquement ou manuellement), il passe à l'état Autoriser. Si le changement est rejeté, une notification par e-mail est envoyée à l'utilisateur qui a demandé le changement et le changement est renvoyé à l'état Nouveau.
- Changement - DevOps - Autoriser : lorsque la demande de changement est à l'état Autoriser, ce flux est déclenché. Dans le système de base, vous observez qu'il existe deux actions clés : Collecte des données de politique de changement DevOps et Appliquer la politique d'approbation de changement, toutes deux utilisées pour récupérer les données DevOps associées à la demande de changement et vérifier si la demande de changement doit être approuvée automatiquement, rejetée automatiquement ou envoyée pour approbation manuelle. Les conditions de la politique de changement de modèle DevOps dans l'action Appliquer la politique d'approbation de changement ne sont pas remplies. L'approbation du changement (automatiquement ou manuellement) dans ce flux est donc ignorée. Ce flux place uniquement la demande de changement à l'état Planifié, ce qui déclenche le flux Changement - DevOps - Planifier. Remarque :Si votre processus de changement nécessite une autre approbation, vous pouvez vous référer à ce flux et personnaliser la politique de changement de modèle DevOps en fonction de vos besoins.
- Changement - DevOps - Planifier : lorsque la demande de changement est à l'état Planifié, ce flux est déclenché. Lorsque la date de début prévue est atteinte, le changement passe à l'état Implémenter.
- Changement - DevOps - Implémenter : lorsque la demande de changement est à l'état Implémenter, ce flux est déclenché.
La politique de changement de modèle DevOps contient les entrées de politique suivantes :
- is_change_with_partial_data
- regression_tests_failed
- code_security
- code_coverage
- total_num_of_commits
- tests_passing_percent
- load_tests_failed
- num_of_open_incidents
- num_of_outages_in_last_7_days
- num_of_current_outages
- integration_tests_failed
- commits_without_work_item
- change_request
- risk
Les trois résultats de la politique de changement de modèle DevOps (en fonction des conditions que vous spécifiez) sont les 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 de la part d'un utilisateur ou d'un groupe, elles sont spécifiées dans la politique. Les notifications sont envoyées par la politique aux utilisateurs ou groupes concernés pour accélérer l'approbation manuelle et faire progresser la demande de changement.Remarque :Par défaut, seule la décision d'approbation manuelle est activée pour la politique de changement de modèle DevOps du système de base.
Important :
Si vous utilisez le modèle DevOps du système de base tel quel, l'approbation du changement est automatisée par défaut. Si vous ne souhaitez pas automatiser l'approbation du changement, vous pouvez modifier la politique de changement du modèle DevOps en l'adaptant à votre processus de changement actuel.
Modèle DevOps simplifié
Le modèle de changement DevOps simplifié contient des flux dans le système de base pour les transitions d'états et les approbations de changements. Chaque état du modèle DevOps simplifié a ses propres flux, et chaque flux est déclenché lorsque les conditions requises sont remplies. L'approbation de changement (automatique ou manuelle) repose sur la politique de changement du modèle DevOps simplifié. Les flux suivants expliquent le comportement d'approbation des transitions d'états et des changements.
- Changement - DevOps simplifié - Nouveau : lorsque la demande de changement est créée à l'état Nouveau, ce flux est déclenché. S'il possède un groupe d'affectation, ce flux met à jour l'état du changement sur Évaluer.
- Changement - DevOps simplifié - Autoriser : lorsque la demande de changement est à l'état Autoriser, ce flux est déclenché. Il existe deux actions clés dans ce flux : Collecte des données de politique de changement DevOps et Appliquer la politique d'approbation de changement ; toutes deux sont utilisées pour récupérer les données DevOps associées à la demande de changement et vérifier si la demande de changement doit être approuvée automatiquement, rejetée automatiquement ou envoyée pour approbation manuelle. L'approbation du changement (automatique ou manuelle) se produit dans le cadre de ce flux dans l'action Appliquer la politique d'approbation de changement basée sur la politique de changement du modèle DevOps simplifié. Si le changement est approuvé (automatiquement ou manuellement), il passe à l'état Planifier. Si le changement est rejeté, une notification par e-mail est envoyée à l'utilisateur qui a demandé le changement et le changement est renvoyé à l'état Nouveau. Remarque :Si votre processus de changement nécessite une autre approbation, vous pouvez vous référer à ce flux et personnaliser la politique de changement de modèle DevOps simplifié en fonction de vos besoins.
- Changement - DevOps simplifié - Planifier : lorsque la demande de changement est à l'état Planifié, ce flux est déclenché. Lorsque la date de début prévue est atteinte, le changement passe à l'état Implémenter.
- Changement - DevOps simplifié - Implémenter : lorsque la demande de changement est à l'état Implémenter, ce flux est déclenché.
La politique de changement de modèle DevOps simplifié contient les entrées de politique suivantes :
- is_change_with_partial_data
- regression_tests_failed
- code_security
- code_coverage
- total_num_of_commits
- tests_passing_percent
- load_tests_failed
- num_of_open_incidents
- num_of_outages_in_last_7_days
- num_of_current_outages
- integration_tests_failed
- commits_without_work_item
- change_request
- risk
Les trois résultats de la politique de changement de modèle DevOps simplifié (en fonction des conditions que vous spécifiez) sont les 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 de la part d'un utilisateur ou d'un groupe, elles sont spécifiées dans la politique. Les notifications sont envoyées par la politique aux utilisateurs ou groupes concernés pour accélérer l'approbation manuelle et faire progresser la demande de changement.Remarque :Par défaut, seule la décision d'approbation manuelle est activée pour la politique de changement de modèle DevOps simplifié du système de base.
Rappel pour reprendre le pipeline
Dans Vélocité de changement DevOps, les facteurs suivants sont pris en compte pour envoyer une demande de rappel.
- Les états d'implémentation sont utilisés pour envoyer un rappel à l'outil d'orchestration tiers. Si un seul état d'implémentation est présent dans le modèle de changement, une comparaison absolue est effectuée. Lorsque le changement créé par un modèle de changement atteint l'état d'implémentation défini, un rappel est envoyé à l'outil d'orchestration tiers.Remarque :Dans les modèles de changement, le champ États d'implémentation peut avoir un ou plusieurs états. Vous pouvez définir les états d'implémentation pour chaque modèle de changement. Pour plus d'informations, consultez legacy: modèle d’état et transitions.
- Si plusieurs états d'implémentation sont présents dans le modèle de changement, un rappel est envoyé à l'outil d'orchestration tiers dans l'état où l'état d'implémentation est atteint en premier.
- Si aucun état d'implémentation n'est défini sur le modèle de changement, l'état Implémenter est recherché parmi les états du modèle. Si l'état Implémenter est présent, le rappel vers l'outil d'orchestration tiers est pris en compte. Si l'état Implémenter est absent des états du modèle, la valeur présente dans la propriété sn_devops.change_request.implement_state est prise en compte. Par défaut, la valeur de la propriété système est -1, ce qui correspond à l'état Implémenter.
Remarque :
Le flux Changement – DevOps – Mettre à jour l'état d'exécution permet d'envoyer un rappel à l'outil d'orchestration tiers. Ce flux d'approbation attend jusqu'à ce que la demande de changement soit à l'état Implémenter. Une fois que la demande de changement atteint l'état Implémenter, ce flux met à jour l'enregistrement d'exécution de l'étape à l'état approprié (approuvé, rejeté, annulé). Dès que l'enregistrement d'exécution de l'étape est mis à jour, le flux de rappel de contrôle des changements est déclenché pour envoyer le rappel à l'outil tiers.
Après la mise à niveau
- Le champ Modèle de changement s'affiche dans le formulaire Étape. Cela n'a pas d'incidence sur votre processus existant de création de changements basés sur les types, car la propriété de compatibilité des types (com.snc.change_management.change_model.type_compatibility) est définie sur true.
- Si vous souhaitez disposer d'une demande de changement basée sur un modèle, définissez la propriété de compatibilité des types sur false. Le champ Modèle de changement du formulaire Étape est requis. Pour en savoir plus sur la combinaison de configuration basée sur la propriété, consultez le tableau Lorsque la propriété de compatibilité des types est définie sur False.
Remarque :
Si vous êtes un client existant et que vous avez effectué un démarrage zboot de votre instance, ou si vous êtes un nouveau client, vous pouvez par défaut créer des demandes de changement basées sur les modèles. Vous pouvez toutefois créer des demandes de changement basées sur les types en définissant la propriété de compatibilité des types sur true.
Consultez le tableau suivant pour comprendre comment utiliser la fonctionnalité de modèle de changement pour les nouveaux clients et les clients mis à niveau.
| Nouvelle instance ou instance de mise à niveau | Marqueur de compatibilité de type | Modèle ou type | Flux de transitions d'états | Flux d'approbation des changements automatique | Rappel à un tiers |
|---|---|---|---|---|---|
| zboot (nouveau démarrage zboot ou démarrage zboot existant) | faux | Modèle DevOps |
|
Dans le système de base, l'approbation du changement (automatique ou manuelle) se fait via le flux Demande de changement - DevOps - Évaluer. Si vous souhaitez disposer d'un niveau d'approbation supplémentaire, vous pouvez vous référer au flux Demande de changement - DevOps - Autoriser et personnaliser la politique de changement du modèle DevOps en conséquence. | Consultez la remarque dans la section Rappel. |
| Mise à niveau | faux | Modèle DevOps |
|
Dans le système de base, l'approbation du changement (automatique ou manuelle) se fait via le flux Demande de changement - DevOps - Évaluer. Si vous souhaitez disposer d'un niveau d'approbation supplémentaire, vous pouvez vous référer au flux Demande de changement - DevOps - Autoriser et personnaliser la politique de changement du modèle DevOps en conséquence. | Consultez la remarque dans la section Rappel. |
| zboot (nouveau démarrage zboot ou démarrage zboot existant) | faux | Modèle DevOps simplifié |
|
Dans le système de base, l'approbation du changement (automatique ou manuelle) se fait via le flux Demande de changement - DevOps - Autoriser. Si vous souhaitez disposer d'un niveau d'approbation supplémentaire, vous pouvez personnaliser la politique de changement du modèle DevOps simplifié en conséquence. | Consultez la remarque dans la section Rappel. |
| Mise à niveau | faux | Modèle DevOps simplifié |
|
Dans le système de base, l'approbation du changement (automatique ou manuelle) se fait via le flux Demande de changement - DevOps - Autoriser. Si vous souhaitez disposer d'un niveau d'approbation supplémentaire, vous pouvez personnaliser la politique de changement du modèle DevOps simplifié en conséquence. | Consultez la remarque dans la section Rappel. |
| Mise à niveau | VRAI | Type | Le comportement actuel est maintenu. | Flux Approbation manuelle des demandes de changement DevOps, Approbation d'automatisation minimale des demandes de changement DevOps ou Approbation d'automatisation avancée des demandes de changement DevOps (selon le flux actif) | Flux de rappel du contrôle des changements |