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 à la 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 pour toutes les instances ServiceNow d’une organisation. Utilisez le référentiel d’application pour déployer une application sur des instances QA/Test (à des fins de test) et enfin sur des instances de production (Prod).

Pour plus d’informations, consultez Publication d’une application dans le référentiel d’application, 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 Update Sets. 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 diffusion de qualité :

• Déplacez toujours les personnalisations du bas de la pile vers le haut.
  • Garantit que les instances en aval de la pile correspondent aux instances de la pile supérieure.
  • Les personnalisations introduites en mid-stack peuvent être écrasées par de futures poussées à partir du down-stack.
  • Les scénarios les plus courants sont les suivants :
    • Correctifs nécessaires en test ou en prod – poussez-les toujours du développement vers le haut
    • Personnalisation standard de l’administrateur Prod, telle que les listes de choix : envoyez toujours les mises à jour du développement vers le haut
• Vérifiez toujours les mises à jour contenues dans un ensemble de mises à jour avant d’effectuer un transfert.
  • Recherchez les mises à jour associées à d’autres efforts de développement et les mises à jour associées aux tests.
  • Surveillez les propriétés système et les changements de points de terminaison d’intégration. P. ex. : transmission par push sys_properties changement qui dirige tous les e-mails vers le compte de messagerie de test
  • Déplacez les mises à jour vers un ensemble de mises à jour « obsolète » plutôt que de supprimer la mise à jour.
• Testez toujours après l’opération push pour vous assurer que toutes les personnalisations souhaitées sont capturées et appliquées comme prévu.
• Dans les situations de versions multiples et parallèles, assurez la communication et la coordination entre les équipes de développement.
• Évitez de faire des expériences 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épertorier tous les numéros de story d’utilisateur 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 de tables qui ne sont pas suivies dans l’ensemble de mises à jour (généralement, commençant par « x_ » ou « u_ »).
• Création d’index de base de données sur les tables. La création de l’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 approprié est sélectionné lorsque vous travaillez sur une story ou un défaut, et vérifiez quotidiennement les enregistrements dans l’ensemble de mises à jour.

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

Les ensembles de mises à jour capturent des informations de configuration, mais pas des données de tâche ou de processus. Par exemple, les ensembles de mises à jour suivent les définitions d’éléments de Service Catalog 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 dans le test ne sont pas suivies par les ensembles de mises à jour.

Soyez conscient des choses à faire et à ne pas faire pour l’ensemble de mises à jour :

• 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 renseignez le champ sys_update_set.comments de l’enregistrement avec le motif 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 tant que l’ensemble de mises à jour n’a pas é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 à une autre (et non des ensembles de mises à jour).

Mise à jour du traitement par lot

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 en validant des ensembles de mises à jour dans le mauvais ordre ou en omettant par inadvertance un ou 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 agir en tant que parent pour plusieurs ensembles de mises à jour enfants. Un ensemble donné peut être à la fois enfant et parent, ce qui permet d’activer 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 prévisualisation ou la validation de l’ensemble de mises à jour de base prévisualise ou valide l’ensemble du lot. Le système détermine l’ordre de traitement et vérifie les collisions en fonction des dates d’enregistrement des modifications et de leur ascendance séquentielle. Leurs ancêtres sont les cas spécifiques dans lesquels les changements dans les ensembles de mises à jour ont eu lieu.

Le traitement par lots d’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 version au dernier moment.
• Le traitement par lots est similaire à la fusion, sauf qu’il permet de supprimer les 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. Voici quelques suggestions pour déterminer la prochaine étape :

• Les personnes qui utilisent l’application au quotidien seront la meilleure source de feedback. Discutez avec eux des nouvelles fonctionnalités ou des changements qu’ils aimeraient voir.
• Déterminez si d’autres flux de processus connexes peuvent être automatisés via Flow Designer.
• Déterminez si de nouveaux spokes Centre d’intégration peuvent être utilisés pour de nouvelles intégrations.