Try our conversational search powered by Generative AI!
AI OnAI Off
DXC Deployment & Debugging Best Practices
I think you are correct. Whatever's on Integration will be copied to PreProd and Prod.
We've managed with only New Relic and logs.
For one serious issue in Production memory dumps were created by Epi staff.
We also start a ticket regularly to get backup data made available so we can troubleshoot locally (with our own Azure resources for storage).
Jan 23, 2018 17:07
Thanks, I've decided to make multiple releases, the default being with debugging on so we can remote debug when in the Integration environment and then another that does a release build. That way when deploying to Pre-Production we'll make sure the otimized code is on Integration
Jan 23, 2018 17:09
This should help you in the future for environment specific configurations and code
Edited,
Jan 26, 2018 15:21
Thanks, but this isn't really related to the my topic, that's more a around transformations which is different that the optimze build flags. Transformations are the easy part lol
Edited,
Jan 26, 2018 15:30
Hi guys I was wondering what other peoples thoughts are around this.
As part of the DXC training and the Episerver World documentation it's shown how to configure integration to allow for PDB files and remote debugging by doing the following.
Creating a configuration which you use for the Integration build and setting the standard debugging values as shown
This will for our deployment deploy these files to the Integration envionment.
However when using the Pass portal or deployment through service desk tickets won't the DLLs simply be copied up to these envionments with the non optimized code?
I was considering creating multiple builds so that our standard would use the debuggable non optimized code and another could deploy to Integration prior to pushing out to the Pre Production but it seems like a lot of effort.
What are people views who have done this before? Thanks in advance