You’re offline. This is a read only version of the page.
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.
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
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.
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
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
Share
Report
65
All responses (
Answers (
