legacy - 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 migrer les informations des ensembles de mises à jour terminés vers l’historique de contrôle de source.

Important :

À partir de la Xanadu mise en production, la legacy version de est en cours de ServiceNow Studio préparation pour une éventuelle dépréciation. Ce module d'extension sera masqué et ne sera plus activé sur les nouvelles instances, mais continuera d'être pris en charge. Pour en savoir plus sur le processus de dépréciation, consultez l’article Processus de dépréciation [KB0867184] dans la base de connaissances Now Support.

Essayez plutôt de créer et de modifier des applications dans la version actuelle de ServiceNow Studio Pour plus d'informations, consultez ServiceNow Studio.

Avant la migration

Assurez-vous que vous remplissez ces critères avant de tenter de migrer vos ensembles de mises à jour :

• Rôle requis : admin
• Lire la legacy - Lier une application ou une personnalisation d’application au contrôle de source rubrique
• Terminez les ensembles de mises à jour de 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.

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.

Lorsque l’opération Link to Source Control est terminée, la validation la plus récente est l’état actuel de votre application dans son intégralité. Vous pouvez afficher les validations historiques 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 d’un fichier qui ne sont pas dans le bon ordre entre différents ensembles de mises à jour.
• Si un ensemble 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 :

Tout commit précédé de [Commit historique] est généré uniquement pour afficher son historique. N’essayez pas d’extraire ces validations dans le 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 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.

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 Personnalisation ci-dessous)

}
{

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.

Remarque :

Si la valeur d’un champ fait référence à une autre table ou à un 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

Figure 2. Valeur de la propriété

Figure 3. Générer un message de validation