Upate or Upgrade of large managed solution

[ZARE]

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:

1. Solution takes a long time to deploy (we use Upgrade method)
2. 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:

1. 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?
2. 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

[EricRegnier]

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!

[ZARE]

Apologies for late reply as well 🙂 We ended up creating another solution in our Build environment which we recreate after each sprint. We continue to maintain full solution like we did so far, but in addition we copy only components we worked with to this new solution. Deployment is done with "Update", not "Upgrade" method so no deletion is done. In repo we have both, full solution where we can trace changes like we could so far and the other one which is not so useful when it comes to tracking changes, but has only purpose of packing and deploying. The reason is that we experienced many times that Microsoft installs updates in our Build environment before Staging and Production. Then we get an error while importing and have to create a support ticket for MS to push updates in other environments as well. We will reduce this problem by deploying only those components we have worked with. Our pipeline will always pack both solutions, so we will be able to perform a full Upgrade (with deletion) occasionally. Hope this sounds reasonable 🙂

[HEDI_BK]

Hey @ZARE ,

How did you manage it at the end. I am facing the same issue of using a big solution for upgrade. I am thinking about making for each new release version a new solution that will contain only newly created components and the modified ones. So in AzureDevOps we need maintain two type of solutions, Sprint solution and Global solution

during a whole PI we deploy each sprint the sprint solution and at the end of the PI the Global one with Upgrade if needed.

In other projects, I've also seen a strategy that's totally based on a new solution for each Release, so there's no global solution. They always import a solution which contains the version in the name and not just in the version field so that let the target environment sees it as a new solution. The target environment contains several solutions:
R1_1_2    1.1.2
R1_2_0    1.2.0
R1_3_0    1.3.0
etc...
each time there is a new layer of solutions. I don't know whether this is a good solution or not.

[ZARE]

Hi, we ended up with solution described above, let me know if there is something unclear in my description.

The catch is in maintaining a sprint solution which we recreate at the start of every sprint. In repo we change the name of the solution in Solution.xml with a PowerShell script and we set the same version as our full solution gets. When we pack it back from repo we are able to deploy it with Update method as a new version of existing solution (I was unsure first if this was going to work but it does) so no additional solution layers are created.

Strategy of deploying a new solution for every version does not sound like a good solution to me, there will be so many layers. How could you ever delete a component which is referenced in many of those versions?

[Gusz]

Our current set up is where have multiple solutions segmented by components e.g. schema (tables, columns, relationships, forms etc.), processes, security and so forth.

Some of these solutions have grown so large that when performing an upgrade the import takes upwards of two hours and during this time the system is next to unusable.

My current thought is using this structure but use update, though in the scenario we need to remove components we:

- create an "anchor" solution with the components to be removed 

- import the anchor solution to the target environment

- remove the components from the segmented solution

- import the segmented solution to the target environment

- delete the anchor solution from both source and target.

Just food for thought, have not tested this yet but in theory it should work.

[piotr-albertin]

I’m not quite sure if I understood you correctly, and this topic is a bit old, but possibly someone else would benefit from the answers here.

My understanding of your scenario:

You have a base solution (following your example) with around 100 components. During a Sprint (the length probably doesn’t matter), you work on only 5 components. You want to reduce deployment time.

Btw, Could you clarify how long it currently takes you to deploy that solution with 100 components, and what duration you would consider as ‘reduced’?

Assuming my understanding is correct, here’s what you could do:

1. Establish a regular ALM process to upgrade your BaseSolution (let’s use this term for simplicity). This process could be run every few sprints, or manually whenever you prefer.
2. Prepare another ALM process that will import a solution called Sprint-XXX-Changes, which includes only the changes your team worked on during the Sprint. This way, you will have an additional layer on top of your BaseSolution, and deployment will be quicker (please clarify your goal here and why you want to achieve it). You could deploy this even every day during your sprint.

Note: Importing your updated (upgraded) BaseSolution should also remove your Sprint-XXX-Changes solution(s), as you wouldn’t want to have too many layers.

[EricRegnier]

Hi @piotr-albertin, that can work but following healthy ALM practices is not recommended to have "Sprint-XXX-Changes:" or delta type of solutions. It could become quite a mess and interdependencies that might get impossible to solve. The import process and speed have improved quite a bit and will continue to improve. Having one solution (if possible) or practice a consistent solution segmentation is best, in otherwards, importing the same solution downstream (with version updates). If having separate solutions, suggest to have one environment per solution (exported as managed). More info at: https://learn.microsoft.com/power-platform/alm/?WT.mc_id=DX-MVP-5004271