Cleaning up ALM environments

[WillJay]

We are starting to consolidate our ALM processes now that we have some managed solutions deployed. I want to clear down our DEV environment, we have a number of solution packages in there for the most recently released system: a core package (which is the initial release containing all objects) and a couple of 'patch' solutions that just contain one or two specific components from the core, for targeted updates.

Can I just check my assumption that I can take an export of the core solution (that contains all objects) to save to our repo, and that will contain the customisations added by other solution packages in the environment, even if the last customisations to an object were carry out by a layer related to another (patch) release? Or do I need to save the lot?

Thanks!

[cchannon]

I think I'm getting some terminology confusion here. "Patch" refers to a very specific type of solution that is not used very commonly. I am guessing that when you say "patch" you just mean "a small unmanaged solution that originated in this environment"

Next thing I want to check on: when you talk about a "core" solution are you referring to:

• The "default", or "unmanaged" solution layer
• A solution that was created in this environment and holds the majority of your customizations
• A solution that was imported into this environment from somewhere else and holds most of your customizations

Answers to the above will help us answer your overall question.

[WillJay]

Hi there!

Correct, when I say 'patch' I just mean a small unmanaged solution with a few of the components for the solution which we used to carry out some updates to those specific components without having to redeploy the whole lot. I've not messed with the 'patch solution' stuff (yet).

When I say 'core' solution I mean a solution that was created in this environment and all the components of our solution. They are all unmanaged as this is in our DEV environment, we export managed to the PROD environment and unmanaged to go into our repo.

There are some customisations added by those patch solutions, what I want is to be able to export a solution package that contains ALL customisations across both core and patch solutions. The idea being that we can spin down DEV and just install that one package again as and when we need to do some work on it - knowing that what we have installed on DEV is the same as the components installed on PROD.

Thanks!

[cchannon · Accepted solution]

OK, great.

So there are plenty of sophisticated ways to do this, but to be honest with you the simplest approaches are usually the best. If you don't already have it, download the XRM Toolbox and install the Solution Components Mover.

That tool will let you take one solution (e.g. patch) and copy everything it contains into another solution (e.g. NewCore) and you can do it multiple times so you can copy everything Core, then everything Patch1, then everything Patch 2... and the end result will be one solution that has it all.

[WillJay]

Thanks, I've used XRM Toolbox previous for data migration between dataverses - I will take a look at the Solution Components Mover.

Am I right in thinking that it wont work to simply export the core because some of the customisation layers in those components are in the patch solutions, so would they effectively just revert to the last layer that was provided by the core solution package?

Thanks again

[WillJay]

Also, as I mentioned, we are looking to really develop our ALM process. We used DevOps and Azure repo's already and I've experimented with getting some simple pipelines going for deployments and repo commits. As we're likely to want to be able to released these patches fairly flexibly in the future could you signpost me to some of the sophisticated capabilities for keeping an up to date master branch as we dynamically create DEV environments and deploy...?

Cheers 😊

[cchannon]

You're right, but not for the right reason.

In any Dataverse environment, there is only one unmanaged layer, ever. All the unmanaged solutions you see are really just views into that one layer and it is impossible for them to contradict. For example, if you add a contact form with 10 fields to unmanaged solution A, then add that form to solution B and add another 3 fields, when you next look at solution A the form will have 13 fields. They must match because they are both looking at the same layer.

But that doesn't mean you can just grab core and move on because those 'patches' could contain things core doesn't have like an extra column on the table or a form that only got created in the patch. Hence why you need to merge them into one: to be safe from missing dependency problems.

[cchannon]

There's a lot of content to discuss there, but let me point you to one change I think will help a lot:

What you're keeping in repo should be reflective of what leaves that dev env, not the momentary state of it at export. So you should be dumping your managed solution into the repo and deploying from there.

Why? Because you can always revert to a backup as much as a month old, so unless it takes you over a month to discover bugs worth rolling dev back for, you are covered without needing to store a dev-recoverable solution. The environments after dev, however, need to be assured they all get the same solutions, so you dump to repo before you deploy to UAT, then when you go to Prod (or whatever your envs are) you deploy from repo again and you have zero risk of a change having occurred in the interim.

[WillJay]

Thanks, that's really interesting. There have been conversations about spinning down DEV inbetween releases and just creating environments as part of the deploy from DevOps, but in that instance I assume it would be fine to do so with the unmanaged package of the merged solution.

I also assume that installing that merged solution package into PROD where the 'old' core solution and various 'patch' solutions exist wouldn't present any issues, as all the required layers are now present in the 'new' merged solution package. In theory I guess we could delete those 'patch' solutions from the environment?