DevOps Modèles de changement

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. L’ancien module d’extension Gestion des changements - State Model est également pris en charge. Pour plus d'informations, consultez Modèle et transitions d’état.

Important :

Les modèles de changement DevOps et DevOps simplifié ne sont pas pris en charge pour les demandes de changement des outils Argo CD et Split.

Utilisez des modèles de changement adaptés aux besoins avec une suite de flux et d’actions de flux succincts intégrées dans 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 Urgent), vous pouvez effectuer une transition sélective vers un large éventail de modèles optimisés pour des cas d’utilisation spécifiques. Des modèles de changement peuvent être créés avec des états et des règles qui déterminent les transitions entre les états. Pour plus d’informations sur les modèles de changement, reportez-vous à la section Modèles de changement.

Vous pouvez utiliser n’importe quel modèle de changement du système de base, y compris les modèles de changement DevOps ou DevOps simplifiés. Pour créer une demande de changement basée sur des modèles, vous pouvez configurer le champ Modèle dans le formulaire Étape dans 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 DevOps simplifié, sont inclus dans le système de base et sont actifs par défaut pour vous permettre de créer une demande de changement basée sur un modèle.

Marqueur de compatibilité type

La propriété de compatibilité com.snc.change_management.change_model.type_compatibility de type est utilisée pour déterminer le type de demande de changement (basé sur le type ou le modèle) qui sera créé. Accédez aux propriétés système > Toutes les propriétés pour définir la valeur de cette propriété. La valeur par défaut de cette propriété est Faux. Cette propriété permet la compatibilité des types de changement pour les modèles de changement. Lorsque la valeur est définie sur vrai, la demande de changement peut être créée sous la forme d’un workflow basé sur le type ou de modèles de changement. Si elle est définie sur faux, la demande de changement est créée uniquement à l’aide du modèle de changement.

La demande de changement sera créée en fonction de la combinaison de configuration telle que définie dans les tables suivantes lorsque la propriété est définie sur vrai ou faux.

Tableau 1. Lorsque la propriété de compatibilité de type est définie sur Vrai
Changer l’attribut configuré à l’étape du 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 sera 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 sera 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, Model 2. `{ "attributes": { "chg_model": { "name": "Model 2" } } }`	Le changement sera créé en fonction du modèle 2
Modèle de changement : non spécifié Type de changement : <n’importe quel 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 sera créée
Type de changement : <n’importe quel type de changement sélectionné>	Le modèle est réussi. `{ "attributes": { "chg_model": { "name": "DevOps" } } }`	Une demande de changement basée sur un modèle sera 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 sera créée en fonction du type Urgence.

Tableau 2. Lorsque la propriété de compatibilité de type est définie sur Faux
Changer l’attribut configuré à l’étape du 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 sera créée
Modèle de changement : <tout modèle de changement sélectionné>	Le type est transmis. Par exemple, Normal `{ "attributes": { "type": "normal" } }`	Erreur La demande de changement ne peut pas être créée, car le marqueur de compatibilité type est désactivé. Activez le marqueur de compatibilité de type dans les propriétés système ou configurez le modèle de changement dans l’enregistrement d’étape dans ServiceNow, ou saisissez l’ID système ou le nom du modèle de changement approprié dans le pipeline. Pour en savoir plus sur la résolution de cette erreur, reportez-vous à la section 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, Model 2. `{ "attributes": { "chg_model": { "name": "Model 2" } } }`	Le changement sera créé en fonction du modèle 2
Modèle de changement : non spécifié Type de changement : <n’importe quel type de changement sélectionné>	Ni le modèle ni le type de changement ne sont transmis.	Erreur Impossible de créer la 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, reportez-vous à la section Erreurs courantes dans Vélocité de changement DevOps.
Type de changement : <n’importe quel type de changement sélectionné>	Le modèle est réussi. `{ "attributes": { "chg_model": { "name": "DevOps" } } }`	Une demande de changement basée sur un modèle sera 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é type est désactivé. Activez le marqueur de compatibilité de type dans les propriétés système ou configurez le modèle de changement dans l’enregistrement d’étape dans ServiceNow, ou saisissez l’ID système ou le nom du modèle de changement approprié dans le pipeline. Pour en savoir plus sur la résolution de cette erreur, reportez-vous à la section Erreurs courantes dans Vélocité de changement DevOps.

Configuration des modèles DevOps

La valeur du champ États d’implémentation pour les modèles de changement du système de base est Implémenter et le champ Préréglage d’enregistrement est sélectionné comme Type=Normal par défaut. Les états de modèle disponibles pour le modèle de changement DevOps sont Nouveau, Évaluer, Autoriser, Planifié, Implémenter, Revue, Fermé et Annulé. De plus, les états de modèle disponibles pour le modèle de changement simplifié DevOps sont Nouveau, Autoriser, Planifié, Implémenter, Revue, Fermé et Annulé. En fonction de vos besoins, vous pouvez modifier les modèles de changement et configurer les états et les transitions pour votre cas d’utilisation spécifique.

