Conseils pour le déploiement de la production

  • Rversion finale: Yokohama
  • Mis à jour 30 janv. 2025
  • 6 minutes de lecture

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

    Vue d’ensemble ou déploiement en production

    Techniquement, vous pouvez toujours « déployer » une application 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 des termes

    Terme Définition
    Métadonnées ou fichiers d’application Les enregistrements sys_metadata qui définissent la configuration et sont packagés dans ServiceNow une application. Ces enregistrements modifient le comportement de l’instance, mais ne contiennent pas de données telles que les enregistrements d’incident ou de CMDB. (Voir la note ci-dessous)
    Applications incluses dans le périmètre Applications ServiceNow qui restreignent l’autorisation uniquement des mises à jour et des 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 périmètre global hérité. Ce travail est souvent effectué dans ce périmètre pour personnaliser les applications ServiceNow existantes, telles que IT Service Management (ITSM).
    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 (fournisseurs) ainsi que pour les applications publiées par ServiceNow. La plupart des clients ne publient pas sur le Store, mais installent souvent des applications à partir de celui-ci.
    Ensembles de mises à jour Méthode standard d’empaquetage des personnalisations pour le déploiement dans chaque instance successive. Elles contiennent la collection incrémentielle des insertions, des mises à jour et des suppressions.
    Chargement delta La méthode de chargement la plus efficace car elle ne change que le contrôle de source plutôt que les 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 parente de tous les fichiers d’application de la plateforme à l’aide ServiceNow du modèle d’héritage de table. Vous pouvez afficher des informations récapitulatives pour les métadonnées en visitant la ou les tables parentes qui s’étendent directement ou indirectement, comme l’indique le champ Étend la table (super_class) de l’enregistrement de table(sys_db_object). Vous pouvez également afficher le schéma complet en visitant le formulaire Table(sys_db_object) pour la table sys_metadata et en sélectionnant le lien connexe Afficher la carte de schéma en bas du formulaire. Le schéma est volumineux et prend donc un certain temps à s’afficher.

    Mappage de schéma

    Table des matières de la carte de schéma

    Emplacement d’installation

    Lorsque vous installez le contrôle de source, il 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 de stockage [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 avoir 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, à un moment donné, le modèle de déploiement change, l’enregistrement sys_app doit d’abord être converti en enregistrement sys_store_app. Vous pouvez contacter le support ServiceNow pour obtenir de l’aide sur l’exécution de cette opération.

    Chargement delta

    Avant la ServiceNow version Paris, l’installation de l’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 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 conserve les données des tables et des champs qui continuaient d’être 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 suppression et de réinstallation de l’application. Les applications globales à 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 de demande 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
    Inclus dans l'étendue Référentiel ou magasin d’applications Oui Oui/Non N/A Confit
    Inclus dans l'étendue Référentiel ou magasin d’applications Non Oui/Non N/A Confit
    Inclus dans l'étendue Contrôle de source Oui Oui/Non N/A Confit
    Inclus dans l'étendue 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 Confit
    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 Confit
    Remarque :
    • Bien que le schéma de base de données et les données soient conservés, ils seront déplacés dans 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 dans l’application globale qui revendiquait auparavant ces fichiers s’ils étaient installés. 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 abandonné, 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 mis à niveau à partir du référentiel d’applications ou ServiceNow du magasin 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 de la trousse de demande entrante. Si vous dissimulez des changements locaux, les fichiers d’application peuvent être récupérés par une validation 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 de sys_update_xml enregistrements empêche qu’ils ne soient supprimés par le chargement Delta ; cependant, cette action peut avoir d’autres conséquences graves ou indésirables.

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