Struggling with Salesforce orgs that are out of sync? You’re not alone - it’s a problem that troubles many Salesforce teams. In this post we’ll take a good look at how to keep your orgs in sync: why it matters, the challenges, and the best solutions.
Out-of-sync orgs are a common problem
Several devs and admins responding to Gearset’s State of Salesforce DevOps survey highlighted this challenge:
- “Keeping multiple orgs in sync is a real challenge.”
- “A large project with consultants has made it difficult to keep environments properly in sync.”
- “We have problems with sandbox and production org desynchronization.”
- “Our UAT org is way different from PROD!”
- “With multiple teams releasing separately our sandbox refresh schedules conflict.”
- “We’re struggling to refresh and get data into our partial sandboxes on a set time frame.”
Why Salesforce environments get out of sync
Your Salesforce environments constantly change as you build features, deploy them along your release pipeline, and finally release them to your production org. Over time, more and more metadata differences between your environments begin to appear. There are three common ways orgs get out of sync with each other, in terms of metadata.
- Abandoned projects. The whole point of sandbox and developer orgs is that you can click around, building and testing customizations without worrying too much about the impact. But any changes you try out and then decide not to deploy can quickly clutter up your sandbox.
- Teammates’ work. If you and your teammates all have your own developer orgs, the chances are they don’t look alike. At some point your changes are being integrated for release. But do you deploy your teammates’ work back to your org? If not, it’s hard to be sure what you’re building will play nicely with the apps and features others have been working on.
- Hotfixes. At the other end of your release pipeline, any hotfixes made directly in production won’t appear in upstream environments unless you deploy them back. That means there’s a risk your hotfix will be overwritten or deleted during a release later on.
Keeping on top of the datasets in different orgs is also a challenge, as data is constantly being added to production by your end users. The datasets in your testing environments can quickly get out of date.
Why does syncing up orgs matter?
Keeping your environments in sync stops you hitting issues with releases. Synced orgs lead to:
- More reliable testing. If you’re testing work in a sandbox that isn’t in sync with production, then you won’t discover every problem before releasing that work. There might be an edge case that causes your work to fail in production.
- Decluttered comparisons. If you’re using Gearset’s comparison tool to see the metadata differences between your orgs, having orgs that are massively out of sync will throw up a huge number of differences, and you’ll need to search carefully for the changes you really care about.
- Easier deployments. The likelihood of deployment success between out-of-sync environments is lower because the metadata in your target environment may not be the right shape to receive the deployment package.
- Successful automation. Adding automation to your release pipeline using continuous integration jobs relies on environments that are in sync. CI jobs are designed to automate frequent deployments of incremental changes. The more metadata a CI job is trying to deploy, the more likely it is to fail.
The limitations of Salesforce’s sandbox refresh
There are different tools you could consider using to sync up your environments. Refreshing a sandbox in Salesforce is the traditional way to get it in sync with your production org. Running this process brings the sandbox’s metadata in line with production and, depending on your particular setup, it may update the data as well. This can be an effective option, especially if your orgs are really out of sync.
Refreshing a sandbox does come with some dangers and drawbacks.
- There’s no visibility into what you’re overwriting in the sandbox, so you might accidentally lose development work that hasn’t yet made it to production.
- Salesforce can take several days to complete the refresh, during which time you won’t have access to your sandbox.
- Salesforce limits how often you can refresh your sandbox.
- The refresh isn’t strictly a migration to your existing sandbox; it tears down the old sandbox and replaces it, which means your sandbox will sometimes ‘move’ to a different Salesforce instance.
- There are quirks in Salesforce that mean your refreshed sandbox isn’t always an exact copy of production.
- This process is only available for sandbox orgs, not developer orgs.
If you’re a small team with a slow release cadence and a simple release pipeline of a few orgs, then Salesforce’s sandbox refresh might meet your needs, but most teams need more powerful tools.
Get your orgs in sync using Gearset for deployments
Gearset can immediately bring visibility, control and speed to your sandbox refresh process, even if you haven’t yet adopted DevOps. Here’s how:
1. Compare your orgs
Run a comparison in Gearset with production as the source and the sandbox as the target. Make sure you select Compare all in the metadata filter, and bear in mind that this comparison will take a while to complete because Gearset’s is comparing all of the metadata in your orgs. As batches of metadata are compared, you can browse the results in real time and quickly get a sense of how badly your orgs are out of sync.
2. Analyze the differences
This kind of comparison with production as the source is the reverse of a typical comparison where you’re looking to promote changes along your pipeline. In this case, the New items tab shows you any metadata in production that isn’t in the sandbox, i.e. any changes that have been made directly in production as a hotfix or bypassing the official deployment process. The Deleted items tab shows you metadata in the sandbox that isn’t in production.
The Changed items tab shows you the metadata items that are in both environments but have been modified or differ in some way. If your team has been following the right development process, production should have the ‘correct’ version of this metadata, but be sure to check that there isn’t any development work in the sandbox that hasn’t been deployed yet. Gearset’s filters in the Changed on column will help you identify the most recent work.
3. Decide whether to refresh
If your orgs are badly out of sync, Salesforce’s sandbox refresh is probably your quickest option. Remember to rescue any changes in your sandbox first, if you spotted anything in the comparison view that you want to keep. After you’ve refreshed the sandbox, run another comparison in Gearset. A refreshed sandbox isn’t always totally in sync with production, and Gearset can help you get them closer.
4. Deploy metadata
If your orgs aren’t too badly out of sync, you could select all the changes in the comparison view (assuming you’ve not identified anything in the sandbox you should keep) and deploy them using Gearset. The larger a deployment, the more likely it is to run into problems, so you might want to break things down into multiple deployment packages.
5. Deploy data
Keep your orgs in sync using Gearset for DevOps
Getting your Salesforce environments in sync is one thing; keeping them in sync is another. One of Gearset’s customers, The Leading Hotels of the World, used to spend precious time syncing up their Salesforce orgs every 6 months - but no longer. The solution for them and so many other businesses? DevOps.
Version control, which underpins the DevOps process, is designed to keep everything in sync. Teams using version control have a new source of truth: not production, but their main branch in Git. Developers can create a new feature branch from the main branch, commit work to this feature branch, and then ultimately merge it back into main after testing and review. Everything in Git is synced up with each cycle of that workflow.
Even when using version control, developer orgs can get out of sync from the main branch and each other if changes aren’t deployed back to these upstream environments. It’s all too easy to skip this step when you’re working in Salesforce orgs, because it calls for yet another deployment in your workflow.
Here’s where setting up CI/CD using Gearset’s pipelines tool is a game changer. Whenever you promote changes along your release pipeline, Gearset will automatically create a pull request against upstream environments, which you can accept at the click of a button and effortlessly keep everything in sync.
You should also set up a monitoring job to catch any changes made directly in production or released outside your established DevOps process. Choose whether to remove those changes or sync them up to your main branch - and from there to all your other orgs.
How devs and admins describe the solution
Our DevOps survey reveals that plenty of teams have solved this problem!
- “More easily syncing environments is a huge plus of DevOps!”
- “DevOps has reduced the number of items lost in a refreshed sandbox.”
- “We use change monitoring to identify production-only changes that we sync down to a sandbox if needed.”
- “With Gearset we can keep the lower environments more in sync.”
- “As well as saving time in deployments, Gearset also helps us keep our orgs in sync.”
- “We save hours with the ability to refresh sandboxes more often, since we don’t worry about losing important work.”
Say goodbye to that syncing feeling
If you’re new to Gearset and would like to try syncing your orgs, you can start a free trial today and get full access to all of its tools. If you’re already a Gearset user but haven’t started using all of the tools described in this post, get in touch with us via the live chat on this page. You can find out more about the benefits of using Pipelines to set up an automated release process for Salesforce here.