Avant la migration

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 le lien vers le contrôle de source, si l’application dispose d’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 », ils ne sont pas conservés en tant que validations.

Quelle que soit l’option que vous sélectionnez, si vous sélectionnez Continuer, l’opération Link to Source Control 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 compléter des ensembles de mises à jour supplémentaires ou choisir de ne pas continuer, sélectionnez Annuler.

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 triées par horodatage de sys_recorded_at . Pour les applications globales : tous les enregistrements sys_update_xml appartenant à l’application et faisant partie d’un ensemble de mises à jour global achevé sont capturés en tant que validations historiques.

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 dans le commit initial, vous pouvez voir des fichiers tels que sys_choice fichiers ê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 feraient 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 des 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 : reportez-vous à 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 nombre 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 à partir de 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 liées au contrôle de source à partir de l’instance si le validateur choisit de conserver l’historique des ensembles de mises à jour.