An early post in this series introduced some of the distinctions between promoting from the sandbox via Salesforce Change Sets and Dynamics Solutions. After working with other developers on our team, discussions during deployment made me realize that there were some functional aspects we overlooked. Therefore, feel free to consider this an unofficial “Part 2.”
Flexibility
The most significant distinction between the two platforms deals with portability. A Dynamics Solution is exported as a zip file. Inside you will find an XML file that contains the script necessary to create everything included in the solution. Although definitely unsupported, you can theoretically (and yes, one or two times I have been forced to do this) alter this file and therefore alter the metadata that ends up in production.
Another feature of Solutions is the ability to import them into virtually any organization. It is as simple as importing a file from your local drive and deploying it.
Salesforce is more restrictive. Change Sets can move from sandbox to sandbox or sandbox to production, but only among connected organizations. In other words, just because I want to provide a fellow developer with a really cool new set of objects doesn’t mean she can pull them into her organization. Let me preface this by saying that I am limiting my discussion to what is available in the UI. There is a Metadata API option that allows more “creativity” but it requires a knowledgeable developer.
Let’s take a look at the functional differences of preparing metadata for promotion.
Global versus Granular
Before I jump into this topic please give me a few sentences to vent. Most likely I am not the only developer who, after explicitly telling the customer not to make any changes in production and review the entire theory of sandbox development … you know the rest. Needless to say, we are now left with a situation where production is out of sync with the sandbox. This is particularly painful when it comes to forms and page layouts as these are overwritten (as opposed to fields).
In my opinion, this is where Salesforce both shines and drives me temporarily insane. Starting with the positives, Salesforce allows you to be much more detailed in your selection process. Assume that you only added one field to the Account object. Simply create a new change set, add that field, and promote.
Dynamics operates on the entity level. You must include the entire Account entity in the solution … along with the good, the bad and the ugly. Now, there are some workarounds. You could first create a solution that contains the Account entity in production, deploy it to the sandbox, and then everything is in sync. For those who live on the edge, you can (gasp) alter the XML file and be ready to clean up your mess when things go south.
Preparing a Deployment
So far, Salesforce sounds pretty sweet. Now let’s take a look at an actual deployment and we will uncover the “less sweet” part.
In both cases we start out with creating a bucket in which to place our objects. Although the figure above is a very simple example involving only the account and a workflow rule, most deployments are much more complicated. To make my point, assume that we have been working feverishly on the account object, adding lots of fields, validation rules, new page layouts, etc. With Dynamics it is a one-step process: add the Account entity to the solution. Done.
Salesforce, on the other hand, breaks things out into component types, custom fields being one of them. Once you select the correct component type a list of fields appears in alphabetical order. The first issue is that you are presented with pages and not a scrolling list. My first recommendation is to click the link at the bottom of the page that expands the list, and keep clicking it until it is fully expanded. Even then you will still need page through the list.
Next, sort by Type and page through until all of the account custom fields are in view. Note, however, that as of the Spring ’15 release the object types are not in alphabetical order (very irritating). Next, check the box next to each field that needs to be included and finally click the Add to Change Set button. Repeat the process, selecting the next component type, and continue until everything is selected.
Once this is done, the rest is easy. If you are using Dynamics click Export. You will be prompted to add all dependencies. I avoid this at all costs as it bloats the solution. Note that if you fail to include a dependency that does not already exist in production the deployment will graciously fail. With Salesforce simply choose the destination organization and click Upload.
Have I Been Too Harsh?
My assumption is that your answer will parallel your allegiance. From a Dynamics perspective the Salesforce approach seems unnecessarily cumbersome, to say the least. The argument would be that it is better to promote an entire entity because you know everything will then be in sync and the chances of missing something are slim. The reality is that customers are always wreaking havoc in production and if you are not taking the time to validate the that production and sandbox are in sync then you are in a sense doing a disservice to your clients.
On the other hand, the concept of selecting only what you have changed to be deployed requires much better documentation of what we did change and that also takes time. The reality in this case is that Salesforce is really simple to configure and often there are multiple admins and developers making a huge number of changes. What is worse is they may be deleting things they just added, experimenting and not always remembering what made it into the final version.
Having worked in both platforms equally, I actually think that the Salesforce approach more suits my detailed nature. For some reason I just don’t like the idea of promoting an entire entity, and I lay awake at night wondering what would happen if I overwrote an entire form! As an aside, it’s never a bad idea to create a solution in production that consists of what you intend to overwrite. In the worst case scenario you can import that backup solution to production. With both platforms deployment never deletes what is there. Rather, it overwrites something if it already exists.
Deployment
As this post is running a bit long, I will defer to the “Part 1” post in this series to illuminate on this topic. To summarize, both platforms will not allow a deployment to proceed if it fails validation. Also note that this post has focused on, in Dynamics terms, “Unmanaged” solutions that once deployed cannot be rolled back. This is not the case for either of the platforms with third-party components.