This question keeps coming up from time to time, and while it may not always be the same front-end, this tutorial should at least get you going on the right path getting your build automated with Azure. Who knows, it may work for you – hopefully it does! OK, so you’ve got a front-end SPA written in Durandal, and a back-end written in .NET taking the form of a NancyFx REST API? No? Well close enough…if yours is similar, you can probably follow along most of the way, but the key thing we have in common is that you want to take advantage of being able to automatically deploy on Azure Websites using their nifty link direct to your source control – effectively using the cloud as your build and deployment server right? Alrighty then, let’s go!
What you’ll need
First, I’m going to make a few assumptions that you’ll need to have in place before you can pick up from this article:
- You have an Azure account where you can login to the portal and create a hosted Azure website;
- You have your code checked into to some kind of Source Control (like GitHub for example) that can be accessed over the web. It doesn’t matter if it’s private – just as long as Azure would be able to reach it if given the right credentials;
- Your Durandal based website is working locally and now you’re ready to deploy.
Assembling the puzzle pieces
First you need to choose a source control branch that you want to deploy, and make sure Azure is paying attention to it. You can follow this tutorial to get that part setup. After that, you can follow on from here… go ahead, I’ll wait Ok, now we need to get our local environment setup. First you’ll need to have installed node.js, at which point you should be able to open a console (Administrator level) to your web project root folder and run this: We now have gulp installed which we will use as the second half of our build process – the first half being MSBuild for the .NET bits.
Taking the ‘ass’ out of assets
One of the big questions that comes up is “how do I version my stuff so that regular visitors get the new asset updates?”. It’s a good question, and you could use some cache busting techniques suggested by some. Of course, there are numerous post out there that will tell you NOT to add your version to the querystring, the biggest problem being that proxies around the web often do not cache pages with querystrings – and this therefore completely invalidates your reason for using it in the first place. What you end up with is some visitors to your site getting the latest scripts, and others who happen to arrive via a Squid proxy for example never updating to your latest scripts and they get strange or broken experiences. I say, forget about versioning assets automagically – there’s no point as it really doesn’t take long in your code and you should be keeping control of that stuff anyway – especially when it’s going to production, and in development you can just tell Chrome or Firefox dev tools not to cache. I felt I needed to address that reasoning first as you’ll see the versioning stuff built into the next parts as we setup the build and may have been confusing.
Getting it all ready to build automatically
As you probably know, most SPA’s run off of one index.html in the root folder of the project. So I assume since you have the website working locally, this is already working as expected. The next thing I do is put a bit of logic in the Nancy viewmodel just, enough to tell the view engine what to spit out in the