A common strategy in any software project is to have a pipeline of environments. You start with a development environment to make the required changes, which are then promoted to a test environment for QA. Those changes get signed off by your business users in a UAT environment before finally being deployed to production when all stakeholders are confident in the release.
How cloning works in Gearset
Gearset makes it easy to create a new deployment based on an existing one. It works by allowing you to select a previous deployment and specify a new source and target environment. Gearset will then compare the new environments and automatically pre-select the components from the deployment being cloned. You can then click straight through to the pre-deployment summary to rapidly deploy the same changes out to a new environment.
Cloning a deployment with Gearset
From the Deployment history page, click
Clone package...on the deployment you wish to re-use.
Targetthat you want to compare. (For example, if you had previously pushed a new Custom field from Dev > Staging, and now want to push that from Staging > Prod, select Staging as the source and Prod as the target.)
You have the option to choose a new metadata filter if you wish, otherwise the default one will copy the previous deployment.
Run comparisonto begin a comparison between your source and target.
When the comparison is complete, Gearset will pre-select the items used in the previous deployment, if the difference type (new, changed, deleted) is the same as the original deployment, and show you the
Selected itemstab. (Note: Items with
No Differencebetween your source and target will not be selected, as these cannot be deployed.)
NEXTto move to the pre-deployment summary.
You can now review and finish the deployment with a few clicks.
Packages can be cloned from source control systems as well as Salesforce orgs.
To find out more about how Gearset determines which metadata items are selected, please refer to this guide.
With this workflow, Gearset helps introduce simplicity, rigor and compliance into your release process, and ultimately prevent those pesky bugs from making it through to production.
To learn more about release pipelines, read our blog post or our release management white paper. To learn more about running a deployment, see this help article.