º£½ÇÌìÑÄÉçÇø

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’s 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, º£½ÇÌìÑÄÉçÇø really sidesteps the whole merging issue by having a deep understanding of your metadata. This understanding means that º£½ÇÌìÑÄÉçÇø 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 Migration Tool? Tricky, and very error prone.

With º£½ÇÌìÑÄÉçÇø it is nice and easy as we pull out each of the changes to Objects as separate components that you can deploy in isolation.

NOTE: º£½ÇÌìÑÄÉçÇø’s comparisons have had an upgrade! We’re updating all our blog posts with the new UI images — but in the meantime, you can learn more about what’s changed.

Here we can see the field in the Opportunity that I’ve modified to add some help text.

Here we can see the new field that I’ve added to 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.

This powerful new approach, that only º£½ÇÌìÑÄÉçÇø 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 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.

Merge your metadata with ease

To get started with º£½ÇÌìÑÄÉçÇø, and try the only Salesforce metadata deployment solution that has true understanding of your orgs,