Merging Salesforce metadata: How to merge Custom Objects and other Salesforce metadata

Kevin Boyle on February 15th 2016


One of the issues that commonly crops up when working together on a team is merging metadata or deploying only a small part of the work you’ve done.

This often happens if you have more than one developer working in a single developer sandbox, and is almost unavoidable when you work on a larger team with everybody in their own sandboxes.

So what is the best way to merge complicated Salesforce metadata?

With Salesforce metadata and configuration data, there are a few different things that people refer to when they say merging.

  1. Reconciling the differences between Apex classes and VisualForce pages in different environments.
  2. Reconciling the differences between Salesforce objects in two different environments. These differences might require you to deploy only one field to an org, or deploying Profile changes to an org without overwriting the changes that were made directly in production

For the first case, code has too much meaning and relies on knowledge that only the developer has to just automatically merge the files. You really need to get the Apex or VisualForce from both sandboxes, and then manually reconcile the differences using something like KDiff or Eclipse. It is too risky to do ‘best-effort’ and end up with an Apex class that doesn’t compile! Thankfully, due to the power of Salesforce, most of the time you aren’t writing actual Apex classes and conflicts here are rare on most teams.

For the second case, Gearset really sidesteps the whole merging issue by having a deep understanding of your metadata. This understanding means that Gearset can deconstruct Salesforce objects into their constituent components, and stitch them back together effortlessly so you don’t need to merge anything.

Let’s take a concrete example.

I have made two changes to the Opportunity object in my development environment, only one of which I want to move to production. Unbeknownst to me, my colleague has made a third change to the same object directly in production that I don’t have in my development environment.

Here we have three changes made to the same object, only one of which I want to move. How would I do that with Change Sets? How would I do that with the Force.com Migration Tool? Tricky, and very error prone.

With Gearset it is nice and easy as we pull out each of the changes to Objects as separate components that you can deploy in isolation.

Here we can see the field in the Opportunity that I’ve modified to add some help text. Gearset showing a change in the Opportunity object

Here we can see the new field that I’ve added to the Opportunity object. Gearset showing a a new field in the Opportunity object

It is then very easy for me to select just the changes that I am ready to promote to my production environment. Of course you may need to include Profiles or any other associated dependencies or changes in the package so you can deploy with confidence.

Gearset showing a change in the Opportunity object

This powerful new approach, that only Gearset offers, removes a whole class of error that other deployment solutions need to deal with, and it does it all while still building on the Force.com Platform and the Salesforce Metadata API.

To summarise, if you find your deployment process requires you to think about merging and manually reconciling differences in your Salesforce metadata, then it is time to rethink your process.

To get started with Gearset, and try the only Salesforce deployment solution that has true understanding of your orgs, click here.

Ready to get started with Gearset?

Sign up now to start your completely free 30 day trial
try it now