How to manage Sitecore Hotfixes

Question

While building solutions bases on Sitecore I have to deal also with Sitecore hotfixes. For my current project I already have about 20 different hotfixes. They override default Sitecore files in most cases assemblies and Sitecore configs. I am looking for ways or even best practices how to manage those hotfixes within a solution as well as how to deliver them to a test or production environments.

Currently I keep the files from hotfixes together with my solution. They all are committed to the same code repository. I created a dummy Visual Studio project and added all the files from the hotfixes there. When the dummy project is built together with the solution the hotfix files are copied to output folder and added to a deployment package.

What I miss in this approach it is first of all transparency. I would like to understand why I have each hotfix, what it consists of and how it can quickly be uninstalled without digging too much in Sitecore tickets and knowledge base.

What are you doing with your Sitecore hotfixes? How are they connected to your solutions and CI/CD pipeline?

Answer 1

In our project we try to create NuGet packages from them where possible and add them to our own internal feed.

When it replaces an existing Sitecore DLL (for example we've had a hotfixed Sitecore.Kernel.dll) we just use the package from our local feed in every project that requires it.

In case the hotfix adds a separate DLL with a config file to patch it in, we add it to the most relevant module in our Helix solution.

Answer 2

We are creating one project per each hotfix. We unzip hotfix and put everything into C# project. We create README file (which is not deployed) so we know what each hotfix is used for. We keep also reference numbers and ticket numbers there so we can easily identify them.

During upgrades these projects are checked / validated if are included or not in current version which we are upgrading to and then removed if not necessary anymore.

We have recently created a separate repository for hotfixes with same structure as defined above. We are therefore deploying hotfixes only once or as needed to each environment as we have a special pipeline step in DevOps to either deploy or not this repository.

Answer 3

I have added a new layer to my Helix project called Infrastructure. This layer holds my CI scripts, SIF, PowerShell, DSC, etc.... Everything I need to build my devs and farms. In that layer I created a new Infrastructure.Patch project that I am adding all the hot fixes that the site needs. If need be I am excluding files from being deployed to certainly environments via the build configurations.

Answer 4

What we did in our older projects is edit the MSBuild process of the solution to also copy files from a directory into a build/deploy folder. In this directory it is possible to have several levels of folders, so we had a SitecoreModules folder as base folder which contains multiple folders for each patch or module. In these subfolders there were the App_Config and bin folders and all the files. This might help in getting a structure and some documentation for all the patches instead of combining them all in one VS project, but it might also be considered as a 'nasty' approach..

Answer 5

I have used Octo Deploy to successfully manage and deploy Sitecore hotfixes at scale, across multiple projects / sites, whereby the patches are installed "on top of" the artifacts as part of the release pipeline. Keeping the hotfixes separate from the codebase has proven to be advantageous over the long term in terms of maintainability and documentation.

Each hotfix becomes an individual self documenting deploy step, which is based on a step template.

This way, you can also do config transforms if any changes to the web.config are required.

To summarize, each hotfix will end up as a separate step within your release pipeline.