Migrer l’historique des ensembles de mises à jour terminés vers le contrôle de source

  • Rversion finale: Xanadu
  • Mis à jour 1 août 2024
  • 4 minutes de lecture
  • Lors de la liaison au contrôle de source, cette fonctionnalité permet aux développeurs d’applications de choisir de migrer les informations contenues dans les ensembles de mises à jour terminés vers l’historique du contrôle de source.

    Avant de migrer

    Assurez-vous que vous avez rempli ces critères avant d’essayer de migrer vos ensembles de mises à jour :
    Lorsque vous liez une application au contrôle de source, les ensembles de mises à jour et les enregistrements de mise à jour du client sont supprimés. Une fois que vous avez établi un lien vers le contrôle de source, si l’application possède des ensembles de mises à jour terminés, vous serez invité à faire un choix dans la boîte de dialogue ci-dessous.
    • Si vous sélectionnez « Oui, conserver l’historique des ensembles de mises à jour en tant que validations », l’historique des ensembles de mises à jour est conservé en tant que validations de contrôle de source.
    • Si vous sélectionnez « Non, ne pas conserver l’historique des ensembles de mises à jour en tant que validations », elles ne sont pas conservées en tant que validations.
    Quelle que soit l’option que vous sélectionnez, si vous sélectionnez Continuer, l’opération Lien vers le contrôle de source démarre et tous les ensembles de mises à jour terminés et tous les enregistrements de mise à jour du client sont supprimés. Si vous devez terminer des ensembles de mises à jour supplémentaires ou si vous choisissez de ne pas continuer, sélectionnez Annuler. Boîte de dialogue vous demandant de choisir votre historique d’ensemble de mises à jour

    Pour chaque ensemble de mises à jour terminé avec des mises à jour de l’application que vous liez au contrôle de source, des validations sont générées automatiquement par le système en fonction des enregistrements sys_update_xml dans les ensembles de mises à jour. Les validations sont classées selon l’horodatage sys_recorded_at . Pour les applications globales : tous les enregistrements de sys_update_xml qui appartiennent à l’application et font partie d’un ensemble de mises à jour global terminé sont capturés en tant que validations historiques.

    Lorsque l’opération Lien vers le contrôle de source est terminée, la validation la plus récente correspond à l’état actuel de votre application dans son intégralité. Vous pouvez afficher l’historique des commits dans votre référentiel Git ou en cliquant sur l’option de menu Contrôle de source et en sélectionnant Afficher l’historique. Les mises à jour sont séparées en plusieurs validations :
    • S’il existe des mises à jour pour un fichier qui sont dans le désordre entre les différents ensembles de mises à jour.
    • Si un jeu de mises à jour contient plusieurs enregistrements de mise à jour pour un seul fichier.

    Les validations d’un ensemble de mises à jour sont divisées en plusieurs validations ([Validation historique 1], [Validation historique 2]...) pour représenter chaque mise à jour. Ceci est fait pour que chaque fichier ait un historique ordonné des mises à jour.

    Avertissement :
    Toute validation préfixée par [Validation historique] est générée uniquement pour afficher son historique. N’essayez pas d’extraire ces validations au cours du processus de développement, car elles ne représentent pas nécessairement un instantané stable de l’application.

    Le dossier author_elective_update n’est pas créé avant la validation initiale. Cela signifie que lors de la validation initiale, vous pouvez voir des fichiers tels que des fichiers sys_choice être renommés et déplacés du dossier de mise à jour vers le dossier author_elective_update . Tous les fichiers supprimés des ensembles de mises à jour dans les validations historiques sont supprimés et ne sont pas déplacés vers le dossier author_elective_update comme ils le seraient pour les validations réelles. Au cours de la validation initiale, des charges utiles DELETE sont également créées pour tous les enregistrements de sys_update_xml DELETE qui ont été supprimés dans le cadre d’ensembles de mises à jour terminés.

    Exemple de message de validation :
    [Historical Commit 1] <Name of update set that this commit belongs to>
    Description: <Description of update set that this commit belongs to>
    Update Set was completed on / installed on <date>
    Update Set was completed by <sys_user user_name > <sys_user email>
    {
    Valeurs supplémentaires de sys_update_set enregistrement (voir la section Personnalisationci-dessous)
    }
    {

    Informations sur les ensembles de mises à jour par lots (voir la section Ensembles de mises à jour par lots ci-dessous) }

    Ensembles de mises à jour par lots

    Si un ensemble de mises à jour fait partie d’un ensemble de mises à jour par lots, ces informations sont ajoutées au message de validation au format suivant, le numéro le plus élevé étant la base de lots :

    {
    "1": {
    "parent": "<name of parent update set>",
    "description": "<description of parent update set>"
    },
    "2": {
    "parent": " <name of parent 1’s parent update set> ",
    "description": " <description of parent 1’s parent update set> "
    }
    }
    

    Personnalisation

    Vous pouvez ajouter des champs supplémentaires à inclure dans le message de validation en ajoutant une propriété glide.source_control.historical_commit_fields . La valeur est une liste de champs séparés par des virgules que l’utilisateur veut inclure dans sys_update_set champs XML. Les espaces et les noms de champs non valides ou mal orthographiés sont ignorés. Cette propriété est utilisée pour toutes les applications qui sont liées au contrôle de source à partir de l’instance si le validateur choisit de conserver l’historique des ensembles de mises à jour.

    Remarque :
    Si la valeur d’un champ fait référence à une autre table ou à une autre sys_id, seule la valeur du champ est ajoutée. Par exemple : sys_id pour un utilisateur au lieu du nom de l’utilisateur.
    Figure 1. Exemple XML
    Exemple XML
    Figure 2. Valeur de la propriété
    Valeur de la propriété
    Figure 3. Résultat dans un message de validation
    Résultat affiché dans le message de validation