Déployer votre application

Une fois l’application créée et validée, elle doit être déplacée vers l’environnement de production. Les applications peuvent être déplacées via un référentiel d’applications ou à l’aide d’ensembles de mises à jour. Les applications doivent être déployées pour tester les environnements avant de passer en production.

Référentiel d’applications (référentiel d’applications)

La publication d’une application dans le référentiel d’application rend cette version de l’application disponible à toutes les instances ServiceNow d’une organisation. Utilisez le référentiel d’applications pour déployer une application vers des instances d’assurance qualité/de test (à des fins de test) et enfin vers des instances de production (prod).

Pour plus d’informations, consultez Publication d’une application dans le référentiel d’applications, Installer une application.

Ensembles de mises à jour

Si le référentiel d’applications ne peut pas être utilisé pour déployer des applications, utilisez plutôt des ensembles de mises à jour. Le diagramme montre le cycle de vie des bonnes pratiques d’un ensemble de mises à jour pour déployer une personnalisation de l’instance de développement vers l’instance de test.

Pratiques qui mènent à un processus de développement et de mise en production de qualité :

• Déplacez toujours les personnalisations du bas de la pile vers le haut.
  • Garantit que les instances de pile descendante correspondent aux instances de pile montante.
  • Les personnalisations introduites en milieu de pile peuvent être remplacées par de futures poussées à partir de la pile descendante.
  • Les scénarios courants incluent :
    • Correctifs nécessaires en test ou en production - poussez-les toujours à partir du développement
    • Personnalisation courante de l’administrateur de produit, telle que les listes de choix : toujours envoyer les mises à jour par push à partir du développement
• Vérifiez toujours les mises à jour contenues dans un ensemble de mises à jour avant de procéder au transfert.
  • Recherchez les mises à jour associées à d’autres efforts de développement et les mises à jour associées aux tests.
  • Surveillez les changements apportés aux propriétés système et aux points de terminaison d’intégration. Ex. : forcer sys_properties changement qui dirige tous les e-mails vers le compte de messagerie de test
  • Déplacer les mises à jour vers un ensemble de mises à jour « scrap » plutôt que de supprimer la mise à jour.
• Testez toujours après avoir effectué une opération push pour vous assurer que toutes les personnalisations souhaitées sont capturées et appliquées comme prévu.
• Dans les situations avec plusieurs versions parallèles, assurez la communication et la coordination entre les équipes de développement.
• Évitez d’expérimenter sur l’instance de développement, car les personnalisations peuvent être capturées accidentellement et migrées par d’autres membres de l’équipe.
• Ne pas capturer le développement dans l’ensemble de mises à jour par défaut.

Répertorie tous les numéros de stories d’utilisateurs avec une brève description dans le champ Description d’un ensemble de mises à jour. Incluez toutes les étapes manuelles nécessaires au déploiement de l’ensemble de mises à jour.

Voici quelques exemples typiques d’étapes manuelles nécessaires pour un déploiement qui ne sont pas capturées dans un ensemble de mises à jour :

• Activation du module d’extension.
• Transfert des tables qui ne sont pas suivies dans l’ensemble de mises à jour (généralement, commençant par « x_ » ou « u_ »).
• Création des index des bases de données sur les tables. La création d’index n’est pas suivie via l’ensemble de mises à jour et doit être effectuée manuellement.

Gestion des ensembles de mises à jour

Assurez-vous que l’ensemble de mises à jour correct est sélectionné lorsque vous travaillez sur une story ou un défaut et vérifiez quotidiennement les enregistrements de l’ensemble de mises à jour.

Ne déplacez pas manuellement sys_update_xml enregistrements entre les ensembles de mises à jour. La seule exception est de déplacer un enregistrement vers l’ensemble de mises à jour par défaut.

Les ensembles de mises à jour capturent les informations de configuration, mais pas les données de tâche ou de processus. Par exemple, les ensembles de mises à jour suivent les définitions d’éléments de Catalogue de services et les données de configuration connexes telles que les variables et les choix de variables. Toutefois, les commandes (demandes, éléments, tâches du catalogue) passées en test ne sont pas suivies par les ensembles de mises à jour.

Soyez conscient des ensembles de mises à jour à faire et à ne pas faire :

• Pour supprimer un enregistrement de sys_update_xml spécifique de l’ensemble de mises à jour actuel, déplacez l’enregistrement vers l’ensemble de mises à jour par défaut et remplissez le champ sys_update_set.comments de l’enregistrement avec la raison du déplacement de l’enregistrement vers l’ensemble de mises à jour par défaut.
• Ne déplacez jamais les enregistrements de personnalisation d’un ensemble de mises à jour à un autre.
• Ne supprimez jamais un ensemble de mises à jour à moins que l’ensemble de mises à jour n’ait été fusionné avec succès dans un nouvel ensemble de mises à jour.
• Utilisez toujours des extraits de données ou des ensembles d’importation pour déplacer les données d’une instance à l’autre (et non des ensembles de mises à jour).

Mise en lot d’Update Set

Ensembles de mises à jour par lots pour prévisualiser et valider les ensembles de mises à jour en bloc.

La gestion de plusieurs ensembles de mises à jour peut entraîner des problèmes, notamment la validation d’ensembles de mises à jour dans le mauvais ordre ou l’omission par inadvertance d’un ou de plusieurs ensembles. Évitez ces problèmes en regroupant les ensembles de mises à jour terminés dans un lot.

Le système organise les lots d’ensembles de mises à jour dans une hiérarchie. Un ensemble de mises à jour peut servir de parent pour plusieurs ensembles de mises à jour enfants. Un ensemble donné peut être à la fois un enfant et un parent, ce qui permet des hiérarchies à plusieurs niveaux. Un ensemble de mises à jour au niveau supérieur de la hiérarchie fait office d’ensemble de mises à jour de base.

La validation ou l’aperçu de l’ensemble de mises à jour de base prévisualise ou valide l’intégralité du lot. Le système détermine l’ordre de traitement et vérifie les collisions en fonction des dates d’enregistrement des changements et de leur ascendance séquentielle. Leurs ancêtres sont les cas spécifiques dans lesquels les changements dans les ensembles de mise à jour ont eu lieu.

Le traitement par lots des ensembles de mises à jour peut être appliqué aux mises en production, où un ensemble de mises à jour parent vide est créé pour la mise en production et où les ensembles de mises à jour réels sont inclus dans la mise en production en tant qu’enfants.

Les avantages de l’utilisation du traitement par lots d’ensembles de mises à jour sont les suivants :

• Les ensembles de mises à jour individuels peuvent être supprimés de la mise en production au dernier moment.
• Le traitement par lots est similaire à la fusion, sauf que le traitement par lots permet de supprimer des mises à jour.
• Les ensembles de mises à jour par lots sont faciles à déployer. Seul l’ensemble de mises à jour parent doit être traité.

Pour plus d'informations, consultez Ensembles de mises à jour système.

Étapes suivantes

Maintenant que l’application est déployée, réfléchissez à la façon de l’améliorer et de l’améliorer. Voici quelques suggestions pour déterminer où aller ensuite :

• Les personnes qui utilisent l’application au quotidien seront la meilleure source de commentaires. Parlez-leur des nouvelles fonctionnalités ou des changements qu’ils aimeraient voir.
• Déterminez si des flux de processus connexes supplémentaires peuvent être automatisés via Concepteur de flux.
• Déterminez si les nouveaux spokes du Centre d’intégration peuvent être exploités pour de nouvelles intégrations.