cancel
Showing results for 
Search instead for 
Did you mean: 
Reply
Dlabar
Most Valuable Professional
Most Valuable Professional

Unmanaged to Managed Solutioning Strategies

I'm starting my first project where I'll be using managed solutions.  In my unmanaged solutioning, each release I create a new solution, and put only the changes that have been made into that solution, and then deploy through the environments.  Can I just do the same thing in a managed sense?  Or should I be having a single managed solution that contains everything that I deploy each release?  This seems wrong to me.  I know I could use patches, but then at what point should I do an Upgrade vs another patch? I've also seen different projects where solutions are divided up, Tables/code/other/etc.  Is that helpful as well?  And if so, how do I not create issues with inter managed dependencies?

1 ACCEPTED SOLUTION

Accepted Solutions
ScottDurow
Memorable Member
Memorable Member

Why does it seem wrong to deploy the same managed solution with each release? This is the simplest to manage and I usually will try to use this approach. Many of the problems I see with managed solution deployments is not to do with it being managed - but because the managed solutions are being treated in the same way you might for an unmanaged - but they are very different.


In general - the smaller the number of solutions the easier to manage. Only segment where it has a real benefit and you are prepared to manage that solution in it's own deployment/version ALM.
The safest approach is to have each managed solution managed in it's own source dev environment/repo - with the other managed dependencies installed as managed pre-requisites. You might have a core solution and then a department solution - so you'd have a an environment to manage the core solution - and then another for the department solution that has the managed core solution installed. But you'd only want to do this if you needed to deploy the core to multiple orgs with different layered solutions, or you need to have a separate deployment/versioning ALM cycle for the different parts.

Segmenting is quite a complex area and there are some 'short cuts' such as having a single environment/repo to manage segmented solutions that have flows/apps and another solution for the core tables etc - but the safest is to have a separate environment for each segmenting managed solution.

Again - I can't stress enough - only segment where there is a benefit in terms of re-use or deployment/versioning autonomy. A good example of this is in the 1st party dynamics apps - where they have common solutions and then addition solutions for the various apps and even solutions for some of smaller features within the apps (e.g. apps/pcf/webresources/flows/plugins). This allows deployment/versioning of a very complex set of functionality in separate parts - and then potentially patched in parts - but there lots of complex management of the development of each of those solutions. If you are a small team then this approach is going to be hard for you to maintain and support.

 

The main reason people usually give for not having a single solution is the time it takes to deploy. There has been lots of work in this area and the import time is much better than it used to be for updates (not upgrades)- and constantly getting better.

Imho - unless you are a large organisation with many developers and a large number of environments/solution components with different release schedules,  the complexity introduced by solution segmentation does justify the benefit of the decreased import time. The only exception to this is around segmenting for components that don't introduce solution dependencies since they can be managed in the same environment. 

 

Patches are an option to reduce deployment time - but again it introduces more complexity and make ALM very difficult because you can't easily diff between solutions - for this reason I don't use them unless there is out-of-band deployment/hotfix. Once you've patched - you'll then need to do an upgrade at some-point.


From Create and update custom Power Apps solutions for ALM - Power Platform | Microsoft Docs:

"Using clone a patch and clone solution to update a solution isn't recommended because it limits team development and increases complexity when storing your solution in a source control system. "

 

Hope this helps

View solution in original post

11 REPLIES 11
ScottDurow
Memorable Member
Memorable Member

Why does it seem wrong to deploy the same managed solution with each release? This is the simplest to manage and I usually will try to use this approach. Many of the problems I see with managed solution deployments is not to do with it being managed - but because the managed solutions are being treated in the same way you might for an unmanaged - but they are very different.


In general - the smaller the number of solutions the easier to manage. Only segment where it has a real benefit and you are prepared to manage that solution in it's own deployment/version ALM.
The safest approach is to have each managed solution managed in it's own source dev environment/repo - with the other managed dependencies installed as managed pre-requisites. You might have a core solution and then a department solution - so you'd have a an environment to manage the core solution - and then another for the department solution that has the managed core solution installed. But you'd only want to do this if you needed to deploy the core to multiple orgs with different layered solutions, or you need to have a separate deployment/versioning ALM cycle for the different parts.

