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.
When it comes to the Dataverse there are different solutions to that.
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.
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.
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.
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.
The solutions to deploy are very small, which results in fast deployments.
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.
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.
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.
There are additional costs when you add an environment.
Changes made in the hotfix environment needs to be done in dev as well.
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.
This is just 1 of 38 articles. You can browse through all of them by going to the main page. Another possibility is to view the categories page to find more related content. You can also subscribe and get new blog posts emailed to you directly.
Privacy & Cookies Policy
Necessary cookies are absolutely essential for the website to function properly. This category only includes cookies that ensures basic functionalities and security features of the website. These cookies do not store any personal information.