How to handle hotfixes in Dataverse

Recently I noticed some questions coming up here and there regarding how to handle hotfixes in Dataverse. There was one community member who specifically asked whether I would have a blog post about that.

So I thought it might be time to write about it.

What is an Hotfix?

Let’s start with explaining what hotfixes are.

A hotfix does introduce the correction of an urgent production error.

So let’s say you deploy something to production and shortly after that some users do report errors in parts of you application. Depending on your deployment frequency and how pressing the error is you would like to fix it immediately. To do so you would correct the error and deploy the new version to Production right away.

Different Solutions

When it comes to the Dataverse there are different solutions to that.

Complete deployment

The first approach I would like to mention is the “complete deployment”. The idea is that the error gets fixed in development and then deployed through the standard pipeline. This usually means to test and then to prod.

Pros

The investment in this one is very low. You are able to use the pipelines you already have in place and everything is still completely automated.

Cons

If the bug isn’t found right away there could be changes made to the development environment one doesn’t want to deploy yet.

In addition to that we always deploy the whole solution, which could be huge.

Patches

Dataverse has a special type of solutions called Patches. Those build on a “base” solution, but one only includes the components that should be deployed.

Pros

The solutions to deploy are very small, which results in fast deployments.

Cons

Patches are basically unusable in automated pipelines.

If anyone knows how to use them in a good way, please let me know.

The Problem is that the version of the “base” solution where the Patch is created from has to be exactly the same in the source and target environment.

Here again, if the bug isn’t found right away dev and test might be on a higher version than production. This would lead to the problem that a patch created in dev couldn’t be installed in production.

In addition to that the names of patches do change from patch to patch. Since the pipeline steps we usually use do need the solution name to know which solution to export and move one would need to change them manually all the time.

The last con I see is that we not really can store them in our Source Control. Since the name changes we would get them in separate folders which would never get deleted again and would pollute our source control.

Additional Environment

The last approach I could think of is with an additional environment.

So let’s assume the environment structure includes a Dev, Test and Prod environment, as shown in the image.

We could then add another environment, called “hotfix”.

To this hotfix environment we would deploy the same version as we deploy to prod but as unmanaged.

If there is an bug in the production enviornment we could then fix it in the hotfix environment and deploy it from there.

Pros

With this approach you don’t have dependencies to the dev environment when it comes to hotfixes.

If you would like to use patches the base solution would always be the same version in Hotfix and Prod.

There are only very small changes to the pipelines needed.

Cons

There are additional costs when you add an environment.

Changes made in the hotfix environment needs to be done in dev as well.

Conclusion

To handle hotfixes in dataverse I prefer the last mentioned approach.

I think it has the most secure and stable way of handling hotfixes. As I mention there are cons to that as well, but for me the pros out weight those.

I hope this article was interesting and will help you.