Best practices for risk-free Salesforce deployment

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:

• Business continuity: Even a small part missing, like an object or a validation rule, can break other parts of a Salesforce organization thus disrupting workflows, preventing users from doing their job, and compromising security. 
• Compatibility: The existing features and integrations can be incompatible with the new changes and cause serious malfunctions, as well as interfering with data synchronization and automatic uploading. 
• User adoption: New developments are there to make users’ lives better, but in many cases users experience difficulties with Salesforce adoption. For instance, they can require additional training when dealing with newly-developed functionality. 

Salesforce deployment dos and don’ts

To free deployment from its status of the riskiest Salesforce implementation stage, consider the following deployment best practices.

Do plan everything in advance

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:

• Know in advance who’s going to be on the deployment team and what tools you’re going to use: change sets, command-line tools, manual configurations, etc. 
• Plan a go-live for the least busy time with the majority of users off the system, like a weekend or a Friday night, to avoid work disruption. 
• Take into account how much time you will need for testing and manual configurations necessary when working with change sets.

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:

• Who will be deploying?
• What deployment tools are you going to use?
• When are deployments scheduled?
• Do you need to upload any data?
• How are you going to communicate the update?
• What’s the roll-back plan?

Don’t develop in production

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:

• Limit customization access to minimize the number of people allowed to deploy changes
• Restrict modification types for change sets
• Appoint an environment management team to review changes prior to deployment
• Provide every developer with their own sandbox

Sandboxes are a great tool for auditing and keeping track of developers’ work. There are a few types of sandboxes in Salesforce:

Developer sandbox

An isolated organization that copies metadata into a different environment for coding and testing. Multiple developer sandboxes get linked to a source control system.

Partial copy sandbox

The tool copies metadata and a portion of production data for integration testing and quality assurance and minimizes code overwriting risks.

Full sandbox

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.

Don’t skip testing

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:

• Apex classes and triggers work as expected
• Code coverage is at least 75%
• Apps going to production are of high quality

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.

Do implement code version tracking

Code version control allows tracking and documenting all changes at every development cycle stage, which provides:

• A single source of truth for all team members, so that they can access a detailed change history
• Parallel development streams with the possibility to deploy different code versions across development stages
• Notifications about code conflicts
• Continuous integration and delivery

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.

Do create a release management strategy

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:

• Create a complete release management process where each team member understands their role.
• Categorize releases into bug fixes, minor changes with no need for user training, and major changes with significant impact on functionality, dependencies, and adoption.
• Develop and test in separate environments, and migrate all the changes from every project to the same environment for integration.
• Make developers aware of other releases and their schedules, and provide them with version control tools.
• Identify areas of code conflict early in the planning and provide developers with communication tools.
• Avoid deployment during busy hours or major events.
• Release on a regular schedule so that users could plan their week by knowing, for example, that major updates usually come on Friday nights and minor ones on Tuesday mornings.

Do follow CI/CD practices

С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.