Dynamics – setting up the dev process

The project I’ve been working on slowed down a little bit in the last few days, so I suddenly got some spare cycles.. And what do you do with the spare cycles? You spend them on something, preferably on something useful. So.. I started to do this:

It’s actually nice to take a break and just spend some time thinking.

Especially when the topic you have to think about is Dynamics, and, when it’s all about setting up proper development process.. there are certainly things to consider.

So, to start with, I came up with the following diagram:

It’s arguable whether it’s, actually, a standard process, but it’s a reasonable approximation.

And the important part which breaks it for Dynamics is that red “Merge” rectangle.

See, there are so many things in the Dynamics solutions that may have to be merged.. Just think about the entities, attributes, security roles, field security profiles, views, dashboards, applications, sitemaps, workflows, etc. We know that Dynamics supports merge, to an extent, for managed solutions. But, when it comes to unmanaged, and that’s what development teams have to deal with, there is little to no support. If Dynamics had some kind of out of the box merge resolution process, that would be great, but, since it does not, the only other option we have it to merge solution files as regular xml files.

And maybe we could do it, somehow, but this is where Microsoft warns us that we probably should not go too far, since editing of the customizations.xml file is, for the most part, not supported:

https://msdn.microsoft.com/en-us/library/gg328486.aspx

From that standpoint, even the solution packager can’t help that much. Here is another diagram I draw:

Yes, solution packager can split solution files into the individual components, and we can store them in the source control. But what do we do when we need to merge the updates applied by two different developers to the same individual component? Strictly speaking, we are stuck in that situation. Since, as I mentioned above, we are not supposed to edit the xml. We can still try doing that, but that’s, actually, a much more complicated process if you compare that to the merge we normally do for C# code, for example. You have to understand the structure of those files, and, even when you do, there is no guarantee you won’t mess something up if you just keep merging the files.

This is why, in the end, we either need to assume there will be “manual” merge, which is, really, all about re-applying the same configuration changes in the target environment manually, or we should try to avoid even the possibility of merge by using some sort of master configuration environment (for example, have a look at this post: http://gonzaloruizcrm.blogspot.com/2012/01/setting-up-your-development-environment.html )

That creates another problem, though. In either of those approaches the assumption is that all the configuration changes will be implemented in Dynamics. Which is fine until such time when you need to find out what were those changes, when they happened, and, possibly, who actually did them. That’s what source control solutions such as TFS or Git can do, but, again, Dynamics does not support TFS/Git natively.

Some of that is doable with the solution packager, though, so would it be possible to combine either of those two merge approaches with the solution packager so we could also track the history in the source control? In theory it should be possible, but I’ll need to set up a test environment to try it.. that’s for the next post, though, stay tuned!