Conseils de déploiement de la production

  • Rversion finale: Xanadu
  • Mis à jour 1 août 2024
  • 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 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 celle d’un référentiel Git avec contrôle de 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 source. Cela peut avoir des conséquences inattendues.

    Glossaire

    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 une application. 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 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é. Le travail est souvent effectué dans ce champ d’application pour personnaliser les applications ServiceNow existantes telles que Gestion des services IT (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 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 en vue d’un 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 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.
    Restauration 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 à partir 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 pour les métadonnées en visitant 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 voir 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 au 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 un contrôle de source, il facilite le développement continu d’une application personnalisée. Par conséquent, l’application est gérée en tant qu’application « en développement » dans la table Application personnalisée [sys_app] plutôt qu’en tant qu’application « installée » dans la table Application du magasin [sys_store_app]. Les deux tables sont des extensions de sys_scope de sorte qu’elles offrent toutes les deux 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 tout en déployant cette même application à partir de 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 de sys_app doit d’abord être converti en enregistrement sys_store_app. Vous pouvez contacter le support ServiceNow pour obtenir de l’aide afin d’effectuer cette opération.

    Chargement delta

    Avant la version Paris, l’installation ServiceNow d’applications à 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 désormais 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 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 la suppression et de la réinstallation de l’application. Les applications globales dans 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 (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 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 Confit
    Remarque :
    • Bien que le schéma de base de données et les données soient conservés, ils sont 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 conservés, ils seront déplacés dans l’application globale qui revendiquait précédemment ces fichiers s’ils étaient installés. Dans le cas contraire, 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 abandonnées.

    Lorsque vous commutez des 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 les é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 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 doivent avoir une charge utile DELETE explicite pour supprimer un fichier ou déposer un schéma.

    Si des fichiers d’application sont générés dynamiquement d’une manière ou d’une autre, la prochaine installation/application distante 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 modifications locales, 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 d’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.