º£½ÇÌìÑÄÉçÇø

As those of you familiar with º£½ÇÌìÑÄÉçÇø are likely aware, most things in º£½ÇÌìÑÄÉçÇø start with a comparison. º£½ÇÌìÑÄÉçÇø takes the metadata for two orgs and runs a comparison between them, which has lots of benefits. Comparisons underpin many of º£½ÇÌìÑÄÉçÇø’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 º£½ÇÌìÑÄÉçÇø 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 º£½ÇÌìÑÄÉçÇø’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: º£½ÇÌìÑÄÉçÇø 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

º£½ÇÌìÑÄÉçÇø 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, º£½ÇÌìÑÄÉçÇø 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 º£½ÇÌìÑÄÉçÇø’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.

If you’re working in a multi-org setup and need something more structured, º£½ÇÌìÑÄÉçÇø’s layered modules can help you go a step further. While redeploy lets you reuse the same package across environments, layered modules help you organize your metadata into shared and org-specific layers in version control. It’s a scalable way to manage long-term deployments across multiple orgs, especially when you’re working with Pipelines.

How it works in º£½ÇÌìÑÄÉçÇø

When you use this feature, º£½ÇÌìÑÄÉçÇø runs a new comparison between the metadata from the time of your original deployment and that of your new target. Behind the scenes, º£½ÇÌìÑÄÉçÇø 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. º£½ÇÌìÑÄÉçÇø automates this aspect of the deployment, and because it’s based on your previous work, it’ll save you from repeating those steps.

º£½ÇÌìÑÄÉçÇø 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 º£½ÇÌìÑÄÉçÇø

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, º£½ÇÌìÑÄÉçÇø 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

º£½ÇÌìÑÄÉçÇø’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. º£½ÇÌìÑÄÉçÇø 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. º£½ÇÌìÑÄÉçÇø 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.

Redeploy packages in just a few clicks

º£½ÇÌìÑÄÉçÇø not only makes deploying packages to new targets possible, but also allows you to deploy across different Salesforce editions.

Want to save time with º£½ÇÌìÑÄÉçÇø’s redeployment options? Start a , with nothing to install in your orgs.