Directives d’utilisation du contrôle de source

  • Rversion finale: Australia
  • Mis à jour 12 mars 2026
  • 3 minutes de lecture

    • Le contrôle de source (Git) associé à la est la méthode de déploiement préférée pour les applications personnalisées incluses dans le Référentiel d'applications périmètre. L’utilisation Ensembles de mises à jour système est également un mécanisme de déploiement approuvé pour le développement d’applications.

    Pourquoi utiliser le contrôle de source ?

    Historique complet des changements
    Git fournit un enregistrement complet et vérifiable de chaque changement, comme qui l’a effectué, quand et pourquoi, avec la possibilité d’utiliser les fonctions diff, review et revert au niveau du fichier individuel.
    Branchement et développement parallèle
    Plusieurs développeurs peuvent travailler simultanément sur différentes fonctionnalités sans conflits d’ensembles de mises à jour.
    Workflows de revue de code
    Les demandes d’extraction et les révisions de fusion imposent l’examen par les pairs avant la publication de tout changement, ce qui réduit les erreurs et les oublis de sécurité.
    Versions avec version
    Les balises et les branches sont mappées directement aux Référentiel d'applications versions, ce qui permet des restaurations fiables et des workflows de correctifs.
    Intégration CI/CD
    Les outils CI/CD externes tels que Jenkins, GitHub Actions et Azure DevOps peuvent déclencher des versions, des tests et des déploiements à l’aide du ServiceNow SDK et CLI.

    Quand sont-ils Ensembles de mises à jour système appropriés ?

    Ensembles de mises à jour système Conservez la valeur pour des changements opérationnels rapides des éléments suivants :
    • Configurations de portée globale.
    • Correctifs d’urgence lorsque le pipeline de contrôle de source complet introduisait un délai inacceptable.
    • Organisations qui sont encore en transition vers les pratiques de développement héritées.
    • Modifications apportées aux applications ou ServiceNow® Store modules d’extension dans lesquels le workflow ne s’applique Référentiel d'applications pas de manière native.
    Même dans ces scénarios, envisagez d’utiliser Analyse d'instance des vérifications avant Ensembles de mises à jour système de les valider et des ensembles de mises à jour liés aux lots pour réduire la complexité du déploiement.

    Consignes de sécurité

    Appliquer le moindre privilège via les listes de contrôle d’accès (ACL)
    Définissez des rôles spécifiques aux applications personnalisées plutôt que de vous fier à des rôles système généraux. Configurez les ACL pour utiliser d’abord l’ordre d’évaluation des rôles, puis les conditions, puis les scripts pour des performances et une sécurité optimales.
    Utiliser refuser par défaut
    La propriété glide.sm.default_mode doit rester en mode Refuser afin que les ACL génériques restreignent l’accès à l’administrateur uniquement par défaut.
    Exécuter automatiquement Instance Scan
    Configurer Analyse d'instance pour s’exécuter sur Ensembles de mises à jour système et déploiements d’applications. Cela détecte les ACL vides, les accès trop permissifs et les violations des normes de codage avant qu’ils n’atteignent la production.
    Protéger l’accès entre périmètres
    Configurez délibérément les privilèges d’accès entre périmètres des applications. Par défaut, l’accès n’est pas ouvert pour tous les champs d’application.
    Mettre en œuvre l’authentification multifacteur et les restrictions IP
    Tous les comptes interactifs effectuant des déploiements doivent utiliser l’authentification multifacteur. Les comptes de service pour les déploiements automatisés doivent être restreints par plage d’adresses IP et avoir des rôles étroitement limités.
    Tout auditer
    Utilisez l’analyseur d’accès pour examiner régulièrement les autorisations d’utilisateur, de groupe et de rôle. Transférez les journaux de déploiement et l’activité de contrôle d’accès à votre plateforme SIEM pour surveillance.
    Séparer les données du code
    Les enregistrements de données d’application ne sont pas inclus dans les Référentiel d'applications déploiements. Gérez les données de référence et les données d’amorçage par le biais de processus distincts et contrôlés avec une classification appropriée des données.

    Matrice de décision de méthode de déploiement

    Le tableau suivant présente le scénario et l’approche de déploiement recommandée :

    Tableau 1. Approche de méthode de déploiement
    Scénario Approche recommandée
    Nouvelle application personnalisée incluse dans le périmètre Utiliser le contrôle de source + Référentiel d'applicationsApp Engine Management Center Pipelines et déploiements+ , ou ReleaseOps.
    Changements de configuration du champ d’application global À utiliser Ensembles de mises à jour système avec Analyse d'instance ou application globale utilisant le fichier Référentiel d'applications.
    Correctif d’urgence en production À utiliser Ensembles de mises à jour système pour la vitesse et le port arrière dans le contrôle de source (Git) immédiatement après.
    Application développeur no-code low-code à partir de App Engine Studio À utiliser App Engine Management Center Pipelines et déploiements avec un workflow d’approbation guidée.
    Coordination des mises en production multi-équipes : À utiliser ReleaseOps avec les trains de mise en production et playbook la validation.