Managing sandboxes can certainly be a struggle day-to-day with common maintenance tasks of synchronization and utilization, 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 offers 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 partners detailed release notes outlining what's changed across the different Salesforce clouds, capabilities, metadata and APIs.
These are 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 correlates to whether they're in the running to be automatically upgraded, and there's a Heroku app provided to help you check this, and then request a Non-Preview sandbox on refresh if necessary.
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 or integrations, in accordance with your API versioning strategy.
Regression test existing customizations and see whether new changes will impact them ahead of the formal Production upgrade which is several weeks later.
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 recognized by target 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 sandboxes.
This is especially prevalent for your central testing sandboxes that integrate development work on the way to production; if there's an API regression, or newer functionality mixed in with general updates, you could end up in a situation where features can then only validate and deploy to Preview sandboxes, and not Production. Keeping the preview sandboxes out of your central release train is advised.
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.
We always aim to add support for the new API version within the preview window to allow relevant testing, but please let us know about any new metadata types via the in-app chat.
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.