General guidelines and use cases for Developer Sandboxes
Follow some general guidelines to ensure you're optimizing your use of sandboxes.
Number of Developer Sandboxes users
Each sandbox should have only one person working in it. Multiple users per sandbox would negate the benefits of parallel development.
Timing for Developer Sandboxes
Use Developer Sandboxes to create intentionally transient environments. The longer they last, the farther they get from the original base instance. Thus, Developer Sandboxes should be as short-lived as possible.
- A sprint
- A story
- A round of testing
Examples of sandbox allocation
- Create branches at the start of a sprint.
- A new branch should be created for each sandbox.
- If you need to fix a bug in the middle a sprint, instead of stashing changes, create a second sandbox with a new branch and fix the bug there. Then merge those changes into the release branch and deploy the bug fix to production.
- Create a sandbox to test a story or feature by pulling in the changes to a new sandbox, which you will retire when the testing is complete.
Developer Sandboxes vs. non-production instances
Developer Sandboxes are not a replacement for non-production instances. Developer Sandboxes are intended to be temporary, while non-production instances are more permanent and intended for use long-term.
| Non-production instances | Developer Sandboxes |
|---|---|
| Partition your company's work by team or project | Isolate developer metadata changes within a project. |
| Groups start from significantly different configurations | All developers begin with the same baseline instance configuration. |
| Concurrent workstreams are isolated or minimally aligned | Development activities follow a consistent cadence. |
| Durable environment for long-term changes | Work can be completed in a temporary environment and committed to version control. |
Developer Sandboxes and ServiceNow Fluent
Developer Sandboxes work best with ServiceNow Fluent and ServiceNow IDE.
Low-code changes represented in XML markup sometimes cause merging issues, because the generated file structure can make it challenging to align changes. When using low-code builders on the ServiceNow AI Platform, the best long-term strategy is to save changes in ServiceNow Fluent instead of XML.
ServiceNow Fluent is a domain-specific programming language that you can use to define application metadata in source code. Developers and admins can easily look up changes in version control, such as Git. For details, see ServiceNow Fluent.
You can use Developer Sandboxes with System Update Sets, but a more forward-looking solution is to use ServiceNow IDE. Pairing your sandboxes and ServiceNow IDE with version control and deployment apps (such as App Engine Management Center) enables a cleaner, more streamlined deployment ecosystem. For more information, see ServiceNow IDE.
Developer Sandboxes FAQs
See the ServiceNow Community article on Developer Sandboxes: FAQ and Getting Started Guide.