How to deploy metadata changes from sandbox to production in Salesforce
Written by Holly White
Deploying from a sandbox to production in Salesforce can be tricky. Not only does the Salesforce platform come with its own nuances, but custom objects and configurations add an extra layer of complexity. Whether you’re deploying natively with change sets or with a DevOps platform like Gearset, this post will show you what to look out for and walk you through how to deploy from your sandbox to your production org with ease.
What to watch out for when deploying from a sandbox to production
Teams can come up against a number of different issues when deploying metadata from a Salesforce sandbox to production. Sandboxes are a unique type of org – they’re designed to give ultimate flexibility in testing and are completely isolated from any of your other orgs. There are a number of best practices that apply to all deployments but there are a few additional things to keep in mind to help deploy successfully from a sandbox to production.
Type of sandbox
The type of sandbox you have can affect your deployment process. There are a few different types to choose from and all have their own characteristics and limitations:
Understanding the differences and limitations of each sandbox type can help you make more informed decisions and avoid potential pitfalls during the deployment process. Regardless of the sandbox type, proper planning, version control, and thorough testing are all critical to achieve successful deployments.
Sandbox management
Because your orgs are constantly changing, it can be tricky to keep your sandbox’s metadata closely synched to production. But if your environments don’t match up, you could introduce unexpected bugs and errors when deploying to production. To avoid this, it’s vital to keep your chosen sandbox as closely synced to your production org as possible by performing regular sandbox refreshes.
A sandbox refresh copies your production org, aligning the metadata (and data, depending on your sandbox) between your environments. This will give you a better idea of how changes will affect your live environment when they’re released and save you headaches when it comes to deployment time. Each sandbox type has a limit on how frequently you can refresh them, ranging from once a day to once every 29 days – but refreshing as often as possible is the best way to keep your environments as closely matched as possible.
Sandbox seeding is the process of populating your sandbox with test data, so you can test your changes before release. But it’s best practice to make sure no personal data from your production org makes it into your sandbox. Masking your data keeps sensitive production data safe while giving your team realistic data to carry out testing. This means they can release to production with the confidence that their features or changes will work.
Dependencies
The reason metadata can be tricky to deploy is because of the web of relationships and connections between components in your org. Forgetting to deploy these dependencies, or only selecting half, can cause huge headaches with failed deployments or complex error messages. These dependencies can be on anything from custom objects, Apex classes, triggers, and Visualforce pages and or even something as simple as a small permission setting. Deploying these components without considering their dependencies can cause deployment failures or your new changes to behave unexpectedly in production.
领英推荐
Apex code coverage
Salesforce has specific requirements for code coverage before any deployment to production, so if your deployment includes any Apex code you need to be cautious about code coverage and test classes. The minimum requirement is to have 75% of your Apex code covered by unit tests to be able to deploy to production environments. As well as this, all triggers need to have at least one line of test coverage.
API management
While API management is not directly tied to the specific process of deploying from sandbox to production in Salesforce, the API may indirectly influence areas of the deployment process. API versions are a key part of deploying successfully and without careful management the newer versions can cause confusion. You could start to see new differences in comparisons or experience a blockage when a validation or deployment fails. This is more of a risk when sandboxes are using a different platform version to your production org.
Difficult metadata types to deploy from a sandbox to production
Some metadata types are notoriously harder to deploy than others. We won’t list every single metadata type but here are some of the most common headache-inducers:
CPQ configuration
Salesforce CPQ deployments are well known for being difficult, with teams even trying to recreate configuration manually in the target org. Unlike other packages, CPQ configuration is stored as data, not metadata. That usually means you need a different tool and workflow to deploy CPQ than you use for metadata. If this sounds familiar, you can take the pain out of stressful CPQ deployments by using Gearset. Not only can you see all differences and dependencies clearly, but you can also deploy metadata and CPQ together in one deployment, not two.
Layouts
Deploying Page Layouts to Salesforce orgs can be so painful that many teams skip it all together. The biggest problem is that Layouts are large metadata items with lots of component parts, and most deployment tools only support deploying the Layout to Salesforce as a whole – in an ‘all or nothing’ approach. By using Gearset for your deployments, you can easily deploy specific components of Layouts rather than the whole thing – saying goodbye to manual workarounds and overwriting teammates changes.
Flows
Deploying flows in Salesforce can be awkward for a number of reasons but the one we hear time and time again is an issue with versioning. Each time you make changes and save them, you create a new version of your Flow in that org. To confuse things, the version number depends on the target org. If you iterate on a Flow in a dev org and end up deploying v5 to a target that currently has v2, it will be added as v3. Using Gearset helps you easily navigate these issues by helping you compare changes side-by-side, regardless of flow versions.
There are so many types of metadata and they all come with their own challenges. Gearset helps take the pain out of these tricky metadata types, and hundreds more, including Digital experiences (communities), Profiles and permission sets and custom objects and fields.
How to deploy changes from sandbox to production using change sets
This blog post was originally posted on gearset.com. Find out how to deploy changes from sandbox to production using change sets and Gearset here: https://grst.co/4cXYYwT