Sandboxing
Sandboxes provide an essential tool during the development lifecycle. While we recommend the use of scratch orgs for the development of new functionality, sandboxes are still useful for user acceptance testing and training.
We recommend using sandboxes in conjunction with source control and SFDX to provide a stable and repeatable development process.
Sandboxes should never be the source of truth for metadata. All metadata should be stored in source control, and sandboxes should be considered ephemeral.
The below diagram shows an example sandboxing structure, and the flow of changes through the development lifecycle.
Each Development environment is a standalone environment. A single piece of functionality is worked on by a single developer, and then promoted up the tree.
When Development environments are reused, it means manually managing the metadata for a piece of work, instead of allowing SFDX to manage it, e.g. a developer would need to manually retrieve and commit the changes, and not rely entirely on SFDX source tracking.
If an issue is found within a testing environment, a new development environment can be created to fix the issue, without impacting the work of other developers. The ensures that the development process is stable and repeatable, with changes being tested in isolation. Any issues found in a testing environment will be reproducible in a new development environment, allowing easier and faster debugging, as these new development environments will mirror the testing environment.
Scratch orgs and development sandboxes can be used interchangeably, but scratch orgs provide a quicker and more repeatable development process.