Best practices to organize repository structure for Dynamics 365 CRM Workflows/Plugins/Assemblies

Question

What would be optimal way to set up repository structure for CRM (Dynamics 365) project that should contain advanced features that are being implemented by Workflow Activity/Plugin code?

Would it be wise to have one repository for whole solution and inside, there would be separate projects for each Entity that should contain Workflow Activity or Plugin?

Good points to consider:

1. Building debug/release assemblies (.dll)
2. Updating Workflow Activity/Plugin via Plugin Registration Tool
3. Any limitations for pipelines
4. Maintainability of these Workflow Activities / Plugins

Answer 1

The way we manage our repositories changes as the tooling evolves, and is highly dependent on personal preference.

My approach is to store everything related to Dynamics/Power Platform in a single GIT repository, and focus on grouping items based on Power Platform solutions.

1. The repository will have a root folder for each Power Platform solution
2. Each solution folder will contain the source for web resources, plugins and custom workflow activities for that particular solution
3. Usually we export and unpack the solution from Dynamics/Power Platform and store in this folder (using the Power Platform CLI)
4. We usually store scripts specific to this solution in this folder (e.g. DevOps scripts).

We usually then have another root folder to store the generic DevOps scripts

For example:

• MyRepoName (GIT repository)
  • Build
    • SolutionDeploy.ps1
  • Solution1
    • Earlybound
      • Earlybound.cs
    • Plugins
      • PostCreateAccount.cs
    • Web Resources
      • Contact
        • information.ts
    • Workflows
      • ConcatString.cs
    • package
      • Solution1_unmanaged
      • Solution1_managed
    • Scripts
      • Config.ps1
  • Solution2
    • ...