With Gearset’s clone package feature, you can promote successful changes to the next environment in your release pipeline. While this was, and still is, a huge time-saver, if you wanted to migrate changes from multiple deployments, you’d have to clone each in turn, or start from scratch with a fresh comparison.

To go away with this repetition and speed up your release cycle, Gearset lets you combine multiple deployments into a single package.

To get started, just head to the Deployment history page. Choose which deployments you’d like to combine by selecting the checkboxes in the column on the left, and click Combine Packages... at the bottom of the page.

The resulting dialog lets you review and confirm which deployments you’re combining, and pick source and target environments for the combined deployment - you can choose from both Salesforce orgs and version control. 

Before you kick off the comparison, in the Metadata filter tab, you can choose from one of the two options:

Once you've run the comparison, the items from each combined deployment will be pre-selected for you in the new comparison results grid.

From this point onwards, the deployment behaves like any other in Gearset - you can add and remove items to and from your deployment, refresh the comparison, save a draft, or carry on to a validation or deployment step, all without having to repeat the process for each deployment you'd like to clone.

To find out more about how Gearset determines which metadata items are selected, please refer to this guide:

Which metadata differences are the same between different Gearset comparisons

Remember, Gearset's clone deployment works by running a fresh comparison, so you don't run the risk of overwriting changes.

This means Gearset will run a new comparison between your source and target, then select all the component names that were deployed in the selected past deployments, before showing you the comparison results. This gives you an opportunity to review each change before you deploy it, while also making sure that you're seeing up-to-date metadata.

This means that only the list of item names is carried from the various input packages, whilst the content of the XML of the source environment selected will decide what actual XML metadata forms the resulting deployment package.

This feature works for Salesforce orgs authenticated via any of the available "Connection type":