A critical vulnerability was discovered in React Server Components (Next.js). Our systems remain protected but we advise to update packages to newest version. Learn More

Scott Reed
Dec 13, 2017
  1372
(0 votes)

Configuring VSTS Releases From a single package to work with New Relic on the DXC

As part of my first expereince fully working with the DXC on a project here at https://www.redweb.com/ we chose to use the Visual Studio Team Services code, build, test and deploy process so that we could manage everything in VSTS and have links through to work items for build and releases. In our project our site was both a commerce and cms website so we needed to deploy to 2 defferent Azure web apps.

This process involved

  1. Create a triggered build process that would build the CMS and Commerce solution
  2. Create a single zip artifact package file that would contain packages for both the CMS and Commerce builds.
  3. Create a triggered release process that could deploy each package in the artifcact to each Azure web app (using the Azure App Service Deploy step). This is important so left over files are not on the web app and any old DLLs are not left in the bin folder (which could cause runtime issues).

This was all pretty simple to set up (with a bit of playing) although one problem I have discovered when configuring the release process is around the New Relic files which are in a main top level folder by the name of newrelic. These files are added by Episerver and should not be modified.

The issue I have been getting when deploying is one of two results

  • Deploy failing due to the locked new relic files in the newrelic folder
  • Deploy working but deleting the new relic files and the reporting in New Relic breaking (Requires a ticket with Episerver to fix).

The documentation here https://world.episerver.com/digital-experience-cloud-service/deploying/deploying-code-changes/ lists how to configure this for using publishing within the publish/project config which is great if you are directly publishing a site but this wouldn't work using our method of creating a shared artifact of the code and then pushing out to each Azure app.

The magic key to all of this was configuring the additonal argument to have -skip:skipAction=Delete,objectname='dirPath',absolutepath='.\\newrelic' -skip:skipAction=Delete,objectname='dirPath',absolutepath='.\\newrelic\\Extensions' so that the folder is skipped as part of the deploy process as shown below.

Once this is configured the newrelic files are skipped and only the files we control are remove.

Hopefully this will help people with similar issues. At some point I'll do another blog around the full experience of setting up a DXC VSTS project.

Dec 13, 2017

Comments

Please login to comment.
Latest blogs
A day in the life of an Optimizely OMVP: Learning Optimizely Just Got Easier: Introducing the Optimizely Learning Centre

On the back of my last post about the Opti Graph Learning Centre, I am now happy to announce a revamped interactive learning platform that makes...

Graham Carr | Jan 31, 2026

Scheduled job for deleting content types and all related content

In my previous blog post which was about getting an overview of your sites content https://world.optimizely.com/blogs/Per-Nergard/Dates/2026/1/sche...

Per Nergård (MVP) | Jan 30, 2026

Working With Applications in Optimizely CMS 13

💡 Note:  The following content has been written based on Optimizely CMS 13 Preview 2 and may not accurately reflect the final release version. As...

Mark Stott | Jan 30, 2026

Experimentation at Speed Using Optimizely Opal and Web Experimentation

If you are working in experimentation, you will know that speed matters. The quicker you can go from idea to implementation, the faster you can...

Minesh Shah (Netcel) | Jan 30, 2026