(!) Available in the Pro and Enterprise plans

One of the most common use cases for Salto is comparing and deploying changes between different environments. Users can compare and then deploy small changes from a Sandbox environment to the Production one, or complex changes from a Dev environment to UAT and Production.

Comparing and deploying changes in Salto is a simple process that consists of two steps:

Comparisons and deployments are part of shared environments, which means that team members can collaborate when comparing and deploying changes by adding their individual changes and reviewing the deployment plan.

❗ The comparison will be done between the latest fetched version of the source and destination environments. Before starting a new deployment, it’s highly recommended to fetch the source and destination environments so you can see the most recent changes. You can also set up periodical fetches to help you do so.

First, select the environment you want to deploy to. Once inside, click the “Compare & Deploy” tab at the top bar. This is where you’ll see all deployments - ones that are being planned, run right now, or past deployments.

To get started, click the “Compare & Deploy” button.

Here, you can choose the source and destination environments, and give a name and description to your deployment. Choose something which will be familiar and recognizable to you and your teammates, as you may end up having a lot of deployments. You can also include a ticket ID in the description to associate deployments with a Jira issue or any other type of ticket.

Once you’re done, click the “Compare & Deploy” button.

If this is the first time you’ve deployed something between these 2 specific environments, Salto may take some time to compare these 2 environments and cache the result. While it’s doing that, feel free to explore other parts of Salto - you will get a popup message as soon as the comparison is done and you can proceed with the deployment.

As a best practice the include and exclude sections of the configuration files of the source and target environments participating in a deployment should be identical. Any changes applied to these sections in a configuration file of one of these environments, should be applied to the other environment before a comparison or deployment take place. You can compare the configuration files and identify differences by using any online text comparison tool, such as Diffchecker.

This is the first step of any deployment - choosing which changes you want to deploy from the source to the destination environment. Salto displays all differences between the two environments - elements exist only on one of the two environments, or elements with different contents.

Click on an element to see how it differs between the source and destination environments and select the elements you would like to deploy.

For elements which were modified (and not added or removed), you can also select specific changes to deploy within the element. That helps you deploy only changes within elements that are ready for deployment, while others may still be tested.

Additional team members can also go into this deployment (from the deployments view) and add additional changes to deploy.

Use the table-tabs at the top to quickly browse to elements which, if selected, will be added, modified or removed.

You can also filter elements by using the filter text box, or clicking any of the table columns; for example, if you want to find a specific element type.

At some deployments, multiple changes have to be deployed together. For example, when deploying a new Salesforce object which uses a new Picklist, you need to deploy both of them for the deployment to be successful.

Salto helps you select all the necessary changes for a successful deployment.
In the element selection phase, when you select a change which relies on another one, the required change will appear in the "Required Dependencies" column. You can review these requirements by clicking on the notification itself, or simply add all the required elements to your deployment using the checkbox.

You can also review all the missing dependencies by clicking the "Missing Dependencies" table-tab. This will show you a list of all the elements required for a successful deployment. An icon next to each elements name can also show you why it's required for this deployment.

In addition to required dependencies, Salto also provides 2 other dependencies that you may choose to add to your deployment:

Adding these elements is a suggestion - they are usually not required for a successful deployment.

When you’re done, continue to the deployment preview phase by clicking on the “Preview Plan'' button. Note that while the element selection phase was collaborative, allowing different team members to add elements on their own, moving to the next phase (deployment preview) will lock the deployment. Only the team member who clicked on “Preview Plan” will be able to approve and deploy the changes.

📘 Salesforce Validation Deployments

When deploying changes to a Salesforce org, you can validate the changes without deploying them, and view the success or failure messages you would receive with an actual deploy. Learn more about how to do this with Salto.

After selecting the changes to be deployed in the previous step, Salto calculates the deploy plan for your deployment - which API calls to make, in what order, and which elements can or can’t be deployed because of various constraints. In this view, you can review this plan.

In this screen, you can review the elements you selected for deployment. Each element will be marked as Ready or Not Ready. Elements which aren't ready have some issues that prevent them from being deployed - Salto will not attempt to deploy them. Click the elements to review the issues preventing their deployments.

In addition, some Ready elements may also have issues, which do not prevent them from being deployed. Click the elements to learn more about these more.

You can also review all elements which are ready or not, or focus only on additions, removals or modifications, by using the table-tabs above the table.

If your deployment requires some additional changes to the deployed elements, which were not part of the elements in the source environment, you can use the “Edit” button to edit the element itself. This edit will be applied only to the target environment element, once the deployment is made. You can also edit additional target elements as part of the deployment, by selecting them from the “All” tab and editing them.

If you realize there are additional changes that you forgot to include in this deployment, you can always go back to the element selection phase. Note that edits that you’ve made will be discarded in this case.

When you’re done reviewing the plan, proceed to deploying them by clicking “Deploy”. This process may take some time; you can review its progress in the top progress bar.

📘 When clicking deploy, you may see a popup with a list of pre-deploy actions you need to perform on the service side. For example, when deploying Salesforce CPQ data, you may need to disable triggers before deploying. Follow the on-screen instructions, and if necessary the links for additional documentation about each recommended action

Once the deployment is complete, Salto presents the deployment summary - which elements were successfully deployed, which weren’t, and additional errors to review.
Review the “Deployed” and “Failed to Deploy” table-tabs to see the deploy results.
You can also review any deployment errors in the “Deploy Errors” tab.

📘 When deploy ends, you may see a popup with a list of post-deploy actions you need to perform on the service side. For example, when deploying Salesforce CPQ data, you may need to enable triggers after deploying. Follow the on-screen instructions, and if necessary the links for additional documentation about each recommended action. You can click “Recommended Actions”, when available, to see these actions.

After successfully deploying elements, you can push your changes to git to document the deployed changes by selecting "push to git". The suggested git commit description will contain all details about the deployment, along with a list of all affected NACL files. Make sure the right files are selected for your commit.

It is good practice to include a relevant ticket ID in your commit description, in case your deployment name or description don't already contain it.

Once a deployment is done, you can clone the deployment in order to deploy the same elements to another environment, or fix a deployment to retry a failed one.