Creator Studio Stratégie d’instance de développement
Assurez-vous de l’installer Creator Studio sur toutes les instances sur lesquelles ServiceNow les utilisateurs créeront des applications, y compris l’instance de production.
Décider de votre stratégie d’instance
- Accès libre : Autorisez tous les membres de votre entreprise à utiliser Creator Studio pour créer des applications.
- Accès restreint : Limitez l’accès à un groupe spécifique d’utilisateurs.
- Accès basé sur la demande : Configurez un formulaire dans lequel les utilisateurs peuvent demander l’accès. Les administrateurs examineront ces demandes et décideront d’accorder ou non l’accès.
Développement et déploiement sur des instances de production
Une instance de non-production configurée de la même manière que votre instance de production peut être la meilleure candidate pour votre environnement de tests. Vous pouvez ensuite identifier plus précisément les problèmes qui peuvent survenir si l’application est déployée en production.
Vous devez vous assurer que les développeurs créent des applications sur Creator Studio une instance de non-production, puis déploient des applications prêtes et approuvées en production.
Lorsque vous déployez une application, les enregistrements sont référencés dans la table Applications du magasin [sys_store_app] sur l’instance de production. Cependant, lorsque vous développez une application, les enregistrements sont référencés dans la table Applications système [sys_app]. Donc, si vous développez en production, vous développez en utilisant la table [sys_app] au lieu de [sys_store_app].
Après avoir établi votre stratégie d’instance, vous devez également établir et automatiser votre processus d’approbation ou de révision. Creator Studio s’exécute dans votre environnement de non-production, et les administrateurs déploient ensuite des applications dans l’environnement de production. Pour plus d’informations sur le processus de déploiement, reportez-vous à la section Déploiement de votre Creator Studio application.
Si votre organisation dispose de plusieurs environnements de non-production, vous devez décider sur quel environnement Creator Studio de non-production s’exécuter. Vous devez également déterminer le pipeline à utiliser pour promouvoir les applications d’une instance de non-production particulière vers votre instance de test, puis enfin vers la production où l’application sera exécutée en direct. Pour plus d’informations, consultez Pipelines et déploiements.
Besoin de configuration de catalogue pour Creator Studio
Pour garantir que les formulaires s’affichent correctement pour les utilisateurs, les instances de non-production et de production doivent avoir la même Catalogue de services catégorie et toutes ses catégories.
Rôles de développeur et applications de test sur les instances
Si vous disposez du Creator Studio rôle sn_creatorstudio.user ou sn_creatorstudio.restricted_user, vous ne pourrez pas tester les applications que vous créez sur l’espace de travail de l’application de demande de l’instance de non-production. Vous devriez pouvoir tester l’application sur l’instance de non-production à l’aide Creator Studiodes aperçus d’applications de . Vous pourrez tester les applications en tant que prestataire dans l’espace de travail de l’application qui a été déployée en production.
Supposons qu’un utilisateur fait partie du Creator Studio groupe Utilisateurs, de sorte que lorsque cet utilisateur crée une application, cet utilisateur obtient des autorisations de développement déléguées pour cette application. Cet utilisateur peut ensuite publier un formulaire de demande et, si aucun rôle n’est requis pour le formulaire, il peut envoyer des demandes avec le formulaire.
Toutefois, cet utilisateur ne sera pas en mesure de répondre aux demandes ou d’accéder à l’espace de travail de l’application de demande, car il n’aura pas le rôle x_acme_user_app.agent et ne pourra pas se donner ce rôle à lui-même. Les administrateurs doivent affecter des rôles supplémentaires si nécessaire.