Segmenting is quite a complex area and there are some 'short cuts' such as having a single environment/repo to manage segmented solutions that have flows/apps and another solution for the core tables etc - but the safest is to have a separate environment for each segmenting managed solution.

Again - I can't stress enough - only segment where there is a benefit in terms of re-use or deployment/versioning autonomy. A good example of this is in the 1st party dynamics apps - where they have common solutions and then addition solutions for the various apps and even solutions for some of smaller features within the apps (e.g. apps/pcf/webresources/flows/plugins). This allows deployment/versioning of a very complex set of functionality in separate parts - and then potentially patched in parts - but there lots of complex management of the development of each of those solutions. If you are a small team then this approach is going to be hard for you to maintain and support.

 

The main reason people usually give for not having a single solution is the time it takes to deploy. There has been lots of work in this area and the import time is much better than it used to be for updates (not upgrades)- and constantly getting better.

Imho - unless you are a large organisation with many developers and a large number of environments/solution components with different release schedules,  the complexity introduced by solution segmentation does justify the benefit of the decreased import time. The only exception to this is around segmenting for components that don't introduce solution dependencies since they can be managed in the same environment. 

 

Patches are an option to reduce deployment time - but again it introduces more complexity and make ALM very difficult because you can't easily diff between solutions - for this reason I don't use them unless there is out-of-band deployment/hotfix. Once you've patched - you'll then need to do an upgrade at some-point.


From Create and update custom Power Apps solutions for ALM - Power Platform | Microsoft Docs:

"Using clone a patch and clone solution to update a solution isn't recommended because it limits team development and increases complexity when storing your solution in a source control system. "

 

Hope this helps

cchannon
Multi Super User
Multi Super User

Excellent topic that not nearly enough people take the time to dive into, IMO!

 

There are a lot of considerations to make when you jump over to managed solutions. It definitely introduces new risks to your process, but it also delivers some really excellent benefits at the same time.

 

My best advice is to start by thinking about the classic stratified visualization of solution layers (see my terrible MS paint skills below): As any component in Dataverse gets returned, it is evaluated against each of your solution layers in order, going from the oldest to the newest managed layers then finally the unmanged layer. 

cchannon_0-1617297223907.png

