Unanswered

Solution Strategy

(2) Share

Report

Posted on by JasonSealy

I have been researching tirelessly to understand Application Lifecycle Management (ALM), Continuous Integration and Continuous Development (CI/CD), and data modeling for a small company I work for. I have a pretty good grip on the concepts but have some gaps of knowledge that make it difficult to deploy a plan for the company.

Context: Work for a small engineering firm that is looking to automate paper processes and have a secure database. I am a Computer Science Intern with some software dev experience but little Power Platform experience. I currently have 1 App and around 5 tables (in one solution) and am looking to scale that to 10+ apps and 30+ tables within the next year.

Questions:

1. I am finding it difficult on determining a good solution strategy. Most resources say to start with a single solution (which is what I have currently). I want to make sure there is room to scale, and I can imagine problems can arise if I am storing everything in a single solution. I need help understanding solution strategies , is it easy to transfer a single solution to multiple solutions down the line?

2. How does app updates happen in the production environment? When I import an updated app from dev to prod does the apps automatically update for users?

3. What ALM strategy to use. I have heard of manual ALM (what I am currently doing), then also ALM accelerator, Pipelines, and Azure Dev Ops (don't have subscription to this). Which one to use? I think I am going to try researching and using pipelines.

Categories:

Microsoft Dataverse with Power Apps

I have the same question (0)

All responses (6)

Answers (1)

Verified answer

Parvez Ghumra 1,579 Moderator on at

Like (3)

Report

Hi @JasonSealy

In response to your questions:

1. I would recommend having a single core/base solution which contains all your data model (ie. tables, columns and choices) for all apps, and then 1 separate solution per app which contains the app-specific components/customisations. This is an approach that works well generally speaking in my experience. If you are disciplined and organized with regards to management of your environments (including access control), your solution segmentation strategy and your deployments, then it really shouldn't be too difficult if you had to rethink your solution organisation approach later down the line after having established an initial baseline.
2. You will be deploying managed solutions to non-development environments. The changes come into effect for users immediately upon completion of the deployment of managed solutions
3. To get the most out of your ALM strategy, I would recommend getting set up with Azure DevOps or GitHub. I think you should be able to get at least some level of access to these for free. Both provide rich functionality to support comprehensive ALM scenarios. The ALM Accelerator and Power Platform pipelines are still fairly new and so will not support more advanced ALM capabilities (yet).

Let me know if you have any further questions

Was this reply helpful? Yes No
JasonSealy 65 on at

Like (1)

Report

Hello and thank you very much for your insight.
I think most of my confusion is still with a solution strategy. So if I am hearing you right, I would have a base solution with all the tables and such, and then create new solution for every instance of an app. In the solutions with apps I would add components specific to the app and all the required components from the base solution (effectively duplicating the tables from the base solution?). Since the dev environment has unmanaged solutions any changes to the tables would automatically update in solutions with apps? This strategy is intuitive to me however have more follow up questions to get a better understanding.

1. How are cross-dependencies managed with this strategy? In the Microsoft documentation it says "don't have two different solutions in an environment where both contain tables". Is this in-consistent with the strategy you posed?

2. (Slightly off topic) but the Microsoft documents say "For a healthy ALM approach, always use a custom publisher and not the default". Why is that? Link: Work with solutions using the Dataverse SDK - Power Platform | Microsoft Learn

Thanks, truly, any help is much appreciated.
Jason

Was this reply helpful? Yes No
Parvez Ghumra 1,579 Moderator on at

Like (2)

Report

@JasonSealy

For easier management of dependencies and avoiding solution layering issues in downstream non-development environments, as a general rule of thumb, each component that you build (either a custom one built from scratch, or customising an existing one) should only exist in a single solution. Therefore, your data model components (tables, columns etc) should only exist in the core/base data model solution. Your app specific solutions do not need to contain these components. Sometimes, however, the platform sometimes has a tendency to silently include dependent components into the unmanaged solution when you build something which introduces such dependencies. You will need to watch out for such scenarios and actively remove such dependent components from the solution to avoid issues during or following deployment.

At the time of deployment to downstream non-development environments, in order to avoid falling foul of dependency failures, you would always install the core/base data model solution first and then install the app-specific solutions(s) afterwards.

The use of a custom publisher will ensure that your solution and any custom components that you introduce in your solution have a unique name that is prefixed with an identifier specific to your publisher. This, then, means that your publisher is the 'owner' of such components in whichever environment the solution ends up being installed. For example, if a downstream environment has other solutions installed in it and these originate from different publishers, there's less of a chance of conflicts in component unique names.

Was this reply helpful? Yes No
JasonSealy 65 on at

Like (1)

Report

@parvezghumra
Thank you very much, your advice has been very helpful. I think I have understood that there is a lot that goes into developing the right ALM strategy for my needs. Many of the questions I have now are off topic to the original question but I will continue to look for resources and I appreciate your help to these questions.

Best of luck to you,
Jason

Was this reply helpful? Yes No
M-M 58 on at

Like (0)

Report

Hi @parvezghumra @parvezghumra question/confusion about your answer.

(this is basically related to my other post if you're curious/have thoughts :) - https://community.powerplatform.com/forums/thread/details/?threadid=cfb9554c-ba9b-ef11-8a69-6045bddbcca5)

Say you define a business-topic Solution full of stuff. E.g. "Weather App" Solution - containing all tables, business rules, forms, web resources, flows etc. Because it's the first deployment, and you're deploying it all at once. Deploying as Managed of course.

Say the business later wants a small change - just move some fields around 2 Forms.

Would you then create a new Solution, just for these changes, just for this Release. Or do you redeploy the entire Solution containing everything (as an Update or Upgrade)?

MS Docs state you should only include things you changed/specifically want to deploy in Solutions. So that seems to imply you need to create a new Solution per each Release/Deployment...

Was this reply helpful? Yes No
Parvez Ghumra 1,579 Moderator on at

Like (0)

Report

@M-M

I would not recommend a new solution for every change you want to make. Such an approach necessitates a change to your deployment logic/release pipeline definition for every change, introduces additional risk of failed deployments due to dependency issues and also introduces unnecessary solution layering complexity, giving rise to unexpected behaviour being observed post-deployment.

My recommendation is to stick with a single, baselined container solution containing all your changes which you add to/remove from incrementally. If you use the recently optimised 'Stage and Upgrade' deployment pattern, you will benefit from the smart-diff deployment logic, and assuming the delta is small, the deployment should be very quick (as long as you don't sent the 'overwrite unmanaged customisations' or 'convert to managed' flags. Even though you're deploying the entire container solution, in the example you gave, only the changes you included in the latest version will have an impact from a deployment perspective. Even the 'Update' deployment pattern will be relatively quick, but note that it is additive only and will not delete removed components.

Hope this helps

Was this reply helpful? Yes No