I run this blog and other sites on Azure App Services (used to be called Websites). As you might know all that code is open source on GitHub and I use that code to deploy directly to Azure.

I use the GitHub deployment that Azure offers so that every time I push a change to my master branch, it creates a new deployment for me. It’s been pretty great, except…the deployment is pretty slow. Normally the speed of this deployment wouldn’t matter a lot, except of course when I push a bug out to ‘live’. Then the speed really matters.

I was perusing the builds and noticed that a build was taking 1014 seconds. That’s an ASP.NET project with very little client-side building (e.g. no webpack or similar). Getting the source, doing the restore, building the project, and deploying it all shouldn’t be taking 16+ minutes.

I looked back to see if this was an aberration, and saw that lots of my builds were that slow, though some were as fast as 9 minutes…still incredibly slow. So off to Twitter!

@ShawnWildermuth set an App Property “SCM_REPOSITORY_PATH” to “D:\local\repository” this is the local vm drive or fast drive.
— Shayne Boyer (@spboyer) January 13, 2017

I got a great answer and a solution from this twitter conversation:

So when a build runs on App Services, it uses (by default) a mapped drive that allows it to store the data required to run a site across instances (without duplicating the code across the data center). This is a great idea, but because this drive is going through a handful of layers, it slows it down. Luckily there is a locally mapped version of this drive that can vastly improve the performance of building your apps.

The trick is to set an AppSetting to point at the ‘fast’ drive:

It decreased by builds from 1000 seconds to right around 300 seconds! It was a big win for me.

If you want to understand why this is happening, the ASP.NET Core standup did a great job of explaining it. You can watch it here (interesting bits starts at 18:30):