Not available in the Free plan
One of the most common use cases for Salto is deploying changes between different environments. Users can deploy small changes from a Sandbox environment to the Production one, or complex changes from a Dev environment to UAT and Production.
Deploying changes in Salto is a simple process which consists of two steps:
- Comparing the source and target environments, and selecting which changes should be deployed to the target
- Reviewing and approving the deployment plan
Deployments are part of shared environments, which means that team members can collaborate when 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.
The configuration files of the source and target environments must be identical. Any changes applied to the configuration file of one of these environments must be applied to the other environment before a deployment takes place. You can compare the configuration files and identify differences by using any online text comparison tool, such as Diffchecker.
First, select the environment you want to deploy to. Once inside, click the “deployments” tab at the top bar. This is where you’ll see all deployments - ones which are being planned, run right now, or past deployments.
To get started, click the “New Deployment” 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 “Create Deployment” 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.
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.
Additional team members can also go into this deployment (from the deployments view) and add additional changes to deploy.
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.
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 related change will be added to the “Related Elements” tab at the top. You can notice when it happens by seeing the element counter grow.
Select the “Related Elements” tab, and then the related element itself, to add it to the deploy plan.
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.
Observe the three tabs on the left - “Planned”, “Skipped” and “All”
In the “Planned” tab, you will see all changes you previously selected, which will be deployed by Salto.
In the “Skipped” tab, you will see all changes you previously selected, which will not be deployed by Salto. To understand why they can’t be deployed, click on each one. You can also see a consolidated list of all deploy issues by opening the bottom bar.
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” tabs to see the deploy results.
You can also review any deployment errors in the bottom “Deploy Events” 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.
You can clone the deployment in order to deploy the same elements to another environment, or retry a failed deployment.
Updated 7 days ago