Migrer l’historique des ensembles de mises à jour terminés vers le contrôle de source
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
- Rôle requis : administrateur
- Lire le Lier une application ou une personnalisation d’application au contrôle de source sujet
- Complétez tous les ensembles de mises à jour pour votre application que vous souhaitez exporter en tant qu’historique de contrôle de source.
- Exportez l’ensemble de mises à jour terminé si vous souhaitez le conserver.
- 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.
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.
- 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.
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.
[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>
{}
{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.