Improving the performance of Service Fabric builds and deployments on VSTS

Consider the following definition – this is my typical build for a Service Fabric (SF) application on Visual Studio Team Services (VSTS):


In short, after restoring the nuget packages, building the solution and running the unit tests I generate the Service Fabric deployment package and test it. The artifacts of the build are not only the deployment package but also the publish profiles for each environment, as follows:


Unlike an ASP.NET application the Service Fabric deployment package is not zipped, as you can see in the above screenshot. Publishing the artifacts in this case takes around 11 seconds:


What does it mean exactly “publishing the artifacts”? It means that the files files will be uploaded to the server. Obviously the more and bigger files you have the longer it will take to upload them to a server (and later on downloading them when you need to deploy the application).

I decided to zip the deployment package instead to improve the performance. I added another task as follows:


And this is the deployment package, zipped:


Zipping and uploading the deployment package took around 8 seconds:


You might think that’s not a big improvement but times will change depending on the size of the deployment packages. In this case the generated folder has 26MB but I’ve heard of deployment packages that have almost 200MB in size!

Also, have in consideration that when you do a deployment you’ll need to download the artifacts from the server. In the first case the deployment package (uncompressed) took on average 10 seconds to download:


As opposed to less than 3 seconds in the second case (zipped deployment package):


That’s it! In this example I have shown you a Service Fabric build but I’d recommend this approach if you upload multiple files as artifacts. Even though there are extra tasks in the build (zip the package) and release (unzip the package) there was an improvement in the performance of both the build and release.

My suggestion is to create 2 versions of the same build and also the release and compare the results between each version. Give it a try, you might be surprised with the result!

Happy coding 🙂

Use environment variables to speed up your .NET Core build on VSTS

I’m using Visual Studio Team Services (hosted agent) to automate the builds and deployments of .NET Core solutions.

You probably noticed that .NET Core builds take much more time compared to the traditional .NET builds. For example, when you run the command dotnet restore you might have noticed something like this being logged:

2016-09-15T11:15:39.1510337Z A command is running to initially populate your local package cache, to improve restore speed and enable offline access. This command will take up to a minute to complete and will only happen once.
2016-09-15T11:15:44.7529135Z Decompressing 0%... Decompressing 1% ... (text removed for brevity) Decompressing 100% 5523 ms
2016-09-15T11:16:05.7899968Z Expanding 0%.... Expanding 1%... (text removed for brevity) Expanding 100% 20548 ms
2016-09-15T11:16:29.7176084Z log  : Restoring packages for C:\a\1\s\Development\Source\MyProject\UI\project.json...

As you can see, caching of the packages took almost 1 minute! As suggested in Stop wasting time during .NET Core builds, adding the following environment variables to your build definition can reduce the build time:

.NET Core environment variables

So basically DOTNET_SKIP_FIRST_TIME_EXPERIENCE will prevent the caching of the packages on the build machine, and NUGET_XMLDOC_MODE will prevent the download of the XML documentation for the packages. Unfortunately I couldn’t find much documentation about these variables, but check the blog post above for more details.