Figure 2. DevOps : modèle de changement simplifié

Si vous souhaitez créer votre propre modèle au lieu d’utiliser les modèles DevOps du système de base, consultez les instructions de la Créer un modèle de changement section.

Vous pouvez utiliser des paramètres prédéfinis d’enregistrement pour configurer les détails du changement pour votre modèle de changement. Chaque fois qu’un changement est créé, ces valeurs seront automatiquement définies sur le changement. Vous pouvez définir un paramètre prédéfini d’enregistrement pour n’importe quel champ de changement qui existe dans la demande de changement.

La logique suivante est prise en compte pour le pré-dépôt des 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 paramètre prédéfini de l’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 paramètre prédéfini d’enregistrement, les valeurs transmises à partir du pipeline sont prises en compte pour le pré-dépôt des détails dans la demande de changement.
Si les détails du changement ne sont ni configurés dans le paramètre prédéfini d’enregistrement ni transmis à partir du pipeline, les valeurs configurées dans le formulaire Étape dans ServiceNow sont prises en compte.


Modifier les détails configurés dans un paramètre prédéfini de l’enregistrement dans ServiceNow	Modifier les détails configurés dans le formulaire Étape dans ServiceNow	Détails du changement transmis dans le pipeline	Détails du changement 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 sera pré-rempli à partir du paramètre prédéfini 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 sera 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 sera pré-rempli à partir du formulaire Étape dans la demande de changement

DevOps : modèle de changement

Le modèle de changement DevOps contient des flux dans le système de base pour les transitions d’états et les approbations de changement. Chaque état du modèle DevOps a ses propres flux et chaque flux est déclenché lorsque les conditions requises sont remplies. L’approbation de changement (automatique ou manuelle) est basée sur la politique de changement de 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 pour une automatisation des approbations supplémentaire, vous pouvez modifier la politique. Les flux suivants expliquent la transition d’état et le comportement d’approbation des changements.

