As those of you familiar with Gearset are likely aware, most things in Gearset start with a comparison. Gearset takes the metadata for two orgs and runs a comparison between them, which has lots of benefits. Comparisons underpin many of Gearset’s useful features, like the ability to decompose and recompose complex metadata types to avoid conflicts, perform sophisticated dependency analysis and highlight when you might be about to overwrite something by mistake.
Comparisons let you build deployments in Gearset painlessly. But what if you need to ship the same changes to multiple environments? If you’re running a lot of comparisons, waiting for them to finish can slow your process down. Combine this with the need to monitor subsequent stages of Gearset’s workflow, such as manually selecting components to deploy and running problem analysers, and it quickly gets time-consuming to rebuild deployment packages. Fortunately, there’s good news: Gearset now lets you deploy the same package to a new target org without initiating a new comparison or repeating the analysis steps.
Migrate the same changes faster
Gearset now lets you push the same changes to different environments quickly and consistently. Use this feature to redeploy any previous deployment to a new target, without repeating the comparison and analysis steps. This will save you time, as you no longer need to repeat actions to move the same sets of changes. Instead, Gearset runs the comparison in the background for you and copies your previous deployment settings.
When should I deploy packages to a new target?
If you’re an #AwesomeAdmin, this feature will help you ship changes to multiple orgs quickly, without repeating work you’ve already done or waiting for comparisons to complete. Build and deploy your package as usual, then redeploy it to as many new environments as you need. When you’re moving the same changes to different environments, this feature will save you spending time waiting for comparisons to finish, selecting components and monitoring problem analysers. Instead, build your deployment once and redeploy it without covering the same ground again.
If you’re a developer, you can use this feature similarly to deploy changes made in existing branches to new environments. You can now deploy the same package to UAT, staging and on to prod without rebuilding your deployment, keeping your changes consistent at every step.
This feature makes it easier to refresh sandboxes because it lets you run quick, easy metadata deployments to multiple orgs. If you have sandboxes to seed with realistic production data, simply build your package once and deploy it to those sandboxes in a few clicks. Once you’ve deployed your metadata changes, you can then use Gearset’s data loader to deploy subsets of data to your environments. Combining these features makes it easy to build realistic testing environments quickly and with minimal effort.
How it works in Gearset
When you use this feature, Gearset runs a new comparison between the metadata from the time of your original deployment and that of your new target. Behind the scenes, Gearset selects all the previously deployed components for you. The comparison runs in the background, so there’s no need to manually initiate or monitor processes, such as selecting which components to deploy. Gearset automates this aspect of the deployment, and because it’s based on your previous work, it’ll save you from repeating those steps.
Gearset automatically preserves your original deployment’s ‘friendly name’, notes, and tickets in any connected ALM tools like Jira, during redeployment to a new target. This preserves their original context, and your audit trail for that deployment. You can also change these fields before you redeploy.
How to redeploy your previous packages with Gearset
From your deployment history, select the deployment you’d like to redeploy and select Deploy to target.
From the Summary of objects to deploy screen, select the new target you’d like to deploy to. Choose the new environment to redeploy to from the Target type dropdown. You can target a comprehensive range of environments, including Salesforce orgs of all kinds and Git repos from the popular providers.
You can also change the deployment attributes from this screen, such as the friendly name, notes and associated ALM tickets from integrations including Jira, Azure DevOps work items and Asana.
Just like a normal deployment, Gearset lets you run a validation of your package. Click the Validate deployment button to confirm that your components can be deployed to the new environment.
Click Deploy now to deploy to your new target.
The new deployment is based on your previously selected components, so you don’t need to move through the comparison results and problem analyzer steps to build your deployment again. It’s super easy to use - just select your previous deployment and point it at your new target.
Cloning a package versus deploying straight to another target
Gearset’s clone package feature also lets you promote successful changes to a new environment. Both the clone package and the deploy to target features are huge time savers, designed to make your release process simpler. But what situations are they most suitable for?
The clone package feature lets you create a deployment based on a previous one. Gearset automatically pre-selects the components from the cloned deployment. You can change what’s included in the deployment from the Comparison results page. This feature works well if you need to make manual customisations for different targets, because it supports making changes to your original deployment.
The deploy to new target feature lets you replicate a previous deployment, without having to deal with the manual parts of the process, like confirming which items you want to deploy. Gearset automatically selects all of the items included in your original deployment and skips the Comparison results page, so you can’t change what’s included in the deployment. Because this feature lets you deploy the same changes consistently to many environments, it’s suitable for use throughout your release pipeline, when you want consistency between deployments, and don’t need to many tweaks on a case-by-case basis. Use it when you’re happy with your original deployment package, comfortable that you won’t be overwriting any changes in your target environments, and want a faster way to push that same set of changes to other environments.
Try it out
Give redeploying packages to new environments a try, and let us know what you think. Your feedback helps us build new features like this, so we’d love to hear your ideas. What would you like to see in the Gearset app? Get in touch with any thoughts and feedback, no matter how big or small, via the in-app chat or our user feedback forum.