Setting up and configuring data in a sandbox can be a fairly tedious and unpleasant experience. Typically, I just create some data in a sandbox in a way that is quick and simple. For example, I will create numerous “test” accounts with random values. It can be difficult to invest a lot of time creating proper data because when you refresh your sandbox everything is lost. This sets up a suboptimal experience: either my data is low quality or my metadata is out of date.
You Should Refresh Sandboxes Frequently
Frequently refreshing Salesforce sandboxes is a best practice and one that Salesforce developers should seriously consider doing regularly. Sandbox refresh limits depend on the type of sandbox (e.g., Full Copy sandboxes can be refreshed every 29 days, partial copy sandboxes every 5 days). Typically, I see Salesforce development teams refreshing far less frequently than they are allowed to.
Sandboxes are meant to be copies of your production environment. Salesforce provides sandboxes so you can make changes and test them in an environment that is removed from your production users. But a key part of ensuring that your changes are safe is making sure that your sandbox is a close approximation of production. If the sandbox diverges from production too much, then you cannot be confident that your changes will not break in production. There are too many dependencies in Salesforce that you need to look out for. How can you be confident the change you made will work in production and not fail because of dependency issues?
One of the key benefits of doing continuous integration for Salesforce is ensuring that you make frequent small changes that you can be confident in.
Refreshing your sandbox ensures that the code and configuration settings in production are mirrored in your sandbox.
Much like having up to date metadata, having good data in your sandboxes will solve a number of headaches down the line. Having high quality data allows you to quickly and efficiently test your code and configuration changes before you release to production. Spending time getting data set up correctly will save time when you are actually developing features. It’s worth to set up data that covers all of your edge cases.
From what we have heard at Dreamforce, Salesforce DX is supposed to help make data configuration much easier. You will be able to upload data via JSON. In the meantime, we can use source control to resolve the metadata/data conflict.
Using Source Control to Keep Metadata in Sync
One way to have the best of both worlds – properly configured data and up-to-date metadata, is to use source control to keep your metadata in sync with production without resorting to a full sandbox refresh. There are two ways to do this.
The first is to use the Force.com migration tool to bring your changes into Git. You can write Ant scripts that pull down metadata changes and commit them into Git. While this is technically a “free” option, it can be time consuming and expensive from a time perspective.
You can also use a hosted solution like Blue Canvas to automatically provide this functionality for you. Blue Canvas automatically takes your Salesforce metadata and commits it into a Git repository. You don’t have to do any maintenance or setup. It then allows you to migrate your code and configuration changes from production to sandbox without overwriting your data.
Either of these options is a great way to solve the paradox laid out at the beginning of the post. Using source control you can ensure that the test and development data on your sandboxes is of high quality while also ensuring that the metadata on your sandboxes mirrors your actual production environment, making your Salesforce release process faster, smoother and of higher quality.
Jack Moxon is a co-founder of Blue Canvas source control tool for Salesforce which among other things can quickly refresh the metadata on your sandboxes