Managing sandboxes can certainly be a struggle day-to-day with common maintenance tasks of synchronisation and utilisation, and when the Salesforce triannual release comes around an extra layer of complication can arise; Preview vs Non-Preview sandboxes.
When these major releases come around at key times throughout the year, bringing tons of great new features and changes to the wider platform, Salesforce offer a 6 week period before general availability of the new version where customers can automatically receive the latest version as a testing ground, known as a Preview Sandbox.
This is distinctly different from Non-Preview sandboxes that won't automatically get upgraded and will stay on the existing version. The instance your Salesforce sandboxes are running on directly correlate to whether they're in the running to be automatically upgraded, and there's a Heroku app provided to help you check this.
Leveraging these Preview sandboxes can be really useful for your team to:
Try out the new features and identify whether they're something you'll want to implement in future development cycles.
Consider any API changes that may impact your ways of working, in accordance with your API versioning strategy.
Regression test existing customisations and see whether new changes will impact them ahead of the formal Production upgrade.
You can leverage your Preview Sandboxes in Gearset in the same way you normally manage other Sandboxes, including adding them as a connected org and using Compare & deploy to load them up with any metadata you need to regression test.
There are some key considerations to be aware of however and should be factored into your use of them:
Since the Preview Sandboxes come alongside a new API version referencing all the new features in the release, you will be running on an API version mismatch between your standard workflow and the preview sandboxes. This needs to be a consideration when comparing and deploying metadata (manually or in CI jobs) as some elements won't be recognised by targets orgs. More detail on that here.
Due to this we wouldn't usually recommend adding Preview Sandboxes to your Gearset Pipeline, as the discrepancy in features, API versions and 'experimental' work vs planned development could cause validation and deployment failures in your critical sandboxes.
If new Metadata types are available in the latest version, but Gearset hasn't added those to the available Metadata items in the filter, Comparisons/Monitoring Jobs wouldn't be able to retrieve/deploy them.
Overall, the Preview availability can give development teams some early warning on potentially breaking features to existing implementations, the chance to head off regression issues with ongoing deployments, and visibility on new functionality they could implement in future iterations, so they're a really effective tool to consider in overall release management as long as you're aware of the key considerations.