See our enable pilot documentation on how to run a comparison using the new compare 2.0 pilot.
Since Gearset's launch in 2015, the Salesforce release management landscape has changed with the growing popularity of DevOps and teams looking to deploy their changes faster and with fewer deployment failures.
Salesforce orgs, team size, deployment complexity and metadata types have all increased over the years and will only continue to expand further. In order for those approaches to be successful, each part of the process needs to be optimised to ensure the velocity that teams want to work at can be achieved.
That's one of the core drivers which has led to the Gearset team to rebuild its approach to downloading and comparing metadata to ensure a core stage of the process meets those needs.
The traditional Gearset comparison approach
Gearset has traditionally requested all metadata for a metadata type(s) unless a more granular pre-comparison filter has been specified to retrieve fewer types or items. Whilst this has served our users very well for over 8 years, the traditional approach can have several implications for the overall time taken to retrieve and compare metadata - leading to waiting times before being able to view or deploy changes. These include:
Waiting times for the metadata to be returned from Salesforce can be significant before a comparison can even taken place. Some metadata types can be impacted more severely than others.
For items that haven't changed, which is often the case when comparing on a semi-regular basis, these no difference items are also retrieved each time - leading to a lot of unnecessary items being requested from Salesforce, also increasing the time taken to receive the metadata from Salesforce.
Having to pre-filter each comparison to only include the most recent changes or changes you're interested in can take time to configure before requesting the metadata and leading to a longer overall process.
The Gearset compare 2.0 (pilot) approach
In order to make comparisons more responsive by removing the bottleneck of metadata download waiting times from Salesforce, and provide the metadata that users want faster, a new approach to the overall comparison process introduces a number of changes to how Gearset retrieves metadata. These come in the form of underlying comparison engine changes, but also UI changes to make the selection of what you want to see more efficient and save time.
The new comparison engine and UI changes include:
The introduction of incremental caching for metadata types resulting in the need to request less metadata from Salesforce on subsequent comparisons leading to a significant improvement in the overall experience.
Source tracking support as a comparison filter. Source tracking was introduced by Salesforce for Developer and Developer Pro sandbox orgs as a way to make the retrieval of changed items in an org more instantly available. By utilising source tracking capabilities for orgs that have it enabled, Gearset can take advantage of a faster way to retrieve a specific subset of changes and build your comparison filter automatically.
A completely new set of UI features specifically designed to let users really take charge of their comparisons and drive what results they want to see on-demand to reduce the number of pre-comparison configuration steps required.
Enhanced functionality to existing features such as the management of comparison filters with additional information available to more efficiently choose the items for comparison you most care about.
Planned comparison improvements for Q1 2024:
Proactive retrieval of metadata to return the most up-to-date version of your metadata possible
Using metadata snapshots from existing team owned connections. If your team have configured orgs to be team owned, Gearset will use the latest snapshot for that org connection, meaning that even if you haven't previously compared that org you'll receive the benefit of metadata already being available and only the delta being retrieved for metadata types you want to compare.
On-demand item level retrieval. Depending on the outcome of upcoming technical spikes, we're investigating the ability to retrieve metadata on-demand if it's in a pending state so it gets immediately prioritized for retrieval and doesn't require waiting for other metadata to be retrieved first.