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.
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:
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.
Connect with like-minded Atlassian users at free events near you!Find a group
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no AUG chapters near you at the moment.Start an AUG
We're bringing product updates and pro tips on teamwork to ten cities around the world.Save your spot