Changement - DevOps - Nouveau : lorsque la demande de changement est créée à l’état Nouveau, ce flux est déclenché. S’il dispose d’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 : DevOps : collecter les données de la politique de changement et Appliquer la politique d’approbation des changements, qui 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 de modèle DevOps. Si le changement est approuvé (automatique ou manuel), il passe à l’état Autorisé. Si le changement est rejeté, une notification par e-mail est envoyée à l’utilisateur qui l’a demandé et le changement est renvoyé à l’état Nouveau.
Changement - DevOps - Autoriser : lorsque la demande de changement est à l’état Autorisé, ce flux est déclenché. Dans le système de base, vous remarquerez qu’il existe deux actions clés : DevOps : collecter les données de politique de changement et appliquer la politique d’approbation de changement, qui 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. Les conditions de la politique de changement de modèle DevOps de l’action Appliquer la politique d’approbation de changement ne seront pas remplies. L’approbation du changement (automatique ou manuelle) dans ce flux sera donc ignorée. Ce flux déplace uniquement l’état de la demande de changement vers Planifié qui déclenche le flux Changement - DevOps - Calendrier.
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 - Calendrier : lorsque la demande de changement est à l’état Planifié, ce flux est déclenché. Lorsque la date de début planifiée 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 (selon les 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 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.
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 :

Lorsque vous utilisez le modèle DevOps du système de base tel quel, l’approbation de changement est automatisée par défaut. Si vous ne souhaitez pas une approbation automatisée des changements, vous pouvez modifier la politique de changement de modèle DevOps de manière à ce qu’elle convienne à votre processus de changement actuel.

Modèle simplifié DevOps

Le modèle de changement simplifié DevOps contient des flux dans le système de base pour les transitions d’état et les approbations de changement. Chaque état du modèle simplifié 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 de modèle simplifié DevOps. Les flux suivants expliquent la transition d’état et le comportement d’approbation des changements.

Changement : DevOps simplifié : nouveau : lorsque la demande de changement est créée dans l’état Nouveau, ce flux est déclenché. S’il dispose d’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 Autorisé, ce flux est déclenché. Il existe deux actions clés dans ce flux : DevOps : collecter les données de la politique de changement et Appliquer la politique d’approbation des changements, qui 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 des changements basée sur la politique de changement de modèle simplifié DevOps. Si le changement est approuvé (automatique ou manuel), il passe à l’état Calendrier. Si le changement est rejeté, une notification par e-mail est envoyée à l’utilisateur qui l’a demandé 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 simplifié DevOps en fonction de vos besoins.
Changement : DevOps simplifié : calendrier : lorsque la demande de changement est à l’état Planifié, ce flux est déclenché. Lorsque la date de début planifiée 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 simplifié 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 simplifié 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 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.
Remarque :
Par défaut, seule la décision d’approbation manuelle est activée dans la politique de changement de modèle simplifié DevOps du système de base.

Rappel pour reprendre le pipeline

Dans DevOps Change Velocity, les considérations suivantes sont prises 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 Modèle et transitions d’état.
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, les états des modèles sont vérifiés pour l’état Implémentation . Si l’état Implémenter est présent, il est pris en compte pour le rappel vers l’outil d’orchestration tiers. S’il n’y a pas non plus d’état d’implémentation dans les états du modèle, la valeur présente dans la propriété sn_devops.change_request.implement_state est prise en compte. La valeur de la propriété système est -1 par défaut, qui correspond à l’état Implémenter.

Remarque :

Le flux Modifier l’état d’exécution DevOps – Mettre à jour est utilisé pour envoyer un rappel à l’outil d’orchestration tiers. Ce flux d’approbation attend que la demande de changement affiche l’état Implémenter. Une fois que la demande de changement atteint l’état Implémentation, ce flux met à jour l’enregistrement d’exécution de l’étape sur 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’aura pas d’impact sur votre processus de création de changement basé sur le type existant, car la propriété de compatibilité de type (com.snc.change_management.change_model.type_compatibility) est vraie.
Si vous souhaitez avoir une demande de changement basée sur un modèle, définissez la propriété de compatibilité de type sur faux. Le champ Modèle de changement du formulaire Étape est requis. Pour plus d’informations sur la combinaison de configuration basée sur la propriété, consultez le tableau Lorsque la propriété de compatibilité de type est définie sur Faux.

Remarque :

Si vous êtes un client existant et que vous avez zbooté votre instance, ou un nouveau client, vous pouvez créer des demandes de changement basées sur des modèles par défaut. Toutefois, vous pouvez créer des demandes de changement basées sur le type en définissant la propriété de compatibilité de type sur true.

Le tableau suivant explique comment la fonctionnalité de modèle de changement fonctionne pour les nouveaux clients et les clients de mise à niveau.

Tableau 3. Comportement du modèle de changement en fonction de la mise à niveau
Instance nouvelle ou mise à niveau	Marqueur de compatibilité type	Modèle ou type	Flux de transitions d’états	Flux d’approbation de changement automatique	Rappel à un tiers
zboot (zbooted nouveau ou existant)	Faux	Modèle DevOps	Demande de changement - DevOps - Nouveau Demande de changement - DevOps - Évaluer Demande de changement - DevOps - Autoriser Demande de changement - DevOps - Calendrier Demande de changement : DevOps : implémenter	Dans le système de base, l’approbation des changements (automatique ou manuelle) se fait via le flux Demande de changement - DevOps - Évaluer. Si vous souhaitez un autre niveau d’approbation, vous pouvez vous référer au flux Demande de changement - DevOps - Autoriser et personnaliser la politique de changement de modèle DevOps en conséquence.	Voir la note dans la section Rappel.
Mise à niveau	Faux	Modèle DevOps	Demande de changement - DevOps - Nouveau Demande de changement - DevOps - Évaluer Demande de changement - DevOps - Autoriser Demande de changement - DevOps - Calendrier Demande de changement : DevOps : implémenter	Dans le système de base, l’approbation des changements (automatique ou manuelle) se fait via le flux Demande de changement - DevOps - Évaluer. Si vous souhaitez un autre niveau d’approbation, vous pouvez vous référer au flux Demande de changement - DevOps - Autoriser et personnaliser la politique de changement de modèle DevOps en conséquence.	Voir la note dans la section Rappel.
zboot (zbooted nouveau ou existant)	Faux	Modèle simplifié DevOps	Demande de changement - DevOps - Nouveau Demande de changement - DevOps - Autoriser Demande de changement - DevOps - Calendrier Demande de changement : DevOps : implémenter	Dans le système de base, l’approbation des changements (automatique ou manuelle) se fait via le flux Demande de changement - DevOps - Autoriser. Si vous souhaitez un autre niveau d’approbation, vous pouvez personnaliser la politique de changement de modèle simplifié DevOps en conséquence.	Voir la note dans la section Rappel.
Mise à niveau	Faux	Modèle simplifié DevOps	Demande de changement - DevOps - Nouveau Demande de changement - DevOps - Évaluer Demande de changement - DevOps - Autoriser Demande de changement - DevOps - Calendrier Demande de changement : DevOps : implémenter	Dans le système de base, l’approbation des changements (automatique ou manuelle) se fait via le flux Demande de changement - DevOps - Autoriser. Si vous souhaitez un autre niveau d’approbation, vous pouvez personnaliser la politique de changement de modèle simplifié DevOps en conséquence.	Voir la note dans la section Rappel.
Mise à niveau	vrai	Type	Le comportement actuel se poursuit	Approbation manuelle de demande de changement DevOps, approbation d’automatisation minimale de demande de changement DevOps ou flux d’approbation d’automatisation avancée de demande de changement DevOps (quel que soit le flux actif)	Flux de rappel de contrôle des changements