Creator Studio Stratégie d’instance de développement
Assurez-vous de l’installer Creator Studio sur toutes les ServiceNow instances où les utilisateurs créeront des applications, y compris l’instance de production.
Décider de votre stratégie d’instance
- Libre accès : Autorisez tous les membres de votre entreprise à Creator Studio 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 dans les instances de production
Une instance de non-production configurée de la même manière que votre instance de production peut être le meilleur candidat pour votre environnement de tests. Vous pouvez alors trouver 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éployer des applications prêtes et approuvées pour la production.
Lorsque vous déployez une application, les enregistrements sont référencés dans la table Applications de stockage [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 sur votre environnement de non-production et les administrateurs déploient ensuite des applications dans l’environnement de production. Pour en savoir plus 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écuteront-ils. Vous devez également déterminer le pipeline à utiliser pour promouvoir des 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.
Exigence de configuration du 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 test d’applications sur des instances
Si vous disposez d’un Creator Studio rôle sn_creatorstudio.user ou sn_creatorstudio.restricted_user, vous ne pouvez 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 devez être en mesure de tester l’application sur l’instance de non-production à l’aide Creator Studiodes aperçus d’application de . Vous pourrez tester les applications en tant que prestataire dans l’espace de travail sur l’application qui a été déployée en production.
Supposons qu’un utilisateur se trouve dans le Creator Studio groupe Utilisateurs, lorsque cet utilisateur crée une application, il obtient des autorisations de développement délégué 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. Les administrateurs doivent affecter des rôles supplémentaires si nécessaire.