ALM Managed solutions best development practices

[Anonymous]

Hello everyone,

I am new to the forum and I would like to know your opinion about some doubts about team development and ALM that I have right now since, during the short time I have worked with Dynamics 365 (just 1 year) and due to the projects, I have always worked with unmanaged solutions.

I am currently developing a system with Power Platform and Dataverse. After some reading about managed solutions and understanding how the layer system and patches work, I have some doubts that I can't find through forums or videos:

Let's assume the following scenario. After a first initial development in the development environment, the solution is exported to the test and production environments. From now on, additional developments of this solution are going to be carried out in which several developers will work . Obviously, it can happen that there are several developments in parallel and at the time of uploading to production some of them are not complete.

1- How do you usually work in these situations? Do you use patches, clone solutions, or create new solutions for these new developments? For me, it does not make sense that each development is a patch of the original solution because, in case you want to upload some of these completed developments while the rest are not finished, it would not be possible to clone the solution because it would merge all the patches with incomplete developments. But on the other hand, there will come a time when, if new developments are cloned with the original solution, and moved to production environments, it will be very large and will take a long time to be imported into the environments.

If you continue to develop functionality related to this solution, how do you work on it? How do you work with several parallel developments that affect the same solution to move them to production?

2- Do you always move the entire solution to production environments? In any case other than a hotfix on a large solution is it better to carry a patch than the solution itself?

3- If anyone knows of any post that talks about good ALM development practices or has ideas on this subject that deals with deeper or not so basic topics, I would be interested and I would appreciate it so much.

Thank you very much,
Best regards.

[parvezghumra]

Hi @Anonymous 

You raise some very valid questions and a lot of these are common challenges faced by many teams working with this platform. For a lot of these, there's no right or wrong answer and you need to work out the approach that best suits your needs. But here are a few points that might help

1. Ensure that all customisation and configuration changes are committed to source control, and all members of the team are committing their changes to source control regularly when stable

2. Make sure you have a suitable branching strategy in place. Each branch that can support a deployment route to Production should be supported with (at least one) development environment which will act as the source of changes for that branch. This approach will allow you to separate our new build/development efforts occurring on the main/dev branch (for example), from fixes (bug fixes, hotfixes) occurring on the hotfix branch.

3. Your team will need to know the purpose of each branch and work accordingly, making sure they make changes in the correct source environment and replicate changes on multiple environments/branches as required

4. Ensure you have a suitable solution version numbering convention established which will allow you to promote releases from either your main/dev or hotfix branch through to Production.

5. If your team members work in central, shared development environments, they will need to commit changes to source control in sync with other other and each commit will potentially include changes from multiple team members. Therefore, close collaboration and communication is key to make this process work. Unfortunately, this does mean that changes owned by different team members are combined into a single commit and are not isolated. However the benefit is that it simplifies the developer process.

6. If each team member has their own dedicated development environment, you will need to contend with additional maintenance overhead in ensuring each environment is kept up to date in line with changes committed to source control over a period of time.

7. Microsoft were actively discouraging people from using Patch solutions at one point due to the deployment complexities they introduced. I don't know if this advice is still valid, but based on my past experience, I also stopped using patch solutions around the same time, because I found that each patch solution is actually a unique solution and, therefore, introduces it's own layer in the solution layering hierarchy. In some scenarios, that meant that changes in each layer did not merge as expected. In addition, using patch solutions also introduces other limitations (eg. locking down of changes in the base solution, inability to delete components as part of a patch deployment, etc). Since then, the approach I have taken is to generate a new solution version as part of the build for each main/base solution whenever a change is committed to source control. This obviously means a full solution deployment which can take some time, but we have mitigated against this by performing deployment out of normal office hours to minimise business disruption.

Also here's a few links that might help:

https://benediktbergmann.eu/2020/02/10/cds-basic-alm-process/

https://github.com/LuiseFreese/PP-Good-practices/blob/main/ALM/setup-ALM.md

https://jonasr.app/alm-a-la-rapp/