Préserver les applications et les personnalisations en cours de développement lors d’un clone système

  • Rversion finale: Xanadu
  • Mis à jour 1 août 2024
  • 4 minutes de lecture
  • Conservez manuellement une copie de chaque application et personnalisation que vous avez actuellement en développement avant de pouvoir cloner la version de l’application sur l’instance cible (de développement).

    Avant de commencer

    Assurez-vous d’avoir un accès en écriture à l’enregistrement d’application.

    Assurez-vous d’avoir accès à un référentiel de contrôle de source.

    Rôle requis : administrateur

    Pourquoi et quand exécuter cette tâche

    Le processus de clonage ne conserve pas les différences de version pour les applications et les personnalisations d’application en cours de développement. Au lieu de cela, le système clone uniquement les copies des versions d’application et de personnalisation d’application installées sur l’instance source sur l’instance cible. Si l’instance cible dispose d’une version de développement de la même application, l’application est modifiable après le clone, mais se trouve à la version qui a été installée sur l’instance source. Si l’application était manquante dans l’instance source, le processus de clonage supprime l’application de l’instance cible.

    Procédure

    1. Pour conserver l’application sur l’instance cible du clone, effectuez l’une des actions suivantes :
      Tableau 1. Différences de version entre les instances
      État de la version d’application Mesure à prendre
      La version de l’application sur l’instance cible du clone est différente de la version de l’instance source. Exportez chaque application à partir de l’instance cible du clone. Les choix sont les suivants :
      • En la liant à un référentiel de contrôle de source.
        Remarque :
        Si l’application est déjà liée à un référentiel de contrôle de source, validez la dernière version de celui-ci.
      • Publier chaque application dans un ensemble de mises à jour.
      L’application n’est disponible que sur l’instance cible du clone.
      La version de l’application sur l’instance cible du clone est la même que l’instance source. Aucun. Le processus de clone système copie cette version d’application sur l’instance cible au cours du clone.
    2. Demandez un clone système de l’instance source vers l’instance cible.
      Par exemple, clonez votre instance de production sur votre instance de développement.
    3. Une fois le processus de clonage terminé, connectez-vous à l’instance cible du clone.
    4. Remarque :
      Si le contrôle de source est lié, puis post-clone, la plateforme récupère automatiquement les applications et les applications personnalisées. Si cette option est désactivée via glide.source_control.post_clone_import_enabled , vous devrez effectuer une récupération manuelle en procédant comme suit.
      Si vous avez enregistré chaque application dans un référentiel de contrôle de source, utilisez l’une des actions suivantes pour les récupérer à partir du référentiel de contrôle de source :
      Remarque :
      Pour savoir à quoi s’attendre après la personnalisation de l’application après clonage, consultez Résultats après clonage pour les personnalisations d’application.
      Tableau 2. Récupérer des applications à partir d’un référentiel de contrôle de source
      État d’installation de l’application Action à entreprendre sur la cible du clone
      L’application et la personnalisation ont été préalablement installées sur l’instance source. Appliquez les modifications à distance à partir du référentiel de contrôle de source.
      L’application n’a jamais été installée sur l’instance source. Supprimez la configuration du référentiel (sys_repo_config) et importez la personnalisation à partir du référentiel de contrôle de source.
      Tableau 3. Modifications à distance après clonage
      Champ Description
      glide.source_control.post_clone_import_enabled Pour désactiver l’automatisation de l’application des changements distants, définissez sur Faux. La valeur par défaut est True.
      glide.source_control.post_clone_import_delay_time_sec Pour fournir un délai qui retardera le traitement de la file d’attente, fournissez une valeur. La valeur par défaut est zéro.
      glide.source_control.post_clone_import_pause_refresh_time_sec Pour fournir un intervalle pendant lequel la tâche d’actualisation du référentiel ne s’exécutera pas, fournissez une valeur. La valeur par défaut est de trois heures (10800).
    5. Si vous avez enregistré chaque application dans un ensemble de mises à jour, effectuez l’une des actions suivantes pour les récupérer à partir de l’ensemble de mises à jour :
      Tableau 4. Récupérer des applications à partir d’un ensemble de mises à jour
      État d’installation de l’application Action à entreprendre sur la cible du clone
      L’application a été installée précédemment sur l’instance source.
      1. Supprimez la version d’application qui a été clonée à partir de l’instance source.
      2. Chargez l’ensemble de mises à jour qui contient la version actuelle de l’application.
      L’application n’a jamais été installée sur l’instance source. Chargez l’ensemble de mises à jour qui contient la version actuelle de l’application.

    Résultats

    Les applications précédemment en cours de développement sont disponibles pour un développement ultérieur sur l’instance cible du clone.

    Conserver l’application Événements marketing

    Supposons que votre entreprise ait précédemment créé la version 1.0 d’une application personnalisée appelée Événements marketing. Vous avez déjà publié la version 1.0 de l’application Événements marketing dans le référentiel d’applications et l’avez installée sur votre instance de production.

    Au fil du temps, des utilisateurs ont soumis des demandes d’amélioration de l’application, et vous décidez de développer la version 2.0 de l’application Événements marketing sur une instance de non-production pour répondre à ces demandes. Lorsque le développement touche à sa fin, vous souhaitez mettre à jour votre instance de non-production vers la dernière copie de production pour effectuer des tests complets.

    Étant donné que vous avez précédemment utilisé une intégration de contrôle de source pour développer la version 1.0 de l’application Événements marketing, vous avez déjà lié l’application Événements marketing à un référentiel de contrôle de source. Vous validez la version 2.0 de l’application Marketing Events dans le référentiel de contrôle de source.

    Vous planifiez un clone de l’instance de production sur l’instance de développement. Une fois l’opération terminée, vous vous connectez à l’instance de développement et constatez qu’elle dispose de la version 1.0 de l’application Événements marketing, car il s’agit de la version installée sur l’instance source.

    Étant donné que l’application était déjà installée sur l’instance source, vous appliquez les modifications distantes à partir du référentiel de contrôle de source pour recevoir la dernière version de l’application. L’instance de développement dispose désormais de la version 2.0 de l’application Événements marketing et est disponible pour un développement et des tests ultérieurs.