Déployer votre application

Une fois l’application créée et validée, l’application 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 test avant de passer à la production.

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

La publication d’une application dans App Repo rend cette version de l’application disponible à toutes les instances ServiceNow d’une organisation. Utilisez App Repo pour déployer une application vers des instances de QA/Test (pour les tests) 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

S’il s’avère impossible d’utiliser le référentiel d’applications 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 vers le bas de la pile correspondent aux instances vers le haut de la pile.
  • Les personnalisations introduites en milieu de pile peuvent être remplacées par de futures opérations push à partir de la pile vers le bas.
  • Les scénarios courants incluent :
    • Corrections nécessaires dans le test ou la production - toujours poussez-les du développement vers le haut
    • Personnalisation courante de l’administrateur de production, telle que les listes de choix : toujours pousser les mises à jour depuis le développement
• Examinez toujours les mises à jour contenues dans un ensemble de mises à jour avant le 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. : pousser 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 « 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 où il y a 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épertoriez 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 à 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 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 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 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 choses à faire et à ne pas faire dans les ensembles 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 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 de données à importer pour déplacer les données d’une instance à une autre (et non des ensembles de mises à jour).

Traitement par lots de l’ensemble de mises à jour

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 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 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 prévisualisation ou la validation 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 auxquelles les changements ont été enregistrés et de leur ascendance séquentielle. Leurs ancêtres sont les instances spécifiques dans lesquelles les changements dans les ensembles de mises à jour ont eu lieu.

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

Les avantages de l’utilisation de l’ensemble de mises à jour par lots 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 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 suite des étapes :

• Les personnes qui utilisent l’application au quotidien seront la meilleure source de commentaires. 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 du Centre d’intégration peuvent être exploités pour de nouvelles intégrations.