How a project team should approach the management of solutions for transfer between environments is a debated topic. In my opinion, there is no right or wrong answer – just the one that works best for the team and development approach. Each approach has its own pros and cons which I will cover in this article. Here are just some of the ways you can organize solution management within your team:
#1 – One Main Solution with Patches for Work Items
In this type of scenario, there is only one main solution and all future functionalities will be handled through patches. Once these individual patches are completed and tested, they are moved to the target environment.
Pros:
- Patches contain only the changed components.
- Each person has their own patch to work on their respective tasks.
- Easy to understand what was changed.
- Patches can be rolled up, therefore minimizing the number of solutions visible in the target environment.
Cons:
- There could be potential dependency issues when other patches contain changes to the same components.
#2 – One Main solution and Solutions for Work Items
Similar to the approach mentioned above but instead of creating patches; solutions are created for active work items.
Pros:
- Version numbers are not such a big deal anymore
Cons:
- New solutions are being created which cannot be rolled up on the target environment. This will result in many solutions laying around, often causing confusion.
#3 – Segmenting Solutions by Component Type
This is a simple approach also suggested by Microsoft in which there is one solution, for example, that includes all tables, another solution containing all plugins, and another containing all flows. These different components don’t have risks of cross-solution dependencies. Therefore, it is safe to have multiple solutions formed this way in the same environment.
Pros:
- Easy to use – plugins go in the “plugin solution”, webresources go in the “web resources solution”, etc.
- Easy to Deploy – any changes to a component is done and transferred within its respective solution.
Cons:
- Size eventually becomes a factor once there are more components added.
- Hard to do atomic deployments – what if someone is working on something in the solution which is not finished?
#4 – Segmenting Solutions by Name/Area of Functionality
Similar to point 3, however, instead of separating by component type we categorize by the type of functionality it introduces into the CRM. For example, everything related to the “Customer Service” functionality goes into the aptly named solution.
Pros:
- Easy to understand – gives more context to the solutions purpose
- Easy to deploy
- Smaller solution size
- Easier to manage partial deployments as a project team
Cons:
- There may be dependencies between solutions – it is difficult to separate components.
- Solution order is important during deployment
- higher risk of deploying something unfinished from another person working within the same solution.
I hope this gives you some good ideas or inspiration as a starting point. Again, I wont say either approach is better than the other, it just needs to fit how your team has decided to develop and deploy features.