Utiliser AES avec un référentiel de contrôle de code source Git

  • Rversion finale: Washingtondc
  • Mis à jour 1 févr. 2024
  • 3 minutes de lecture
  • Les développeurs d’applications travaillant dans Studio du moteur de développement d'application (AES) peuvent gérer leur référentiel de données de nombreuses façons.

    Une fois que votre administrateur a lié une application au contrôle de source, tous les développeurs d’applications sur une instance de non-production peuvent effectuer les actions suivantes :
    • Importer des applications à partir d’un référentiel Git.
    • Extrayez et appliquez les modifications distantes à partir d’un référentiel Git.
    • Validez tous les changements locaux de l’instance dans un référentiel Git.
    • Créez des balises pour créer un lien permanent vers une version donnée d’une application.
    • Créez des branches pour gérer simultanément plusieurs versions d’une application.
    Remarque :
    Si vous utilisez le contrôle de source pour collaborer avec d’autres développeurs, seules les modifications qui ont été archivées sont disponibles pour les autres développeurs. Par exemple, si un administrateur crée un nouveau flux pour une application liée à Git, le nouveau flux ne sera pas disponible dans l’application pour les autres utilisateurs AES tant que l’administrateur n’aura pas vérifié le flux dans Git.

    Options disponibles à partir de Studio du moteur de développement d'application

    Une fois qu’une application a été liée au contrôle de source, les développeurs d’applications peuvent l’utiliser Studio du moteur de développement d'application pour gérer le référentiel. À partir de Studio du moteur de développement d'application, les développeurs peuvent :
    • Modifiez les informations d’identification du référentiel d’applications.
    • Validez tous les changements locaux sur l’instance.
    • Appliquez les modifications à distance à partir du référentiel.
    • Créez une branche.
    • Changez de branche.
    • Importer une application à partir d’un référentiel distant.

    L’intégration du contrôle de source ne prend pas en charge la gestion des applications sur une instance de production. Au lieu de cela, vous pouvez gérer les applications d’une instance de production à l’aide du référentiel d’applications, d’un ensemble de mises à jour ou Studio du moteur de développement d'application. Pour plus d’informations sur la gestion des applications sur une instance de production, consultez Partage d’applications.

    Options disponibles à partir d’un référentiel Git

    La ServiceNow plate-forme offre une prise en charge limitée de la modification des fichiers d’application liés en dehors d’une instance. À partir de Git, les développeurs peuvent :
    • Déplacez les fichiers d’application vers une autre structure de répertoire Git.
    • Modifier les fichiers d’application en dehors de Studio du moteur de développement d'application.

    Le système génère un fichier texte de propriétés appelé sn_source_control.properties au niveau racine du référentiel. Pour déplacer les fichiers d’application vers une autre structure de répertoire Git, les développeurs d’applications peuvent définir le path paramètre pour spécifier le chemin d’accès du sous-dossier contenant leurs fichiers d’application. Par exemple, si vous avez déplacé votre application dans le sous-dossier src/app , définissez la path valeur path=src/app.

    Le système génère un fichier checksum.txt dans le référentiel Git pour déterminer si des fichiers d’application ont été modifiés en dehors de Studio du moteur de développement d'application. Lorsque la valeur de la somme de contrôle du fichier correspond à la valeur de la somme de contrôle actuelle, l’intégration ignore le processus de validation et d’assainissement. Lorsque les valeurs de la somme de contrôle ne correspondent pas, l’intégration valide et nettoie les fichiers d’application dans le cadre de l’opération de contrôle de source. Le processus d’assainissement :
    • Crée des entrées de journal de mise à niveau pour chaque action de nettoyage effectuée.
    • Supprime les dossiers et fichiers non pris en charge du référentiel.
    • Abandonne toutes les opérations de contrôle de source lorsqu’un fichier d’application système échoue à la validation du schéma XML. Par exemple, si la validation du schéma XML d’un enregistrement de dictionnaire de base de données échoue, le système abandonne toutes les opérations.
    • Ignore l’opération de contrôle de source actuelle lorsqu’un fichier d’application non système échoue à la validation du schéma XML.

    L’intégration du contrôle de source nettoie uniquement le contenu figurant dans le chemin d’application répertorié dans le fichier sn_source_control.properties . Le contenu du référentiel en dehors du chemin d’accès de l’application est ignoré.

    Prise en charge du MID Server

    Utilisez un MID Server existant pour vous connecter à un référentiel de contrôle de source. L’accès à une application via un MID Server permet d’accéder aux référentiels derrière un pare-feu.