Working with Multiple Salesforce Orgs (Part II)
In Part I, we talked about the basics of managing your orgs – establishing your rules of engagement and setting up your change pipeline. In this article, we take a deeper look at more advanced set-ups, and discuss some of the issues you might encounter along the way.
Hopefully by now you have a change pipeline in place which lets you experiment and test changes before releasing them to production. This works great when there’s one or two of you – what happens in more complicated scenarios, where consultants, developers, and admins all need to make changes to Salesforce?
The golden rule: one org per person
If you’re a developer or an admin, this is one rule that will help keep you sane: don't share your sandboxes. Unless you know exactly what's changing in the org, sharing your sandboxes can lead to misconfigured orgs, accidentally overwriting or affecting someone else's changes, and introducing hard-to-track-down bugs. Speaking from experience, it isn’t worth the pain.The good news is that with the recent Spring 16 release, all Enterprise Edition customers have been given greater quota of sandboxes, which should make it easier for your company to adopt this policy if they aren't already.
Giving everyone their own sandbox won't solve every problem, but it’s a great start. With each person empowered to make their own changes, the next step is to add an integration environment. The purpose of the integration org is to combine everyone’s changes together ready to go out to testing.
For Salesforce admins, some changes might be simply reproduced manually in the integration org. Other changes can be migrated through Salesforce’s Change Sets feature.
Salesforce developers can also use Change Sets, or a tool like MavensMate or Salesforce’s Ant-based Force.com Migration Tool. If you’re a developer attempting to use version control, you might want to pull down the metadata and handle the merge process there before pushing those changes to your integration environment.
How do I keep track of all these sandboxes?
Whichever way you end up handling migrations, you're going to want to keep track of the changes you’re making in your sandbox orgs. Try to keep these questions in mind:
- What’s changing in each environment on a daily basis?
- Has anyone “broken the pledge” and made a change in Production?
- Are the unit tests continuing to pass in each environment?
- Are environments diverging too much, making for a difficult deployment?
- If it all goes sideways, do you have a backup of the previous configuration?
Wrestling with our problems was our motivation for building Karabiner. Karabiner allows you to add your production org and all of your sandboxes so you can answer these questions. This gives you peace of mind and allows you to make change with confidence.
Liked this article? Follow us on Twitter for more updates and Salesforce advice.