We were on the phone with a Salesforce developer the other day and he said, you know you don’t even talk about the biggest use case that we use you for.
“Oh yeah?” we said. “Tell us more.”
As many Salesforce developers know, one of the biggest pains with Salesforce development is managing your data across orgs. Typically, developers and admins want to have some amount of data that they can use to test their Apex classes, custom objects and other Salesforce configurations. Unfortunately, it’s not very easy to upload this data into an sandbox. Developers spend a lot of time setting up, populating, and configuring data on their Salesforce sandboxes to make it possible to test their code.
The difficulty associated with preparing sandbox data puts pressure on developers to avoid refreshing Sandboxes. Of course, this is a problem, because refreshing sandboxes is a best practice.
The Salesforce Metadata/Data Paradox
A key reason that teams are moving towards DevOps and continuous integration is because they want to take advantage of the code quality enhancements that come with keeping test code and production code in tighter alignment. A best practice for Salesforce development is making sure that the metadata on your sandboxes closely resembles the metadata and code in your Salesforce production environment. This is a modern software development best practice and a key part of any team looking to move to an agile approach. Refreshing sandboxes achieves this aim.
However, now we have a paradox of sorts. On the one hand, you want to refresh your sandbox to keep the code in your production environment and sandboxes similar so you don’t run into code clobbering, merge conflicts or other problems. You want to ensure that the code and configuration changes that work on your sandbox won’t mysteriously break in production because of dependencies.
On the other hand, you don’t want to refresh your sandbox because you’ve spent a lot of time getting data uploaded and configured just the way you want it. Your data is a key part of testing and code quality. If you refresh your sandbox you will lose all of this data and have to start configuring it again from scratch.
Ultimately you end up like the cat i’ the adage who let “‘I dare not’ wait upon ‘I would’” or at the very least Hamlet as you ask: “To refresh or not to refresh, that is the question.”
Enter Blue Canvas
Fortunately, this doesn’t have to be an either or situation. With Blue Canvas you can quickly refresh the metadata on your Salesforce sandboxes without going through the process of doing a full sandbox refresh. This has several benefits. One you won’t lose your data configurations and you can keep coding. Two, you can refresh far more frequently than the Salesforce sandbox limits allow. Partial copy sandboxes can only be refreshed every 5 days. Full copy, every 29. But with Blue Canvas you can be continuously merging code to and from production in a way that ensures that your sandboxes have the latest metadata, code and configuration information up to the minute.
Refreshing metadata in Blue Canvas is simple. You can use our UI to create a deployment request between production or UAT and your staging sandboxes.
Or you can use the command line and simply pull the code down from production into your sandbox:
git pull salesforce master.
And this doesn’t just work from production to sandboxes. You can pull and push between any org. You can copy metadata from one sandbox to another or from Production to staging or staging to a sandbox and vice versa.
To learn more sign up for a free trial at https://bluecanvas.io/.