Legacy - Conseils pour le déploiement de la production

  • Rversion finale: Zurich
  • Mis à jour 31 juil. 2025
  • 6 minutes de lecture

    • Lorsque vous développez des personnalisations d’applications sur la ServiceNow® plateforme, vous les déployez via le référentiel d’applications dans une instance de production. Cette rubrique examine et met en garde contre les compromis à effectuer entre l’installation d’une application à partir du référentiel d’applications et celle d’un référentiel Git avec contrôle de source.

    Important :
    À partir de la Xanadu mise en production, la legacy version de est en cours de ServiceNow Studio préparation pour une éventuelle dépréciation. Ce module d'extension sera masqué et ne sera plus activé sur les nouvelles instances, mais continuera d'être pris en charge. Pour en savoir plus sur le processus de dépréciation, consultez l’article Processus de dépréciation [KB0867184] dans la base de connaissances Now Support.

    Essayez plutôt de créer et de modifier des applications dans la version actuelle de ServiceNow Studio Pour plus d'informations, consultez ServiceNow Studio.

    Vue d’ensemble ou déploiement en production

    Techniquement, vous pouvez toujours « déployer » une application à partir d’un référentiel Git vers une instance de production à l’aide du contrôle de source. Cela peut avoir des conséquences imprévues.

    Glossaire

    Terme Définition
    Métadonnées ou fichiers d’application Les enregistrements sys_metadata qui définissent la configuration et sont empaquetés dans ServiceNow une application. Ces enregistrements modifient le comportement de l’instance, mais ne contiennent pas de données telles que des enregistrements d’incidents ou de CMDB. (Voir la note ci-dessous)
    Applications incluses dans le périmètre Applications ServiceNow qui restreignent n’autorisant que les mises à jour et les opérations dans les limites du champ d’application. Ce mécanisme est utilisé pour la plupart des nouveaux développements.
    Applications globales Les applications globales sont développées dans le champ d’application global hérité. Dans ce périmètre, on travaille souvent à la personnalisation d’applications ServiceNow existantes, telles que IT Service Management (ITSM, Gestion des services IT).
    Référentiel d’applications Les applications sont généralement publiées ici pour être déployées dans des instances de production. Bien que le référentiel d’applications dispose de règles d’autorisation distinctes, il fonctionne de la même manière que le ServiceNow Store.
    ServiceNow Store Référentiel pour les applications tierces (fournisseur) ainsi que pour les applications publiées par ServiceNow. La plupart des clients ne publient pas dans le Store, mais installent souvent des applications à partir de celui-ci.
    Ensembles de mises à jour Méthode standard d’empaquetage des personnalisations pour déploiement dans chaque instance successive. Ils contiennent la collection incrémentielle d’insertions, de mises à jour et de suppressions.
    Legacy - Chargement delta La méthode de chargement la plus efficace car elle change uniquement à partir du contrôle de source plutôt que des méthodes de désinstallation/réinstallation antérieures.
    Schéma Définition des tables et des colonnes dans les tables.
    Restaurer Les administrateurs peuvent restaurer la dernière installation d’une application sélectionnée. Une restauration supprime toutes les mises à jour de code, de table et de fichier de l’installation initiale.
    Remarque :
    La table sys_metadata est la table parent de tous les fichiers d’application de la plateforme qui utilisent ServiceNow le modèle d’héritage de table. Vous pouvez afficher les informations récapitulatives pour les métadonnées en consultant la ou les tables parentes qui s’étendent directement ou indirectement, comme indiqué par le champ Étend la table(super_class) sur l’enregistrement Table(sys_db_object). Vous pouvez également voir le schéma complet en accédant au formulaire Table(sys_db_object) de la table sys_metadata et en sélectionnant le lien connexe Show Schema Map (Afficher la carte de schéma ) en bas du formulaire. Le schéma est volumineux et prend donc un certain temps à afficher.

    Mappage de schéma

    Sommaire de la carte de schéma

    Emplacement d’installation

    L’installation d’un contrôle de code source facilite le développement continu d’une application personnalisée. Par conséquent, l’application est gérée comme une application « en développement » dans la table Application personnalisée [sys_app] plutôt que comme une application « installée » dans la table Application du magasin [sys_store_app]. Les deux tables sont des extensions de sys_scope elles offrent donc les mêmes protections et restrictions que le champ d’application. Ainsi, lorsque vous recherchez l’installation d’une application déployée de contrôle de source, reportez-vous à la table Application système [sys_app] et à la section En développement de la page Gestionnaire d’applications.

    Vous ne pouvez pas disposer d’un enregistrement sys_app sur l’instance lors du déploiement de cette même application à partir du ServiceNow Store ou du référentiel d’applications. Les deux modèles de déploiement s’excluent mutuellement. Si, à tout moment, le modèle de déploiement change, l’enregistrement sys_app doit d’abord être converti en enregistrement sys_store_app. Vous pouvez contacter l’assistance ServiceNow pour obtenir de l’aide sur l’exécution de cette opération.

    Chargement delta

    Avant la version Paris, l’installation ServiceNow d’application à partir du contrôle de source supprimait et réinstallait toujours l’intégralité de l’application lorsqu’elle était déclenchée, y compris la fonction Appliquer les modifications distantes. Avec Legacy - Chargement delta, seuls les changements sont mis à jour, ce qui simplifie considérablement le processus.

    Le processus de chargement Delta charge les changements à partir du contrôle de source de façon incrémentielle. Lorsque vous appliquez des modifications distantes, vous ne supprimez pas les tables ou colonnes existantes à moins qu’elles n’aient été supprimées du référentiel. Cela préserve les données des tables et des champs qui étaient toujours présents.
    Remarque :
    La propriété glide.source_control.allow_delta_loading_in_scopedapp vous permet de désactiver le chargement Delta dans Paris ; cependant, cela reviendra au comportement plus destructeur de la suppression et de la réinstallation de l’application. Les applications mondiales à Paris utilisent toujours le chargement Delta.
    Vous trouverez ci-dessous un tableau des différents résultats attendus dans une instance utilisant le chargement Delta.
    Type d'application Source de l’installation Schéma présent dans le package Le schéma contient des données Réclamation par une autre application (globale) Résultat attendu pour les données et le schéma
    Dans le périmètre Référentiel ou magasin d’applications Oui Oui/Non N/A Conservé
    Dans le périmètre Référentiel ou magasin d’applications Non Oui/Non N/A Conservé
    Dans le périmètre Contrôle de source Oui Oui/Non N/A Conservé
    Dans le périmètre Contrôle de source Non Oui/Non N/A Supprimé
    Global Contrôle de source, référentiel d’applications ou magasin Oui Oui/Non Oui/Non Conservé
    Non Oui Non Conservé (1)
    Non Non Oui Conservé (2)
    Contrôle de source Non Non Non Supprimé (3)
    Référentiel d’applications Non Non Non Conservé
    Remarque :
    • Le schéma de base de données et les données seront conservés, mais ils seront déplacés vers l’application globale par défaut.
    • Bien que le schéma de base de données et les données soient préservés, ils seront déplacés vers l’application globale qui réclamait auparavant ces fichiers si elle était installée. Sinon, ils passeront à l’application globale par défaut.
    • Applicable uniquement sur les colonnes personnalisées avec u_ préfixe. Les colonnes créées par la plateforme ServiceNow ne sont pas supprimées.

    Lorsque vous changez de branche dans le contrôle de source pour une application incluse dans le périmètre, soyez extrêmement prudent dans un environnement de production. Si la branche cible n’a pas d’éléments de schéma trouvés dans la branche actuelle, le schéma connexe est supprimé, détruisant toutes les données qu’il contient. (Les applications globales n’abandonnent pas le schéma lorsque des données sont présentes.)

    Tout comme pour les ensembles de mises à jour, seul un sous-ensemble des changements incrémentiels doit être appliqué avec le chargement Delta. Contrairement aux ensembles de mises à jour, le package applicatif représente l’application complète. Les fichiers absents du nouveau package sont supprimés. Cela peut altérer les fonctionnalités et supprimer des données. Les ensembles de mises à jour et les applications mises à niveau à partir du référentiel d’applications ou ServiceNow du Store doivent avoir une charge utile DELETE explicite pour supprimer un fichier ou déposer un schéma.

    Si les fichiers d’application sont générés dynamiquement de quelque manière que ce soit, les changements d’installation/d’application distants suivants annulent l’opération d’une application et suppriment ces enregistrements. Ils sont considérés comme absents du dossier de candidature entrant. Si vous dissimulez des changements locaux, les fichiers d’application peuvent être récupérés par un commit de dissimulation, mais si des données sont perdues à la suite des changements, les données ne sont pas récupérées.
    Remarque :
    La suppression ou la suppression des enregistrements sys_update_xml empêche leur suppression par chargement Delta ; cependant, cette action peut avoir d’autres résultats graves ou indésirables.

    Les modifications directes apportées au référentiel, en particulier pour supprimer des fichiers, peuvent avoir des ramifications importantes, notamment la perte de données et des suppressions en cascade. Effectuez cette action avec précaution.