Team development for Dynamics has always been a little vague topic.
To start with, it’s usually recommended to use SolutionPackager – presumably, that helps with the source control since you can unpack solution files, then pack them, then observe how individual components have changed from one commit to another. But what does it really give you? Even Microsoft itself admits that there is this simple limitation:
In that sense you might, of course, use git to merge various versions of the solution component files, but that would not be different from manual editing which, as per the screenshot above, is only partially supported.
The only real merge solution we have (at least as of now) is deploying our changes to the target environment through a solution file or, possibly, re-applying them manually in that environment using a solution designer.
That might be less of a problem if all Dynamics/PowerApps source artefacts were stored in CDS. But, of course, they are not. Plugin source code and Typescript sources for various javascript web resources are supposed to be stored in the source control. And even more – the solution itself would better be stored in the source control just so we don’t lose everything when somebody accidentally deletes the PowerApps environment.
So what do we do? And why do we need to do anything?
Apparently, developers are used to the best development practices, and, so, there is no wonder they want to utilize the same familiar Git workflows with Dynamics/PowerApps.
I am not sure I can really suggest anything magical here, but, it seems, we still need a way to somehow incorporate solutions into the Git workflow which looks like this:
https://www.quora.com/What-is-the-difference-between-master-and-develop-branch-in-Git ( although, I guess the original source is not Quora)
Come to think of it, the only idea I really have when looking at this diagram is:
- Creating a branch in Git would be an equivalent of creating a copy environment in Dynamics/CDS
- Merging in Git would be an equivalent of bringing a transport solution and/or re-applying configuration changes from the corresponding feature development environment to the higher “branch” environment
That introduces a bunch of manual steps along the way, of course. Besides, creating a new environment in PowerApps is not free – previously, we would have to pay for each new instance. If your subscription is storage-based these days, then, at the very least, you need to ensure you have enough additional storage in your subscription.
And there is yet another caveat – depending on what it is you need to develop on the “feature branch”, you may also need some third-party solutions in the corresponding CDS environment, and those solutions may require additional licenses, too.
At the very least, we need two environments:
- Production (logically mapped to the master branch in Git)
- Development (logically mapped to the development branch in Git)
When it comes to feature development, there might be two scenarios:
- We may be able to create a separate CDS environment for feature development, in which case we should also create a source code branch
- We may not be able to create a separate CDS environment for feature development, in which case we should not be creating a source code branch
Altogether, the whole workflow might look like this:
We might create a few more branches for QA and UAT – in that case QA, for example, would be in place of Master on the diagram above. From QA to UAT to Master it would be the same force push followed by build and deploy.
Of course there is one remaining step here, which is that I need to build out a working example, probably in devops…
PS. On the other hand, if somebody out there reading this post has figured out how to do “merge” of the unpacked solution components in the source control without entering the “unsupported area”, maybe you could share the steps/process. That would be awesome.
> PS. On the other hand, if somebody out there reading this post has figured out how to do “merge” of the unpacked solution components in the source control without entering the “unsupported area”, maybe you could share the steps/process. That would be awesome.
It is simply not (currently) possible to reliably, and automatically, merge an entire solution from multiple branches that have diverged from the same version – either by merging the alternate branches via the unpacked files on the file system, or by importing solutions from alternate branches into a target environment. If you were to attempt to do the merge, you would have to very carefully examine and test the merged results, and there would be a high risk of doing this improperly. If one cares about predictable results and only doing things that are certain, merging of solution components should not be done. This can be thought of the same situation in real source code files (e.g. C# or JavaScript files) as two developers making significant changes to the same lines within the same files, once you get a merge conflict the resolution of that merge is manual and difficult and needs to be done carefully and tested to be correct.
The only successful approach to working in an isolated environment per developer is for the solution(s) to be exclusively modified by one developer at a time, and changes committed to that solution’s unpacked files in a linear fashion. It is also important to plan out the solution segmentation to understand the dependencies between solutions and adjust the order of changes made to those solutions based on those dependencies.
The ability to successfully merge components would require Microsoft to drastically simplify the definition of solution components so that they could all be easily understood and modified by humans, by hand. Until that happens, sequential and exclusive access to making changes to solutions will be needed.
Hi Alan, thanks for the detailed comment – certainly makes sense. Still, I have a feeling some folks are using source control merge with the solution files. Would love to hear of how it’s been working out.
My comments are based on many experiences of merging causing problems that require the sequential and exclusive changes I’ve described, but sure, if someone has done merging successfully without problems, I’m all ears!
Sorry to resurect an old thread here, but I just wanted to say that I’ve been leading projects using source control merge successfully with D365/CRM for years.
The main challenge is that the output produced by the Solution Packager in a lot of areas isn’t stable; for example the components listed in RootComponents can be sorted differently on every export even if nothing has changed. A solution to this is to ‘normalise’ the output after the output has been produced to add this predicability of the order that elements/attributes/etc are written out in all the areas where order isn’t significant. (Like the actual merging, this is of course technically unsupported). Once this is in place each ‘commit’ (change set) becomes a lot cleaner and easier to merge, which means a lot less conflicts unless they are real ones.
Using a specialised XML diff/merge tool makes the situation even better when you do get conflicts as it will help you visualise what you’re doing better and avoid mistakes. Examples: Oso XML Merge, Beyond Compare.
I’ve recently shared a repo template which includes some of these ideas. It’s not the one that been tested over the many years (as I don’t have the rights to share that), but it shares the same basic idea:
https://github.com/rnwood/DataVerseALM
See common.ps1 normaliseCrmSolutionFolder function for the bit I’m talking about above.