Déployer votre application

Une fois l’application généré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 dans des environnements de tests avant de passer en production.

Référentiel d’applications (App Repo)

La publication d’une application dans le référentiel d’application rend cette version de l’application disponible dans toutes les instances ServiceNow d’une organisation. Utilisez le référentiel d’application pour déployer une application vers des instances QA/Test (pour le 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 en aval correspondent aux instances en amont.
  • Les personnalisations introduites au milieu de la pile peuvent être écrasées par les futures poussées à partir du bas de la pile.
  • Les scénarios les plus courants sont les suivants :
    • Les correctifs sont nécessaires en test ou en prod – toujours les pousser du développement vers le haut
    • Personnalisation courante de l’administrateur de production, telle que les listes de choix : toujours transmettre les mises à jour par push à partir du développement vers le haut
• Consultez toujours les mises à jour contenues dans un ensemble de mises à jour avant de les transférer.
  • Recherchez les mises à jour associées à d’autres efforts de développement et les mises à jour associées aux tests.
  • Surveillez les modifications apportées aux propriétés système et aux points de terminaison d’intégration. 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.
• Toujours effectuer un test après 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 de sorties multiples et parallèles, assurer 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 capturez pas le développement dans l’ensemble de mises à jour par défaut.

Répertorie tous les numéros de stories d’utilisateurs avec une description brève 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 d’index de base 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 le bon ensemble de mises à jour est sélectionné lorsque vous travaillez sur un story ou un défaut et vérifiez quotidiennement les enregistrements dans l’ensemble de mises à jour.

Ne déplacez pas manuellement sys_update_xml enregistrements entre les ensembles de mises à jour. La seule exception est le déplacement d’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 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) placées dans les tests ne sont pas suivies par les ensembles de mises à jour.

Soyez conscient des choses à faire et à ne pas faire dans 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 remplissez le champ sys_update_set.comments de l’enregistrement avec le motif de 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 vers 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 de données à importer pour déplacer les données d’une instance à l’autre (et non des ensembles de mises à jour).

Mise en lot des ensembles de mises à jour

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

Le fait de gérer 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. Pour éviter ces problèmes, regroupez les ensembles de mises à jour terminés en 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 enfant et parent, ce qui permet d’établir 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’ensemble du lot. Le système détermine l’ordre de traitement et recherche les collisions en fonction des dates d’enregistrement des modifications et de leur ascendance séquentielle. Leurs ancêtres sont les instances spécifiques dans lesquelles les changements apportés aux ensembles de mises à 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 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 manière de l’améliorer et 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 Concepteur de flux.
• Déterminez si les nouveaux spokes IntegrationHub peuvent être exploités pour de nouvelles intégrations.