Conseils de déploiement en production

  • Rversion finale: Washingtondc
  • Mis à jour 1 févr. 2024
  • 6 minutes de lecture

    • Lorsque vous développez des personnalisations sur des applications sur la ServiceNow® plateforme, vous les déployez via le référentiel d’applications sur une instance de production. Cette rubrique examine et fournit des mises en garde sur 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 code source.

    Vue d'ensemble

    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 code source. Cela peut avoir des conséquences inattendues.

    Glossaire des termes

    Terme Définition
    Métadonnées ou fichiers d’application Les enregistrements sys_metadata qui définissent la configuration dans ServiceNow une application et qui sont empaquetés dans celle-ci. Ces enregistrements modifient le comportement de l’instance, mais ne contiennent pas de données telles que des enregistrements d’incident ou CMDB. (Voir la note ci-dessous)
    Applications incluses dans le périmètre Applications ServiceNow qui restreignent l’autorisation de mises à jour et d’opérations uniquement dans les limites du périmètre. 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é. Le travail est souvent effectué dans ce champ d’application 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 ait des 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 magasin, 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. Ils contiennent la collection incrémentielle d’insertions, de mises à jour et de suppressions.
    Chargement delta Il s’agit de la méthode de chargement la plus efficace, car elle ne change qu’à partir du contrôle de code 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 parente de tous les fichiers d’application de la ServiceNow plateforme utilisant le modèle d’héritage de table. Vous pouvez afficher des informations récapitulatives relatives aux métadonnées en consultant la table parente ou les tables 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 afficher l’ensemble du schéma en consultant 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 son rendu prend donc un certain temps.

    Mappage de schéma

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

    Emplacement d’installation

    Lorsque vous installez le contrôle de code 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 qu’une application « installée » dans la table Application de stockage [sys_store_app]. Les deux tables sont des extensions de sys_scope de sorte qu’elles fournissent les mêmes protections et restrictions que le périmètre. Ainsi, lorsque vous recherchez l’installation d’une application de contrôle de code source déployée, 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 d’enregistrement sys_app sur l’instance tout en déployant 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 de sys_app doit d’abord être converti en enregistrement de sys_store_app. Vous pouvez contacter le support ServiceNow pour obtenir de l’aide pour effectuer cette opération.

    Chargement delta

    Avant la ServiceNow version Paris, l’installation de l’application à partir du contrôle de code 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 à distance. 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, sauf si elles ont é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 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 d'application Source d’installation Schéma présent dans le package Le schéma contient des données Réclamation par une autre application (global) 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 Conservés
    Inclus dans l'étendue Référentiel ou magasin d’applications Non Oui/Non N/A Conservés
    Inclus dans l'étendue Contrôle de source Oui Oui/Non N/A Conservés
    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 Conservés
    Non Oui Non Préservé (1)
    Non Non Oui Préservé (2)
    Contrôle de source Non Non Non Supprimé (3)
    Référentiel d’applications Non Non Non Conservés
    Remarque :
    1 : 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.
    Remarque :
    2 : 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 qui détenait auparavant la revendication de ces fichiers s’ils étaient installés. Sinon, ils passeront à l’application globale par défaut.
    Remarque :
    3 : applicable uniquement aux colonnes personnalisées avec u_ préfixe. Les colonnes créées par la plateforme ServiceNow ne sont pas supprimées.

    Lors du basculement de branches dans le contrôle de code 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 ainsi toutes les données qu’il contient. (Les applications globales n’abandonnent pas le schéma lorsque des données sont présentes.)

    Comme pour les ensembles de mises à jour, seul un sous-ensemble de changements incrémentiels doit être appliqué avec le chargement Delta. Contrairement aux ensembles de mises à jour, le package d’application représente l’application complète. Les fichiers qui sont 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 d’applications doivent avoir une charge utile DELETE explicite pour supprimer un fichier ou supprimer un schéma.

    Si les fichiers d’application sont générés dynamiquement d’une manière ou d’une autre, la prochaine installation/application à distance modifie le fonctionnement d’une application et supprime 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 modifications, elles ne sont pas récupérées.
    Remarque :
    La suppression ou la suppression des enregistrements sys_update_xml empêche leur suppression par le chargement Delta ; Cependant, cette action peut avoir d’autres résultats graves ou indésirables.

    Les modifications directes vers le 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 soin.