Layering managed layers therefore gives you the ability to have an almost polymorphic control of your solution components where you have mgd solution 1 define an entity "animal", then managed layer 2 says that animal is specifically of type "mammal" and managed layer 3 says that animal-->mammal is specifically of type "ape". This is a really powerful tool when you are mixing together customizations from multiple sources or teams, but if you only have one source definition (this project's dev environment) then it might just be overkill.

 

"but what about ease of deployment and only moving the newest customizations?" With an unmanaged solution you are always dumping to the same default solution so you can easily just add in the things you've changed and toss it from org to org, but with a managed solution this is less straightforward. You don't want to remove content from your solution just to minimize it (what a management headache!) but you also don't want a ton of managed solutions floating around your higher environments. Skipping right past the fact that it is ugly, when you have multiple managed solutions that contain references to the same components, it becomes very difficult to ever remove those components; say you have field X in mgd solution A and mgd solution B, now you want to remove it from the system. You remove it from A and go to import as an upgrade. but--oh no!--the import fails because you can't delete a component required by another managed solution. You remove it from B and try again, but still no luck because it is required by A! This kind of headache happens more often than you might think because a big advantage of managed solutions is that you can do these subtractive "upgrade" pushes which unmanaged solutions don't let you do. So, we're left with promoting this same managed solution again and again or, as you suggested, Patches.

 

Patches are an excellent tool, although I think they are no longer the 'preferred' approach of MSFT and may eventually be replaced with something more functional (that is still a long way off, don't worry). A Patch gives you the best of both worlds: it lets you stack managed layers on top of one another in a way that makes them very easy to remove if you want to back out a release, but also sets them up to be cleaned up eventually so you don't wind up piling up conflicts over time and making future subtractive releases unnecessarily difficult. When you generate a patch, what you're doing in your source system is creating a new unmanaged solution that is linked to your main unmanaged one, and when you export it and import it into the new org, it does not merge them, but stacks them so you get your changes, but can also easily back them out. The "Upgrade" you refer to is when you decide that all your patches are rock-solid, the solution is clean and there is no chance you will need to roll any of them out, so you are ready to again call it just one managed solution. You clone as Upgrade and it will consolidate your base solution and all patches into one Managed layer and upon importing into the new org it will do the same; flattening all patches and the base into one nice, clean managed layer again. (if it isn't already obvious, patches are the path I recommend)

 

So when do you consolidate your patches? That's really a question to be left to your project specifics and how you want to define a patch, but for the ISV products I manage, we do our releases in batches. We lump each of our 'preview' features as individual patches I can give out to customers to review and offer feedback and when we've incorporated feedback and are ready to finalize the release, we consolidate and issue a new major release.

 

Issues you'll have when using a patch:

  • The source is still all one unmanaged layer, so as tempting as it is to pretend that you can cleanly issue patches as individual features that can be installed in any order, this is often not really the case. I especially find a lot of headaches with ribbon customizations where it is an all-or-nothing add to the unmanaged solution. So, for example, if Patch A has a new ribbon button on some entity and Patch B is updating a different ribbon button on the same entity, there is no way to prevent these customizations (and their dependencies) from bleeding over into one another, so when it comes to things like this you will need to plan carefully and often subsegment your patches based on the schema they impact.
  • Patches cannot be subtractive
  • Patches lock down the core solution so that from the moment you make your first patch until you clone the solution again as an upgrade, you are dead stuck; you cannot even touch your core solution until you go all the way.

On balance, there are of course downsides to every approach, but I find that patches let me and my teams experiment freely with new features, knowing that we can always safely rip them out of an environment if there is an issue. This is an enormous value-add that I just adore, and good enough reason for me to recommend it to anyone.

@ScottDurow 's reply came in while I was writing mine so I am only seeing it now. I agree with everything he said, and I think we just have different perspectives on the cost/benefit of patches. Scott is totally right about the segmenting and not shying away from big solutions AND that patches add a lot of complexity, I would just say that the cost/benefit calculus changes a lot as the complexity of your feature releases changes. The more isolated features you are pushing out and the more you think you might need to pull them back, the more reasonable the costs of patches becomes.

ChrisPiasecki
Most Valuable Professional
Most Valuable Professional

@ScottDurow already touched on all the major points, so I won't repeat everything as I agree with with those statements.

 

I prefer to keep it as simple as possible and keep the solutions to a minimum. I think segmenting PA Flows is ok as they require a bit more work to deploy automatically with connection references. 

 

I've never liked patches or had much success with them so I no longer attempt to. As Scott mentioned, it makes it difficult to manage in source control and requires its own ALM steps.

 

---
Please click Accept as Solution if my post answered your question. This will help others find solutions to similar questions. If you like my post and/or find it helpful, please consider giving it a Thumbs Up.

---
Please click Accept as Solution if my post answered your question. This will help others find solutions to similar questions. If you like my post and/or find it helpful, please consider giving it a Thumbs Up.
Chris
BenediktB
Advocate II
Advocate II

I do agree with @ScottDurow and partially with @cchannon.

I always use managed solutions based on the pros that were discussed and you are probably fully aware of. Two major things for me is the possibility to roll back Upgrades (until the Holding solution was applied) and that it will clean up components that were deleted from the solution. So if you delete a field from Dev it will be deleted from the following environments as well.

 

I also rarely use segmentation because of the complexity which comes with it and Scott described very well. One example where it is useful though is when there are several teams working on your end solution. There one team might build the core function and other teams might build on top of it (a bit like Scott described). Then every team should have at least one environment and a separated segmented solution.

 

As I mentioned on twitter: The approach you use at the moment with unmanaged solutions isn't usable and not at all recommended with managed solutions. You would create a dependency hell (ass @cchannon described) where you will be unable to delete anything in the future.

When I started here in Sweden over 3 Years ago my first assignment was in a project where this approach was used. It also was a CRM 2013 onPrem installation, which made it worse since there was a lot of investments in this area in the last months. We had maybe hundreds of managed solutions in prod all referencing components from each other. It is basically unmanageable and not possible to clean up.

 

I have to disagree with @cchannon in regards to patches. I rarely use them (the only occasion is when I have a hotfix to deploy) because I find them nearly unusable when it comes to an automated deployment process. I have the following problems with it:

  • When it comes to an automated process the solution name should be always the same, otherwise one has to change the pipeline with every deployment which makes the whole point of automation worthless. When you create patches the names change for every patch.
  • The base/core solution a patch is created from has to be exactly the same in the source and the target environment. Otherwise the Patch can't be installed. One example: You are in production with version 1.0, you developed some features and have version 1.1 in dev as well as deployed to test, a bug is detected and you have to test it. When you create a patch on your current version you can't move it to production since the core version of the patch is higher than the core version in production. Yes, today you can change the version to whatever you want (even to a lower version) in the maker portal, but still, it feels awkward. I could see benefits when it comes to ISVs.
BenediktB
Advocate II
Advocate II

Since Holding solutions and Upgrades are only a thing with managed solutions you might not be aware of what I was referring to (and Scott as well). I tried to describe those a bit in one of my blog posts

https://benediktbergmann.eu/2020/09/20/apply-solution-upgrade-in-pipeline/#background

@BenediktB - Agree that Patch naming (and many other aspects of patches) could really use some love from MSFT. Those are definitely among the many reasons they outwardly do not promote patches as a best practice.

 

The key to making patches viable, IMO, is thinking of them more as an ethereal solution branch; either as a "hotfix that we will roll into the whole solution once we can test it better" or as a "feature we will roll into the solution once we know it isn't worthless" Granted, in both cases rollback isn't as simple as it could be (I have R-rated dreams about the ability to build a managed layer directly in an environ instead of importing it) but it is definitely much better than putting a temporary addition into one monolothic managed solution only to release it and decide "that was a bad idea".

BenediktB
Advocate II
Advocate II

I am still not convinced. How do you handle a normal release when you have a feature patch which is in development/testing for several sprints/weeks?

As you mention patches block the core solution. So they have to be short-lived. Which isn't possible when one uses them for feature development. At least I haven't seen it work.

 

We tend to create POC environments if we would like to test out new features or feature environment to develop them. When they are finished they get deployed to the dev environment and merged into our normal solution.

 

I am sorry, but I don't see patches there. Could be that I don't see the complete picture though.

filcole
Advocate II
Advocate II

One caveat with the all in one solution approach is custom connectors. Currently it's possible to get SQL deadlocks and thus a failed solution install if a custom connector is included in a single solution alongside its dependent components. See https://docs.microsoft.com/en-us/connectors/custom-connectors/customconnectorssolutions#known-limita...

Helpful resources

Announcements

Win free tickets to the Power Platform Conference | Summer of Solutions

We are excited to announce the Summer of Solutions Challenge!    This challenge is kicking off on Monday, June 17th and will run for (4) weeks.  The challenge is open to all Power Platform (Power Apps, Power Automate, Copilot Studio & Power Pages) community members. We invite you to participate in a quest to provide solutions to as many questions as you can. Answers can be provided in all the communities.    Entry Period: This Challenge will consist of four weekly Entry Periods as follows (each an “Entry Period”)   - 12:00 a.m. PT on June 17, 2024 – 11:59 p.m. PT on June 23, 2024 - 12:00 a.m. PT on June 24, 2024 – 11:59 p.m. PT on June 30, 2024 - 12:00 a.m. PT on July 1, 2024 – 11:59 p.m. PT on July 7, 2024 - 12:00 a.m. PT on July 8, 2024 – 11:59 p.m. PT on July 14, 2024   Entries will be eligible for the Entry Period in which they are received and will not carryover to subsequent weekly entry periods.  You must enter into each weekly Entry Period separately.   How to Enter: We invite you to participate in a quest to provide "Accepted Solutions" to as many questions as you can. Answers can be provided in all the communities. Users must provide a solution which can be an “Accepted Solution” in the Forums in all of the communities and there are no limits to the number of “Accepted Solutions” that a member can provide for entries in this challenge, but each entry must be substantially unique and different.    Winner Selection and Prizes: At the end of each week, we will list the top ten (10) Community users which will consist of: 5 Community Members & 5 Super Users and they will advance to the final drawing. We will post each week in the News & Announcements the top 10 Solution providers.  At the end of the challenge, we will add all of the top 10 weekly names and enter them into a random drawing.  Then we will randomly select ten (10) winners (5 Community Members & 5 Super Users) from among all eligible entrants received across all weekly Entry Periods to receive the prize listed below. If a winner declines, we will draw again at random for the next winner.  A user will only be able to win once overall. If they are drawn multiple times, another user will be drawn at random.  Individuals will be contacted before the announcement with the opportunity to claim or deny the prize.  Once all of the winners have been notified, we will post in the News & Announcements of each community with the list of winners.   Each winner will receive one (1) Pass to the Power Platform Conference in Las Vegas, Sep. 18-20, 2024 ($1800 value). NOTE: Prize is for conference attendance only and any other costs such as airfare, lodging, transportation, and food are the sole responsibility of the winner. Tickets are not transferable to any other party or to next year’s event.   ** PLEASE SEE THE ATTACHED RULES for this CHALLENGE**

Celebrating the June Super User of the Month: Markus Franz

Markus Franz is a phenomenal contributor to the Power Apps Community. Super Users like Markus inspire others through their example, encouragement, and active participation.    The Why: "I do this to help others achieve what they are trying to do. As a total beginner back then without IT background I know how overwhelming things can be, so I decided to jump in and help others. I also do this to keep progressing and learning myself." Thank you, Markus Franz, for your outstanding work! Keep inspiring others and making a difference in the community! 🎉  Keep up the fantastic work! 👏👏   Markus Franz | LinkedIn  Power Apps: mmbr1606  

Copilot Cookbook Challenge | Week 1 Results | Win Tickets to the Power Platform Conference

We are excited to announce the "The Copilot Cookbook Community Challenge is a great way to showcase your creativity and connect with others. Plus, you could win tickets to the Power Platform Community Conference in Las Vegas in September 2024 as an amazing bonus.   Two ways to enter: 1. Copilot Studio Cookbook Gallery: https://aka.ms/CS_Copilot_Cookbook_Challenge 2. Power Apps Copilot Cookbook Gallery: https://aka.ms/PA_Copilot_Cookbook_Challenge   There will be 5 chances to qualify for the final drawing: Early Bird Entries: March 1 - June 2Week 1: June 3 - June 9Week 2: June 10 - June 16Week 3: June 17 - June 23Week 4: June 24 - June 30     At the end of each week, we will draw 5 random names from every user who has posted a qualifying Copilot Studio template, sample or demo in the Copilot Studio Cookbook or a qualifying Power Apps Copilot sample or demo in the Power Apps Copilot Cookbook. Users who are not drawn in a given week will be added to the pool for the next week. Users can qualify more than once, but no more than once per week. Four winners will be drawn at random from the total qualifying entrants. If a winner declines, we will draw again at random for the next winner.  A user will only be able to win once. If they are drawn multiple times, another user will be drawn at random. Prizes:  One Pass to the Power Platform Conference in Las Vegas, Sep. 18-20, 2024 ($1800 value, does not include travel, lodging, or any other expenses) Winners are also eligible to do a 10-minute presentation of their demo or solution in a community solutions showcase at the event. To qualify for the drawing, templates, samples or demos must be related to Copilot Studio or a Copilot feature of Power Apps, Power Automate, or Power Pages, and must demonstrate or solve a complete unique and useful business or technical problem. Power Automate and Power Pagers posts should be added to the Power Apps Cookbook. Final determination of qualifying entries is at the sole discretion of Microsoft. Weekly updates and the Final random winners will be posted in the News & Announcements section in the communities on July 29th, 2024. Did you submit entries early?  Early Bird Entries March 1 - June 2:  If you posted something in the "early bird" time frame complete this form: https://aka.ms/Copilot_Challenge_EarlyBirds if you would like to be entered in the challenge.   Week 1 Results:  Congratulations to the Week 1 qualifiers, you are being entered in the random drawing that will take place at the end of the challenge. Copilot Cookbook Gallery:Power Apps Cookbook Gallery:1.  @Mathieu_Paris 1.   @SpongYe 2.  @Dhanush 2.   @Deenuji 3.  n/a3.   @Nived_Nambiar  4.  n/a4.   @ManishSolanki 5.  n/a5.    n/a

Your Moment to Shine: 2024 PPCC’s Got Power Awards Show

For the third year, we invite you, our talented community members, to participate in the grand 2024 Power Platform Community Conference's Got Power Awards. This event is your opportunity to showcase solutions that make a significant business impact, highlight extensive use of Power Platform products, demonstrate good governance, or tell an inspirational story. Share your success stories, inspire your peers, and show off some hidden talents.  This is your time to shine and bring your creations into the spotlight!  Make your mark, inspire others and leave a lasting impression. Sign up today for a chance to showcase your solution and win the coveted 2024 PPCC’s Got Power Award. This year we have three categories for you to participate in: Technical Solution Demo, Storytelling, and Hidden Talent.      The Technical solution demo category showcases your applications, automated workflows, copilot agentic experiences, web pages, AI capabilities, dashboards, and/or more. We want to see your most impactful Power Platform solutions!  The Storytelling category is where you can share your inspiring story, and the Hidden Talent category is where your talents (such as singing, dancing, jump roping, etc.) can shine! Submission Details:  Fill out the submission form https://aka.ms/PPCCGotPowerSignup by July 12th with details and a 2–5-minute video showcasing your Solution impact. (Please let us know you're coming to PPCC, too!)After review by a panel of Microsoft judges, the top storytellers will be invited to present a virtual demo presentation to the judges during early August. You’ll be notified soon after if you have been selected as a finalist to share your story live at PPCC’s Got Power!  The live show will feature the solution demos and storytelling talents of the top contestants, winner announcements, and the opportunity to network with your community.  It's not just a showcase for technical talent and storytelling showmanship, show it's a golden opportunity to make connections and celebrate our Community together! Let's make this a memorable event! See you there!   Mark your calendars! Date and Time: Thursday, Sept 19th Location: PPCC24 at the MGM Grand, Las Vegas, NV 

