In my experience, Salesforce deployments are often a hidden productivity killer that extends the time it takes to develop new features or fix bugs for admins and developers alike.
To mitigate this, we use source-driven development to manage most of our clients' organizations. Source-driven development helps us know the current configuration of the production environment and all development environments at any time.
This has become a necessary process as we collaborate with our clients. We often have a half dozen or more features in various stages of our development cycle throughout a sprint, and our clients frequently make changes directly in production when developing new features.
By using source-driven development, we can quickly and effectively determine if our clients have made changes we were not aware of and make sure that the changes we are preparing to deploy to production will not conflict with any changes that have been made.
Retrieving Changes
The Salesforce CLI has a command that retrieves any changes made in a source-tracked Developer sandbox since the last time the command was run. Source tracking is not enabled by default on developer sandboxes. It can be enabled by following this article.
Salesforce’s CLI Command Reference reviews the command below in detail.
sf project retrieve start --ignore-conflicts.
This command greatly improves our ability to retrieve our changes into source control, but this is by no means a foolproof system.
Source tracking has some inefficiencies that do not work as expected. Every retrieval should be reviewed in detail for accuracy.
For example, when you assign a Lighting page as the default page for a specific application, source tracking does not automatically include the app when the metadata is retrieved.
Another example is retrieving profiles, which can lead to overwriting metadata. According to Salesforce, profile changes should not be deployed as metadata from one org to another.
Deploying Changes
Once all the metadata is in source control, the next step is deploying the changes to another organization.
We make a pull request to the target branch for the full (QA) or partial (staging) sandbox we use for user testing. The pull request will notify us of merge conflicts between the current feature and ones already deployed to the target branch.
Once a pull request is ready to deploy, we use the Salesforce CLI plugin SFDX-Git-Delta to create deployment manifests with the command below.
This creates two manifests that include the differences between the working branch and the target branch. One manifest is destructive, and the other is a deployment manifest.
sf sgd source delta --from <Target Branch Name> --output .
We then test the deployment. The following command performs three separate functions:
- Test the deployment of all metadata changes in the package.xml file
- Test the deletion of all changes in the destructivechanges.xml file
- Run all Apex test classes
sf project deploy validate -x package/package.xml --post-destructive-changes destructiveChanges/destructiveChanges.xml
If the command fails, it will return detailed error messages for each metadata component that fails deployment or any test class that fails.
This command does not deploy your changes once the deployment is successfully validated but generates a second command to run when executing the deployment.
Document the second command if the deployment will be executed later. The second command contains a system-generated id that cannot be easily found again.
Change Management and the Development Workflow
With this workflow, we can effectively manage internal and external changes in our clients’ orgs. We can easily identify client modifications and compare them to internal changes.
Leveraging the productivity features of the Salesforce CLI and SFDX-Git-Delta plugin enhances admin and developer productivity when retrieving and deploying changes in Salesforce orgs.
This saves time, money, and resources and accelerates feature development and bugfixes.