Salesforce deployment best practices, key steps & useful tools

Salesforce provides several types of sandboxes, each with different data and file storage capacity, refresh intervals, and support for templates. Furthermore, not all sandboxes can copy both metadata and data. A sandbox strategy should clarify the types of sandboxes involved in each release stage based on tasks and data requirements.

• Developer sandboxes copy your production org’s metadata but not data. They can be updated once a day and have a limited storage capacity of 200MB compared to other types, which makes it a great choice for individual developers handling isolated coding and unit testing tasks. The Pro version expands storage capacity up to 1GB, enabling a wider range of tasks like quality control and integration testing.

• Partial Copy sandboxes copy both metadata and a portion of data selected via Sandbox templates. This sample set of live data enables you to test changes via integration testing, quality assurance, and UAT, and train users in an environment similar to the real-life one.
• Full sandboxes copy the entire production org’s metadata and data, so you should use them to test new changes with performance and load testing and UAT, and as a staging environment. Be aware that despite having the best storage capacity, their low refresh rate risks bogging down the development and deployment flow if used as a coding environment.

When defining your sandbox strategy, you should also consider the number of sandboxes used, their availability based on each Salesforce Edition, and alternative options to set up new sandboxes.

• Several developers can share the same or different sandboxes. A common sandbox makes integration unnecessary, but we still recommend using multiple sandboxes to let each developer modify metadata without affecting other developers’ work. Just make sure to verify the compatibility of components built in different sandboxes via integration testing.

• Different Salesforce Editions provide different numbers and ranges of sandboxes, so you have to choose accordingly. You still can purchase additional sandboxes, but keep in mind that their cost is based on the type, with the Full sandbox being the most expensive.
• Use Salesforce CLI to clone existing developer sandboxes instead of creating new ones from the production org, which takes longer. This allows you to preload the sandbox with data without using scripts.

Salesforce offers multiple native options to deploy changes between different orgs across your release pipeline. To adopt the most suitable tool, make a choice based on your deployment scenario.

• Change sets are packages of metadata changes (including workflows, rules, and permission sets) that can be selected and deployed directly using the Setup menu provided by Salesforce’s graphical user interface. However, this tool doesn't support version control, which can result in errors and change tracking difficulties. Consider Change Sets as a good option for non-tech-savvy users to deploy minor modifications without developer assistance.

• The Ant Migration Tool (formerly Force.com Migration Tool) allows users to access Salesforce’s Metadata API to move metadata between orgs. All interactions with Ant, such as the request to deploy Salesforce metadata, occur by inputting lines of text into a command line interface. Although the process is more complicated than with the graphical user interfaces, you gain greater control over the deployment. Choose this tool for extensive customizations that require repetitive deployments and will be performed by a team of developers.
• Keep in mind that according to a recent announcement, Salesforce will stop supporting Ant with new updates starting Spring ’24. If you opt for a command line tool, you can replace Ant with Salesforce CLI, which further expands Ant’s capabilities with commands to push and pull metadata to and from the orgs and convert metadata to SFDX format.

Testing is necessary to ensure successful Salesforce deployment, optimal software performance and smooth operation, and seamless user experience.

• You can write and execute unit tests using the Apex testing framework to ensure the high quality of Apex code and reach all the requirements to deploy it.
• Verify that code coverage is at least 75% and that Apex classes (templates to create objects) and triggers (actions automatically invoked by changes to Salesforce records) work as expected.

• Conduct regression testing to ensure that configuration updates or new deployments haven’t negatively affected the existing functionality. Additionally, consider adopting a third-party automation tool to trigger such tests without manual intervention.
• Regularly refresh your sandboxes to keep them in sync with the production org and avoid data/metadata drifts between environments, which can result in bugs after deployment. Also, tests executed in synced environments provide a more realistic indication of how customizations will work in the production org.

Code version control involves tracking and documenting changes at every Salesforce development and deployment stage, keeping a detailed change history and highlighting code conflicts or other issues to help fix bugs.

• Salesforce’s Setup Audit Trail shows the most recent setup changes (page layout customizations, permission sets created, etc.) made to your org, including the date of the change and who made it.

• Developers should identify areas of conflict between the local project’s components or in the org (such as a file modified by one developer and deleted by another) and resolve them before proceeding with deployment. You can adopt Salesforce CLI to notify you of conflicting changes, so that you can resolve them and then overwrite the local project or the org with the resolved file.
• Since many Salesforce development teams consider Salesforce’s version tracking capabilities rather limited, they often go for a third-party version control system. The most popular version control tool for Salesforce is currently Git, which enables developers to monitor all branches (lines of work) and commits (saved points in history) and resolve conflicts.

Active deliverability settings and validation rules, excessively permissive deployment policies, and the lack of rollback capabilities are key factors that can negatively affect the deployment process and thus should be addressed with due care.

• When new metadata is deployed to production, you may need to perform additional manual tasks, such as updating custom metadata, running Apex scripts to modify data, and testing changes on the production environment. To ensure smooth post-deployment processes without impacting live data or inconveniencing customers with unnecessary notifications, consider disabling email deliverability settings, certain validation rules, or any other configurations that could affect your post-deployment steps.

• Administrators should limit the number of users who have deployment permissions to minimize org exposure and the risk of inadvertent changes. Permissions requiring special attention include the 'Customize Application' Profile permission (allowing the modification of an org) and the Metadata API Functions permission (allowing access to metadata via the API).
• Salesforce orgs don’t store prior states and related metadata, which means that any changes you deploy can't be rolled back. To revert to a past configuration and prevent data and metadata loss, adopt a backup and restore strategy. This includes ensuring all changes deployed to an org exist in your version control system, so you can roll back to your last commit and deploy the previous version of the code. You can also create additional copies of your production org if deployment risks impact data (such as removing custom fields or changing field types).

By applying CI/CD best practices during Salesforce deployment, you can test, integrate, and deploy small change packages more frequently.

• Set up a CI/CD pipeline to deliver new changes once they are developed and tested instead of releasing them in one batch. This helps developers minimize bugs and dependency issues, namely changes in a system component affecting other parts.
• Using Salesforce Developer Experience, the set of tools to facilitate development on the Salesforce Platform, you can streamline the CI/CD process via scratch organizations. These are short-lived and disposable environments that are automatically deleted after some time. Scratch orgs enable quick deployment of Salesforce code and metadata to test and integrate small sets of changes.

• Developers need to ensure that code changes they regularly integrate into a source code repository don’t contain bugs. You can use integrated third-party CI/CD tools like CircleCI, Jenkins, and Travis CI to automatically test new changes, check code coverage, and deploy such changes to a target environment.