Tuesday Tip | Accepting Solutions

It's time for another TUESDAY TIPS, your weekly connection with the most insightful tips and tricks that empower both newcomers and veterans in the Power Platform Community! Every Tuesday, we bring you a curated selection of the finest advice, distilled from the resources and tools in the Community. Whether you’re a seasoned member or just getting started, Tuesday Tips are the perfect compass guiding you across the dynamic landscape of the Power Platform Community.   To enhance our collaborative environment, it's important to acknowledge when your question has been answered satisfactorily. Here's a quick guide on how to accept a solution to your questions: Find the Helpful Reply: Navigate to the reply that has effectively answered your question.Accept as Solution: Look for the "Accept as Solution" button or link, usually located at the bottom of the reply.Confirm Your Selection: Clicking this button may prompt you for confirmation. Go ahead and confirm that this is indeed the solution.Acknowledgment: Once accepted, the reply will be highlighted, and the original post will be marked as "Solved". This helps other community members find the same solution quickly. By marking a reply as an accepted solution, you not only thank the person who helped you but also make it easier for others with similar questions to find answers. Let's continue to support each other by recognizing helpful contributions. 

Reminder: To register for the Community Ambassador Call on June 13th

Calling all Super Users & User Group Leaders     Reminder: To register for the Community Ambassador Call on June 13th—for an exclusive event for User Group Leaders and Super Users! This month is packed with exciting updates and activities within our community.   What's Happening: Community Updates: We'll share the latest developments and what's new in our vibrant community.Special Guest Speaker: Get ready for an insightful talk and live demo of Microsoft Copilot Studio templates by our special guest.Regular Updates: Stay informed with our routine updates for User Groups and Super Users.Community Insights: We'll provide general information about ongoing and upcoming community initiatives. Don't Miss Out: Register Now: Choose the session that fits your schedule best.Check your private messages or Super User Forum for registration links. We're excited to connect with you and continue building a stronger community together.   See you at the call!  

Users online (2,397)