Introduction aux ensembles de mises à jour

  • Rversion finale: Washingtondc
  • Mis à jour 1 févr. 2024
  • 6 minutes de lecture
  • Étant donné que les ensembles de mises à jour apportent des changements à une instance, examinez ces informations pour éviter les erreurs et les problèmes de performances. Apprenez à planifier le processus de mise à jour et à éviter les erreurs courantes.

    Quand utiliser les ensembles de mises à jour

    Option de déploiement Bon pour Considérations futures
    Ensembles de mises à jour Stockage des changements apportés à un système de base ou à une application installée.

    Stocker et appliquer une version particulière d’une application.

    Production d’un fichier pour l’exportation.

    Vous pouvez créer manuellement des ensembles de mises à jour pour stocker une version d’application particulière.

    Utilisez des ensembles de mises à jour pour déployer des correctifs ou des changements aux applications installées.

    Remarque :
    N’utilisez pas d’ensembles de mises à jour pour installer des applications. Utilisez plutôt le référentiel d’applications ou le pour installer des ServiceNow Store applications.
    Référentiel d'applications Installation et mise à jour des applications sur toutes les instances de l’entreprise.

    Gestion automatique des ensembles de mises à jour de l’application.

    Restreindre l’accès aux applications à la même société.

    Déploiement des applications terminées pour les utilisateurs finaux.

    Envisagez de télécharger une application sur le ServiceNow Store pour la partager avec d’autres utilisateurs.

    Permet l’installation et la mise à jour vers la dernière version de l’application uniquement.

    Utilisez des ensembles de mises à jour pour stocker les versions antérieures de l’application.

    Remarque :
    Si vous l’utilisez avec le développement d’équipe, publiez des applications uniquement à partir d’une instance parente.

    Planifier le processus de mise à jour

    Avant d’utiliser des ensembles de mises à jour, créez un processus standard pour déplacer les personnalisations d’une instance à l’autre à l’aide de cette liste de vérification :
    1. Vérifiez que les deux instances utilisent la même version. Les personnalisations peuvent ne pas fonctionner si elles reposent sur un code qui a changé entre les versions.
    2. Déterminez les changements à apporter dans un ensemble de mises à jour unique. Terminez vos ensembles de mises à jour à mesure que vous terminez des tâches de petite à moyenne taille. Au fur et à mesure que les ensembles de mises à jour prennent de l’ampleur, il devient plus difficile de les examiner, d’identifier les changements qu’ils contiennent, d’augmenter le risque de conflits avec d’autres ensembles de mises à jour et de prendre plus de temps pour les prévisualiser et les valider. Cela est particulièrement vrai si les ensembles de mises à jour contiennent des modifications de schéma ou des révisions de workflows volumineux ou si l’ensemble doit être retiré.
    3. Vérifiez que tous les enregistrements du système de base ont des champs sys_id correspondants. Certains enregistrements de système de base sont créés sur une instance après la mise en service et ne correspondent pas entre les différentes instances, ce qui entraîne des problèmes avec les ensembles de mises à jour. La meilleure façon d’éviter ce problème est de :
      • Mettre en service des instances de production et de non-production.
      • Clonez l’instance de production sur l’instance de non-production.
    4. Identifiez un chemin commun pour que les ensembles de mises à jour se déplacent d’une instance à l’autre et maintiennent ce modèle. Ne migrez jamais le même ensemble de mises à jour à partir de plusieurs sources. Déplacez les ensembles de mises à jour de développement vers test, puis de test vers production.
    5. Planifiez le moment de la validation des ensembles de mises à jour en production. Évitez de valider un ensemble de mises à jour sur une instance de production pendant les heures ouvrables. L’instance peut fonctionner plus lentement pendant que l’ensemble de mises à jour s’applique. Rassurez-vous, ce ralentissement des performances est temporaire.
    6. Assurez-vous que les noms des ensembles de mises à jour sont clairs. Créez une convention d’affectation de noms pour coordonner les changements de plusieurs développeurs et les référencer lors de la validation des changements dans une autre instance.
      • Si des ensembles de mises à jour sont générés en tant que correctifs pour les problèmes, envisagez d’inclure le ticket de problème dans le nom (par exemple, PR10005 - Correctif des problèmes de messagerie en double).
      • Si vous avez besoin de plusieurs ensembles de mises à jour pour résoudre un problème, incluez un numéro de séquence dans la convention de dénomination. Cela permet de s’assurer que les ensembles de mises à jour sont appliqués dans l’ordre dans lequel ils ont été créés (par exemple, PR10005 - Correctif des problèmes d’e-mail en double et PR10005.2 - Correctif des problèmes d’e-mail en double).
    7. Découvrez les points suivants concernant les ensembles de mises à jour :
      • Quels enregistrements sont générés.
      • Quelles personnalisations sont suivies ?
      • Quels changements de dictionnaire sont valides ?
      • Quelles personnalisations peuvent être retirées (inversées) après l’application ?
    8. Avant d’effectuer des personnalisations, vérifiez que l’ensemble de mises à jour approprié est sélectionné.

    Utilisation d’ensembles de mises à jour

    Passez en revue ces informations pour éviter les erreurs et les problèmes de performances.
    • Ne supprimez pas d’ensembles de mises à jour. Si un ensemble de mises à jour est supprimé, tous les enregistrements mis à jour peuvent être remplacés lors de la prochaine mise à jour.
    • N’incluez pas le champ system_id de l’enregistrement ldap_server_config dans un ensemble de mises à jour. Un ensemble de mises à jour provenant d’une configuration de travail pointe vers le mauvais nœud system_id pour l’instance cible et ne fonctionne pas.
    • Ne pas annuler l’ensemble de mises à jour par défaut. Cette action endommage le système.
    • Ne modifiez jamais la valeur du champ Ensemble de mises à jour (update_set) dans un enregistrement de mise à jour du client (sys_update_xml). Si une personnalisation est effectuée dans le mauvais ensemble de mises à jour, effectuez l’action suivante :
      1. Basculez vers l’ensemble de mises à jour souhaité.
      2. Modifiez l’objet (enregistrement) qui a été modifié à l’origine. Vous pouvez effectuer une modification anodine, comme l’ajout d’un champ.
      3. Enregistrez l'enregistrement.
      4. Annulez le changement que vous venez d’effectuer, puis enregistrez à nouveau l’enregistrement.

        Cette action garantit que la dernière version de l’objet est incluse dans l’ensemble de mises à jour souhaité et empêche les mises à jour en double pour le même objet dans un ensemble de mises à jour unique.

    • Ne marquez pas un ensemble de mises à jour comme terminé tant qu’il n’est pas prêt à migrer. Une fois qu’un ensemble de mises à jour est terminé, ne le redéfinissez pas sur En cours. Créez plutôt un autre ensemble de mises à jour pour le reste des changements et assurez-vous de les valider ensemble dans l’ordre dans lequel ils ont été créés. Les conventions de dénomination peuvent être utiles dans ce cas (par exemple, Améliorations des performances et Améliorations des performances 2).
    • Ne fusionnez pas manuellement les mises à jour dans un ensemble de mises à jour. Utilisez le module Fusionner les ensembles de mises à jour. Cet outil compare les fichiers en double entre les ensembles de mises à jour et sélectionne la version la plus récente.
    • Si un ensemble de mises à jour validé rencontre un problème dans l’instance de test, créez le correctif dans un autre ensemble de mises à jour dans l’instance de développement. Validez cet ensemble dans l’instance de test, puis assurez-vous que les deux ensembles sont migrés vers l’instance de production et validés dans l’ordre dans lequel ils ont été créés.
    • Prévisualisez toujours un ensemble de mises à jour avant de le valider.
    • Définissez l’ensemble de mises à jour terminé sur l’instance de production sur Ignorer. Cet état garantit que l’ensemble de mises à jour n’est pas réappliqué lors du clonage de l’instance.
    • Conservez une liste des tâches de modification manuelle et des chargements de données qui doivent être effectués après l’application d’un ensemble de mises à jour.
    • N’apportez pas trop de modifications à la fois. Vérifiez que les changements corrects ont été apportés de manière incrémentielle.
    • Vous ne pouvez pas modifier une seule mise à jour afin qu’elle soit mise à jour dans plusieurs domaines (c’est-à-dire les domaines globaux et TOP). Cette fonction n’est pas prise en charge dans .Now Platform