Déplacement d’applications entre les instances

  • Rversion finale: Australia
  • Mis à jour 12 mars 2026
  • 1 minute de lecture

    • ServiceNow les applications sont créées dans des instances de développement, puis promues dans des environnements de test et de production à l’aide d’ensembles de mises à jour ou pour Référentiel d'applications empaqueter et migrer les changements. Grâce à ce workflow multi-instances, les applications sont testées de manière approfondie avant d’atteindre les utilisateurs finaux en production.

    Types d'instances

    Les environnements de développement suivent généralement une architecture multi-instances. Chaque instance a un objectif distinct dans le cycle de vie de l’application.
    • Développement (DEV) : créez et itérez des applications.
    • Test/QA (TEST) : validez et testez les changements.
    • Étape intermédiaire/UAT (ÉTAPE) : validez et testez les changements.
    • Production (PROD) : environnement opérationnel qui alimente les opérations commerciales quotidiennes.

    Principe fondamental

    Le principe de base est simple : ne jamais développer directement en production. Tous les changements de configuration et de code proviennent de DEV, passent par une ou plusieurs étapes de validation hors production et n’arrivent dans PROD qu’après avoir réussi des contrôles qualité, notamment des tests automatisés, des vérifications d’instance Instance Scan et des approbations des personnes concernées.

    Lors du déplacement d’une application, tous les artefacts associés à ce périmètre de l’application (règles métier, includes de script, pages d’interface utilisateur, ACL, tables, flux, etc.) doivent voyager ensemble en tant qu’unité cohérente. Les déploiements partiels créent des incohérences de versions et constituent une source majeure d’incidents de production.

    Considérations de sécurité pour le mouvement d’instance

    Isolement des informations d’identification
    Les informations d’identification d’intégration, les clés API et les jetons OAuth ne doivent jamais être promus du développement à la production. Utilisez les propriétés système marquées comme banques d’identifiants privées ou spécifiques à un environnement.
    Validation ACL
    Exécutez Analyse d'instance sur chaque déploiement pour vérifier que les ACL respectent les principes du moindre privilège. Les ACL vides ou trop permissives constituent une faille de sécurité courante.
    Séparation des rôles
    Les développeurs ne doivent pas avoir d’accès administrateur en production. Utilisez des comptes de service de déploiement dédiés disposant uniquement des rôles nécessaires pour installer des applications.
    Protection des données
    Confirmez que les données de test en non-production ne contiennent pas d’Informations personnellement identifiables (IPI) de production non masquées. Utilisez le masquage ou l’anonymisation des données pendant les opérations de clonage.