World is now on Opti ID! Learn more

Scott Reed
Dec 13, 2017
  1316
(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
Make Global Assets Site- and Language-Aware at Indexing Time

I had a support case the other day with a question around search on global assets on a multisite. This is the result of that investigation. This co...

dada | Jun 26, 2025

The remote server returned an error: (400) Bad Request – when configuring Azure Storage for an older Optimizely CMS site

How to fix a strange issue that occurred when I moved editor-uploaded files for some old Optimizely CMS 11 solutions to Azure Storage.

Tomas Hensrud Gulla | Jun 26, 2025 |

Enable Opal AI for your Optimizely products

Learn how to enable Opal AI, and meet your infinite workforce.

Tomas Hensrud Gulla | Jun 25, 2025 |

Deploying to Optimizely Frontend Hosting: A Practical Guide

Optimizely Frontend Hosting is a cloud-based solution for deploying headless frontend applications - currently supporting only Next.js projects. It...

Szymon Uryga | Jun 25, 2025

World on Opti ID

We're excited to announce that world.optimizely.com is now integrated with Opti ID! What does this mean for you? New Users:  You can now log in wit...

Patrick Lam | Jun 22, 2025

Avoid Scandinavian Letters in File Names in Optimizely CMS

Discover how Scandinavian letters in file names can break media in Optimizely CMS—and learn a simple code fix to automatically sanitize uploads for...

Henning Sjørbotten | Jun 19, 2025 |