CI Environments
The ability to quickly spin up an environment that is completely built from your source code repository, makes scratch orgs an ideal candidate for validating changes before merging pull requests. In this process, a freshly spun up scratch org could be used to deploy the metadata in your repository with the changes ( a PR process creates a temporary merge of the incoming branch along with current head of the target branch), run apex tests, run UI tests etc. This addresses the following problems compared to using a sandbox for validation, especially in large programs.
- Time consumed to spin a sandbox: Developer sandbox still takes anywhere under 1 hour to create and activate a new environment. So it is not cost effective to provision sandboxes as a just-in-time disposable environment.
- CI Org getting corrupted: Due to the time taken to spin a sandbox for every run, often a dedicated CI sandbox or an existing sandbox is re-purposed for validating incoming pull requests. Due to the nature in software development for Salesforce, these sandbox typically tend to become corrupted due to unwanted deployments or configuration changes directly in the org. As a result the changes must be manually fixed before being able to be use again as the CI org.
- Resource Contention: Before scratch org's came into existence, typically a sandbox was used for validation run's. This means validation runs had to be queued up waiting for the CI environment to be free. As a result, deployment queues on the sandbox may result in delays in validation error results.