January 15, 2021
Table of contents
Salesforce makes app development accessible for users of different tech proficiency levels, providing both advanced and point-and-click tools. Salesforce deployment usually takes a fraction of the overall implementation time but if done recklessly, it can entail unpleasant consequences.
Any change deployed within a Salesforce organization can challenge the integrity of the entire infrastructure. It’s no wonder Salesforce consultants name Salesforce deployment one of the trickiest and riskiest parts as it can affect:
As a rule, Salesforce implementation starts in a developer sandbox. Then changes are pushed to the testing and staging environment, and once testing is done, the changes get deployed in the production environment.
There are three deployment options in Salesforce:
Let’s overview their characteristics and use cases.
A change set is a group of features, components, and customizations that can be moved from one Salesforce environment to another—from one sandbox to another or from a sandbox to production—and deployed.
It works like that. Two organizations are configured to send and receive changes between each other. The user chooses which objects in the source organization to deploy, thus building a change set right in the Salesforce UI. When a change set is created, it can be deployed in the target organization, where it’s possible to accept the changes. As a result, the two organizations will have the same metadata described in the change set.
By its nature, change sets are a friendly option for non-tech users and smaller companies who need to implement quick changes without developer assistance. At the same time, if there are a few environments and many people working on Salesforce development, change sets make it hard to cooperate. They don’t support release management control and version control, which might entail errors and chaotic change tracking. What’s more, change sets don’t support a number of object types like sales processes, email addresses, divisions, and more. So in order to complete a deployment, it’s necessary to move such components manually, which is an extremely cumbersome and error-prone process.
Metadata API is a set of objects that help manage customization information, or metadata, like custom objects or page layouts, in order to:
Metadata API is a great instrument for managing customizations and building tools that can manage a metadata model, not the data itself. Salesforce also provides Ant Migration Tool to simplify access to the Metadata API functionality.
Ant Migration Tool is a Java/Ant-based command-line tool used for process automation. It can help perform repetitive deployments that use the same components and can be scripted.
The Ant Migration Tool is designed for developers; less tech-savvy users would have to face a steep learning curve before grasping it. It requires considerable time and efforts but at the same time it provides greater control over deployment and supports CI/CD.
The tool comes in particularly handy in the following use cases:
Note that the tool can be used only in a specific development environment, so it’s not suitable for distributed teams.
into a seamless experience with Itransition.
To free deployment from its status of the riskiest Salesforce implementation stage, consider the following deployment best practices.
Say no to random releases and changes that can disrupt business continuity and confuse users. Instead, plan all the changes and their possible implications prior to going live.
The plan is particularly important when you work with multiple sandboxes at the same time. In such a situation, the plan lets everyone know what is going to happen and when, while keeping accountable the actors who initiate and implement changes.
It’s much easier to control your deployment and leave room for maneuver when you:
It’s also important to make sure in advance that you have the right data and calculate data loading time, as it can take a few days in case of legacy data migration. You also need to think how to communicate changes to end users to let them know when changes are coming, how to account for them when planning their day, and where to seek help in case of any difficulties.
One more essential point to consider when creating a deployment strategy is a roll-back plan. Sometimes things don’t work as expected and jeopardize continuity, so with the help of version control tools, it’s possible to get back where you’ve started, analyze, and fix errors.
To sum it up, it’s recommended to answer the following key questions when building your deployment strategy:
Some people develop right in the production environment, which means they don’t need to deploy. It saves time and money but this approach can work only for those companies that run minor customizations that don’t require IT help and additional development and staging environments.
However, in most cases, development in production entails certain limitations (it’s not possible to write Apex code in production) and destructive consequences and unexpected cascading effects (a modified workflow rule can create an infinite processing loop, or an edited field type can change data in a way that’s impossible to undo). For this reason, it’s highly recommended to develop any change, even a minor one, in a sandbox or a scratch organization, test it, and then proceed to deployment.
Consider the following tips to develop safely:
Sandboxes are a great tool for auditing and keeping track of developers’ work. There are a few types of sandboxes in Salesforce:
An isolated organization that copies metadata into a different environment for coding and testing. Multiple developer sandboxes get linked to a source control system.
The tool copies metadata and a portion of production data for integration testing and quality assurance and minimizes code overwriting risks.
The tool copies the entire production organization and data for coding and testing changes in relation to the entire live organization, thus minimizing possible errors.
Testing is a key procedure for securing successful Salesforce deployment and positive user experience. It’s recommended to run tests both during the production and after the deployment.
You can make use of the Apex testing framework to write and execute unit tests to ensure high quality of Apex code and reach all the requirements to deploy it, checking that:
At the Partial copy sandbox stage, run integration tests to ensure that updates don’t affect the functionality. When in a full sandbox, run user acceptance tests to make sure the changes meet user requirements, and performance tests to check response time and unintended effects on any of the organization’s aspects.
Salesforce also allows creating regression tests that can be triggered every time there are updates and ensure that these changes don’t break the existing functionality.
Additionally, consider implementing test automation to cut on manual testing and speed up releases. Automated scripts can run tests and immediately inform the developers whether their code is safe for deployment.
Code version control allows tracking and documenting all changes at every development cycle stage, which provides:
Salesforce sandbox development offers limited version tracking, so many Salesforce development teams go for a Git-based version control system which has become a number-one system for version control.
When developers work simultaneously in multiple environments (development, staging, or production), they need to plan and control their deployments. To establish good governance and run smooth deployments, developer teams need to have a proper release management strategy. Consider the following tips:
СI/CD practices speed up releases and provide space for flexibility and improvisation. Continuous integration and merging lets developers minimize bugs and dependency issues, and if there are still any, they will usually be smaller and can be easily fixed. As a result, you can deliver new features once they are developed and tested, without waiting for releasing them in one batch.
In Salesforce Developer Experience (DX), it’s possible to pursue the continuous integration approach by making use of scratch organizations—source-driven and disposable deployments of Salesforce code and metadata. When developers regularly integrate code changes into a source code repository, it’s necessary to ensure that the new code doesn’t contain bugs. Scratch organizations allow developers to use integrated third-party CI tools, like CircleCI, Jenkins, Travis CI, etc. for running automated tests for new changes, checking code coverage, and pushing deployment to a target environment.
If you don’t have a dedicated Salesforce development team and need your system to scale and run as expected while balancing time and budget, it can be a good idea to cooperate with Salesforce consultants. You will get a professional team with extensive experience in Salesforce implementation who can create a holistic strategy based on your company’s needs and plans for the future, develop both simple and sophisticated features, implement CI/CD practices, and successfully deploy changes, getting them in sync with the existing workflows and features.
This alternative approach can also serve as a shortcut to Salesforce adoption as it helps optimize the platform, make it user-friendly, and turn it into a collaborative hub for developers, admins, and users alike. This way, you can also easily enrich your default CRM functionality with capabilities offered by Salesforce alternatives.
United States
720 207 2820Sales inquiries