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 · Accepted solution]

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:

1. 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.
2. Microsoft updates are a pain point for a lot of us. You probably already tried, but you can try to minimize those by:
   1. Having the same environment types for all your stages
   2. Have the same region for all your envs
   3. Have the same refresh cadence for all envs
      
   4. Ensure that the Dynamics 365 (1st party) apps have the same version in all envs:
      

Hope this helps!

[cchannon]

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.

[EricRegnier]

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

[ZARE]

That's correct @cchannon , we did that.

Many thanks to you also for suggestions @EricRegnier .

[ZARE]

@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)?

[EricRegnier]

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

[ZARE]

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.

[EricRegnier]

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 🙂

[ZARE]

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 🙂