In this tutorial, I will give a quick whistlestop guide on how to effectively debug production issues that occur on Episerver DXP. This article will cover some general good practise tips that you can adopt to prevent serious issues occurring within your website. When it comes to DXP, the first thing you will need to do is get access to the Paas Portal. If you do not have access to PAAS, get in contact with Episerver support, here and request access.
When you have access to the PAAS portal, you will have access to a tab called 'troubleshooting'. When a production error crops up, this is usually the first place you should check. Within the PAAS portal, you will have access to several useful tools. If your production website is encountering issues then your first port of call should be the error log stream:
The log stream will show you any errors that the website is throwing in real-time. To debug, open the stream and recreate the known issue. Hopefully, this will shed light on the issue. From the troubleshooting tab, you can also generate historic logs. It is possible to write custom logs yourself. To do this you can use the Episerver logger. The code to do this would look like this:
The other useful tools within the PAAS toolbox is the ability to purge the Cloudflare CDN cache and the ability to perform an IIS reset. If your website still does not work after clearing the cache, contact Episerver support!
As part of your DXP subscription, you will also have access to an application insights dashboard that is connected to your production site. This is accessed via the Azure portal rather than the PAAS portal. The application insights dashboard is something that should be created by Episerver when the DXP site is set up. If you do not know how to access it, ask the support team! This dashboard can be another vital link in helping you to diagnose production issues.
Even though DXP provides some good debugging tools, I recommend you be mindful and intentional when using DXP. Often an issue that someone in your organization thinks is critical, may take an Episerver support technician several hours to look into. Rolling back your code (or a fix-forward) will take time and is not instantaneous. Pushing code up from integration, onto pre-prod, and then finally onto production can take around an hour. Before each release, consider what would happen if some critical bit of functionality stops working and you can not quickly push new code into production to fix it.
For this reason, when the site is hosted in DXP I recommend you write defensive code whenever you add new features. I make heavy use of feature flags when building DXP sites. This is key to sorting production issues quickly. Having the ability to turn features on and off from within the CMS is critical when things go wrong. The key to building good feature flags in DXP is the ability to switch them on and off without doing a release. This rules out creating feature flags within the web.config. Instead, you will need to add feature flags inside of the CMS, either in a settings page, or block. An example of how to create a feature flag property is shown below:
A final thing to note when using DXP is that whatever is created on integration is the thing that gets copied to preproduction and then onto production. When using DXP, remember to leverage config transforms. You can create three different config transforms for each environment. Create three config files named:
- web.integration.config
- web.preprod.config
- web.prodution.config
You will need to ensure that all the transforms and made on the push into integration. You will not be able to run different transforms when pushing code from int to pre-prod and pre-prod to prod.
