Answered

Upate or Upgrade of large managed solution

(0) Share

Report

Posted on by Žarko Radevic

Hi, I would like to get some advice around deployment strategy in situation when a solution gets very large and takes long time to deploy.

We have an ALM process where many developers send their customizations to a "build" environment. We gather all the customizations in one "main" solution, export it as managed and import to staging and production at the end of the sprint. Some of the problems:

Solution takes a long time to deploy (we use Upgrade method)
We have some out of the box entities there which we don't customize often. Multiple times we experienced issues when Microsoft installs an update in our dev or build environment BEFORE they do it in staging and production (we have asked multiple times if it is possible to control which environments get updates first, but we get response that it is totally random).

We are considering the following:

Use "Update" instead of "Upgrade" method when importing. This way we should be able to always send "minimalistic" solution from our "Build" environment. I am not sure how easy it would be to handle deletion of components in this way. Some other disadvantages?
Begin with a new solution and continue using "Upgrade" method. In this way our new solution would work as it works today, we would only have an extra layer on top of the solution we have now. It would also be tricky to delete stuff that is referenced in both layers, but I am not sure if we would have that need so often.

Thanks in advance

Categories:

Microsoft Dataverse with Power Apps

I have the same question (0)

All responses (16)

Answers (1)

Verified answer

EricRegnier 8,720 Most Valuable Professional on at

Like (3)

Report
Copy link

Link copied!
Hi @ZARE,

Every implementation can have different ALM strategies, however the approach you described is similar to what I'm doing and follows best practices (I assume you're using a repo as the source of truth to manage the customizations). For your specific questions:

Yes, as designed with Upgrade because it actual installs a 2nd holding solution, uninstall the old solution and renames the holding (it's not a minimalistic solution btw). This is a heavy process that takes time... Microsoft is aware and are constantly trying to improve the overall solution import performance. I recommend keeping Upgrade to ensure the customizations are kept clean and components no longer required are removed. This is especially helpful at the beginning when the data model and solution are volatile. When everything is a bit more stable, you can witch to Update but once is a while (eg the deployment before Prod) it is good to do an Upgrade.

Microsoft updates are a pain point for a lot of us. You probably already tried, but you can try to minimize those by:

Having the same environment types for all your stages

Have the same region for all your envs

Have the same refresh cadence for all envs

Ensure that the Dynamics 365 (1st party) apps have the same version in all envs:

Hope this helps!

Was this reply helpful? Yes No
cchannon 4,702 Moderator on at

Like (3)

Report
Copy link

Link copied!

Another way to minimize the impact of MSFT updates: Where you are using OOB tables, only include the schema you need and do not use an OOB form: make your own copy. This will minimize schema and form impacts from their updates.

Was this reply helpful? Yes No
EricRegnier 8,720 Most Valuable Professional on at

Like (0)

Report
Copy link

Link copied!

Yep, that's more on the customizations side but I agree and do the same thing with and also with views, dashboards, apps, etc.

Was this reply helpful? Yes No
Žarko Radevic 42 on at

Like (1)

Report
Copy link

Link copied!

That's correct @cchannon , we did that.
Many thanks to you also for suggestions @EricRegnier .

Was this reply helpful? Yes No
Žarko Radevic 42 on at

Like (0)

Report
Copy link

Link copied!

@EricRegnier do you have any recommendation how we could maintain both, "update" version of solution and full version (to be able to run Upgrade occasionally)?

Was this reply helpful? Yes No
EricRegnier 8,720 Most Valuable Professional on at

Like (0)

Report
Copy link

Link copied!

Hi @ZARE, I have a variable that is set at release time:

Was this reply helpful? Yes No
Žarko Radevic 42 on at

Like (0)

Report
Copy link

Link copied!

I understand @EricRegnier but what I want to achieve is to do "Update" of solution with only components we worked on in a sprint, as well as maintain complete solution so that we can "Upgrade" occasionally. So our "Build" environment should have 2 versions of solution in a way, one with all components and one that we rebuild every sprint to have only components we worked with. Then we would export both to save in our repo. I just have to find a way to manipulate those as I can't have 2 versions of solution (same name and publisher) in same environment.

Was this reply helpful? Yes No
EricRegnier 8,720 Most Valuable Professional on at

Like (0)

Report
Copy link

Link copied!

Hi @ZARE, with Upgrade or Updates, there's no 2 versions of a solutions, it's always the same version. It's the import process that changes where it performs an upgrade/update. You can try to automate and check if you're at the end of the sprint to auto set the pipeline variable. In one of my scenarios, I actually have 2 pipelines: one for the day to day build and test and does and update, and one for the release to prod which goes to UAT then prod which does an upgrade. Hope these gives you options 🙂

Was this reply helpful? Yes No
Žarko Radevic 42 on at

Like (0)

Report
Copy link

Link copied!

I understand that, but what I am trying is to send solution with components that we worked with in current sprint only. Let's say our solution has 100 components totally and we can export it and do a full Upgrade. In current sprint we worked with 5 of those 100 components and I want to send Update of solution containing just those 5 components (to reduce deployment time as much as possible). So what I need is to have a full solution definition with all 100 components in the repo, as well as to be able to pack just those 5 components we worked with recently. Since I do Update nothing is going to be deleted.

I understand if this does not sound clear 🙂

Was this reply helpful? Yes No
EricRegnier 8,720 Most Valuable Professional on at

Like (0)

Report
Copy link

Link copied!

Hi @ZARE, apologies for late reply. I understand what you are trying to do, and unfortunately solutions and pack/unpacking don't quite work like that. Unpacking/packing work at a solution level so if you have an updated solution with just the 5 components, after unpacking and committing, the repo will think all the other 95 components were deleted. If you absolutely want delta solutions, you'll to have create new solutions and unpack to different folders each time before committing, so from a repo history it will be messed up IMO. You may be overcomplicating it. May I ask why you would like to do this? Even though you unpack the full solution each time, with the repo history you'll only see those 5 changes, so you'll still have the traceability of only the components that changed. And since you're packing from the repo, you're ensuring that no WIP and only stable changes are being deployed. Even if you deploy components that didn't change, does it really matter? Comparing to traditional .NET deployment or Azure Functions, maybe a C# class didn't change but you still deploying the full DLL...

Hope this helps a little!

Was this reply helpful? Yes No