Directives générales et cas d’utilisation pour Developer Sandboxes

Suivez quelques directives générales pour vous assurer que vous optimisez votre utilisation des bacs à sable.

Nombre d’utilisateurs Developer Sandboxes

Chaque bac à sable ne doit avoir qu’une seule personne qui y travaille. Plusieurs utilisateurs par bac à sable annuleraient les avantages du développement parallèle.

Les droits peuvent être empilés, prenant en charge jusqu’à 30 bacs à sable par instance.

Remarque :

Le nombre de bacs à sable n’a pas d’impact sur les performances de l’instance.

Les utilisateurs peuvent être connectés à l’instance de base et à plusieurs bacs à sable en même temps. Les utilisateurs de bac à sable utilisent les mêmes informations d’identification de connexion pour leur bac à sable que l’instance de base. Si vous utilisez l’authentification unique (SSO) pour la connexion, lorsque vous l’autorisez à se connecter à votre compte sur l’instance de base, Developer Sandboxes il s’authentifie à l’aide du même mécanisme et des mêmes informations d’identification que l’instance de base. Pour plus d’informations sur l’activation de la SSO, reportez-vous à la section Installer Developer Sandboxes.

Remarque :

L’authentification unique (SSO) pour les bacs à sable ne fonctionne pas sur les instances avec des URL personnalisées.

Délai pour Developer Sandboxes

Utilisez cette fonction Developer Sandboxes pour créer des environnements intentionnellement transitoires. Plus ils durent, plus ils s’éloignent de l’instance de base d’origine. Ainsi, Developer Sandboxes devrait être aussi éphémère que possible.

Les bacs à sable sont temporaires et peuvent être alignés sur de courtes périodes de développement. Par exemple, dans le développement agile, les bacs à sable peuvent durer aussi longtemps que :

1. Un sprint
2. Une histoire
3. Une série de tests

Exemples d’allocation de bac à sable

Voici des exemples d’utilisation des bacs à sable :

• Créez des branches au début d’un sprint.
• Une nouvelle branche doit être créée pour chaque bac à sable.
• Si vous devez corriger un bogue au milieu d’un sprint, au lieu de dissimuler les modifications, créez un deuxième bac à sable avec une nouvelle branche et corrigez le bogue à cet endroit. Ensuite, fusionnez ces changements dans la branche de publication et déployez le correctif de bogue en production.
• Créez un bac à sable pour tester une story ou une fonctionnalité en intégrant les modifications dans un nouveau bac à sable, que vous mettrez hors service une fois les tests terminés.

Developer Sandboxes Instances de non-production par rapport aux instances de non-production

Developer Sandboxes ne remplacent pas les instances de non-production. Developer Sandboxes sont destinées à être temporaires, tandis que les instances de non-production sont plus permanentes et destinées à être utilisées à long terme.

Le tableau suivant compare la façon la plus efficace d’utiliser les Developer Sandboxes instances de non-production.

Tableau 1. Comparaison des instances de non-production suggérées et Developer Sandboxes

Instances de non-production	Developer Sandboxes
Partitionnez le travail de votre entreprise par équipe ou par projet	Isolez les changements de métadonnées du développeur au sein d’un projet.
Les groupes partent de configurations très différentes	Tous les développeurs commencent avec la même configuration d’instance de base de référence.
Les flux de travail simultanés sont isolés ou alignés de manière minimale	Les activités de développement suivent une cadence constante.
Un environnement durable pour des changements à long terme	Le travail peut être effectué dans un environnement temporaire et engagé dans le contrôle de version.

Pour plus d’informations sur la configuration des bacs à sable sur les instances, reportez-vous à la section Installer Developer Sandboxes.

Developer Sandboxes et ServiceNow Fluent

Developer Sandboxes fonctionnent mieux avec ServiceNow Fluent et ServiceNow IDE.

Les modifications low-code représentées dans le balisage XML entraînent parfois des problèmes de fusion, car la structure du fichier généré peut rendre difficile l’alignement des modifications. Lorsque vous utilisez des générateurs low-code sur le ServiceNow AI Platform, la meilleure stratégie à long terme consiste à enregistrer les changements au ServiceNow Fluent lieu de XML.

ServiceNow Fluent est un langage de programmation spécifique à un domaine que vous pouvez utiliser pour définir les métadonnées d’application dans le code source. Les développeurs et les administrateurs peuvent facilement rechercher des changements dans le contrôle de version, comme Git. Pour plus de détails, voir ServiceNow Fluent.

Vous pouvez utiliser Developer Sandboxes avec Ensembles de mises à jour système, mais une solution plus prospective consiste à utiliser ServiceNow IDE. L’association de vos bacs à sable et ServiceNow IDE avec des applications de contrôle de version et de déploiement (telles que App Engine Management Center) permet d’obtenir un écosystème de déploiement plus propre et plus rationalisé. Pour plus d'informations, consultez ServiceNow IDE.

Developer Sandboxes Questions fréquentes

Voir l’article sur les bacs à sable pour développeurs : FAQ et guide de démarrage.ServiceNow Community