How do you handle Sandbox refreshes as part of the SF Development Workflow?

[Melanie Wright]

We refresh our sandboxes occasionally - when we get new feature activations in production, adjustments to config that we find easier to make in prod than to try to deploy via metadata (roles, for example), etc. 

Day-to-day, we keep our individual sandboxes up-to-date by sync'ing down changes backed up from production to the sandbox repositories. When we create a feature branch off the devsb master, we compile/deploy the code to our individual developer sandboxes as soon as we create them. I'll usually do a clean afterwards and check out the difference in SourceTree to see if there's any lingering new metadata from a previous feature release. We also may need to perform some of the manual release steps (like adding new default data) from other teammates' feature development in our sandboxes to keep in line with what's in our deploy pipeline.

Sandbox Setup

We found we had a lot of steps to take to get a fresh sandbox populated with the basic data we need for us to work and tests to pass. We've created a class that helps us out - SandboxSetup - and we run a few methods in there to get our sandboxes into a standard ready-to-go state. 

As part of our releases, we may need to add some default values so we:

1. Add a new method to SandboxSetup class to populate the desired records/settings
2. Add instructions to call the new method to the JIRA ticket for the feature under Release Instructions
3. Optionally Add the new method to the setupDevsandbox methods that we call whenever we activate a fresh sandbox.

Other Ideas...

I met Rocky Assad at Dreamforce and he pointed me to his jar which compares/sync's two orgs: https://github.com/fourq/sf-deploy-and-destroy - looking forward to checking it out more and seeing how we can use it here at Atlassian!

I've also heard of folks that automatically create new sandboxes for each new feature they're developing. We aren't there yet but sounds handy.