For a while now I’ve been focusing on a number of different technologies on Azure outside of my usual focus on mobile development. Today, I decided it would be a good idea to share some of the stuff I’ve learned. In this post, I’m going to walkthrough how you can get started on Azure with Node.js applications. I’m going to go through this as though you’re setting up a new computer, so some of the steps might prove to be unnecessary for you. If you haven’t installed Node, Git, or Visual Studio Code (or whatever editor you prefer) yet, proceed on to the Setup. If you’re ok with skipping those steps, go jump to Creating your First Node App.


In this seciton, we’ll talk through installing a number of tools. For the sake of this guide, I’ll be doing most of the steps assuming that you’re using OS X or Linux. The steps should be similar if you’re on Windows (though if you are, I’d recommend taking a look at the Node Tools for Visual Studio. First we’ll need to install Node.

Installing Node

Open the Terminal (⌘ + Space and type in Terminal) and run the following command:

node --version && npm --version

If that comes back with command not found you’ll probably need to install Node. You can do so by visiting the Node.js homepage and downloading the correct version for your OS.

It’s probably a good idea to update your version of Node if you’re running an older version. The following commands will perform that update, however, it should be NOTED that this can mess things up on complicated Node installs. If you’re at the point where you have a complicated Node set up, hopefully you’ve skipped on to creating your first Node App anyway.

sudo npm cache clean -f
sudo npm intall -g n
sudo n stable

Installing Git

Next you’ll want to make sure you have Git installed. You can do so by running the following command:

git --version

If you don’t have Git installed, you can grab it from the Git homepage.

Installing Visual Studio Code

If you’ve done a lot of Node development already, chances are good you already have a development environment you like to use. If that isn’t the case, I’d highly recommend Visual Studio Code. Code is a lightweight code editor with intellisense, code assistance, navigation, and debugging built-in. This editor works on OS X, Linux, and Windows, so no matter where you’re developing you can use it. Head to the Code homepage and grab the installer for your platform.

Creating your First Node App 

Now that you have all the prereqs installed, let’s create our first app on Azure. Now, we could choose to create a local app first, then upload that to Azure, but today we’ll do things in a slightly more easy manner. I’ll post a followup article walking through creating a local site and putting it on Azure later (as there can be a few other steps). We’re going to start things off from the Azure portal. If you don’t already have an Azure account, you can sign up for a Free Azure Subscription here. Don’t worry, everything we’re going to do today is in the free tier of Azure so even if you’ve already used the free trial benefits of Azure, our web application won’t cost a thing.

Let’s go ahead and open the Azure portal. You should get something that looks like this:

This is our administrative and control center for everything in Azure. There’s quite a lot that can also be done from the command line, but we’ll be using the portal today. On the left side, click New then seelct See all to the right of MARKETPLACE, and select Everything from the Marketplace list. Lastly, search for node.js and select Express Web App and then click Create:

If you haven’t used Express before, it’s a minimal web application framework for Node.js. After clicking Create you’ll be asked to name your app as well as pick an App Service Plan/Location and a Resource Group. Click on the App Service Plan and this is where you can select what tier you want to run in (as well as the location). To ensure you’re staying within the Free Tier, select the Pricing Tier and then click View all at the top right. At the very bottom you’ll see the F1 Free tier which runs on shared infrastructure (and does not allow custom domains). Select that (or go ahead and select something else if you’re planning on paying). Finish by naming your App Service Plan and choosing a location. Next you can specify a Resource Group which is just a logical collection of resources. This is useful if you want to check billing and usage for a specific group, limit access and roles to those groups, as well as a few other reasons. When that’s all done, click Create. Those blades will close and after your app is created, you’ll be taken to the blade for it.

Once your site finishes deploying and you’re taken to the blade for it, at the top you’ll see a Browse link that will take you to your running web app:

That will take you to the default Express site which just says:


Welcome to Express

And that’s all it takes to get our Node site running.

Pulling Down the Code

The next step is to pull down the code so we can make changes and push it back up to Azure. FTPS is always an option and it’s enabled for all web apps if you want to use that. Since we installed Git up above though, let’s use that. Return to the Azure portal and your web app. Up above where we clicked on Browse go ahead and click on Settings. This will open a Settings blade with many different options. If you’re new to Azure, the first thing you need to do is scroll down until you find Deployment credentials and click on that. Here you can set a username and password to use with both Git and FTPS. The username will need to be unique so you may have to try a couple times before you succeed. Once that is done and saved, return to Settings and click on Continuous Deployment and then click on Choose Source. There are a number of options we can connect our site to including Visual Studio Online, OneDrive, Local GIT, GitHub, BitBucket, Dropbox, and External Repository. Today we’re interested in pulling down the sample code that was already generated (as opposed to deploying from an existing code source elsewhere) so choose Local Git Repository then hit Ok. You’ll now be taken to a blade that says No deployments found becuase we haven’t deployed any changes yet. Return to Settings and go to the top and find Properties. Scroll down on the Properties blade until you find GIT URL and copy the url. Return to the terminal and clone your repo with the following:

git clone <yourGitUrl>

That should pull all of the code down locally. Let’s look at the file structure we have:

  • public - Contains any static content we want to serve up (stylesheets, images, etc)
  • routes - Contains JS files for any specific routes in our app (index, user)
  • views - Contains any Jade layout files used by our routes
  • node_modules - All installed Node modules
  • package.json - A JSON file specifying all Node packages we’re using
  • favicon.ico - The small icon that shows up for your site in the browser
  • server.js - The server file that sets up Express, sets up routes, etc
  • web.config - A web configuration file that tells the web server running web apps to run Node

Let’s take a quick look at the web.config file so we understand what’s going on:

     This configuration file is required if iisnode is used to run node processes behind
     IIS or IIS Express.  For more information, visit:
               <!-- indicates that the app.js file is a node.js application to be handled by the iisnode module -->
               <add name="iisnode" path="server.js" verb="*" modules="iisnode"/>
                    <!-- Don't interfere with requests for node-inspector debugging -->
                    <rule name="NodeInspector" patternSyntax="ECMAScript" stopProcessing="true">                    
                        <match url="^server.js\/debug[\/]?" />

                    <!-- First we consider whether the incoming URL matches a physical file in the /public folder -->
                    <rule name="StaticContent">
                         <action type="Rewrite" url="public{REQUEST_URI}"/>

                    <!-- All other URLs are mapped to the Node.js application entry point -->
                    <rule name="DynamicContent">
                              <add input="{REQUEST_FILENAME}" matchType="IsFile" negate="True"/>
                         <action type="Rewrite" url="server.js"/>

          <!-- You can control how Node is hosted within IIS using the following options -->
        <iisnode watchedFiles="*.js;node_modules\*;routes\*.js;views\*.jade"/>

You can read through the invidual lines to understand what’s going on specifically but concisely, we’re telling IIS (which is what is running our web app) to run Node and run the server.js file.

Running Locally

The next step is to run our site locally. Return to the terminal and navigate to your site’s root directory. Then type this:

node server.js

That should start your application listening on port 3000. So go to the browser and navigate to and you should see the same web site running.

A Small Change

Now, open the site in whatever editor you prefer and open the routes/index.js file and make a change to the title (here I’ve changed it to AzureExpress):

 * GET home page.

exports.index = function(req, res){
  res.render('index', { title: 'AzureExpress' });

Now open up views/index.jade and modify the text (here I’ve added on Azure to the end):

extends layout

block content
  h1= title
  p Welcome to #{title} on Azure

Now we can use Git in the terminal to commit our changes like so:

git add .
git commit -m "Modifying the index"
git push origin master

If you stay in the terminal now, you’ll see a number of remote updates that indicate that Azure is doing a redeploy of your site. After a few moments you should messages that say Finished successfully and Deployment successful. If you return to your site in the browser, you should now see it is updated. If you go back into Settings and Continuous Deployment in the portal, you should also now see that a new deployment has shown up:

You can also click on that deployment and see a log of the deployment steps as well as redeploy older versions.


Today we went from zero to having Node, Git, and Visual Studio Code installed. We also deployed a new Node.js Express app into Azure, pulled the code down, made local changes, and redeployed it using Git. All of this in only a matter of minutes and without having to do anything complex. From here though, the sky is the limit in what you can build. Additionally there are a LOT of features of Web Apps that we didn’t look at. A great way to get started with understanding some of the other built-in features is to scroll down the Settings blade in the portal.

Last year in November, I helped with an event in New York called Connect(). At that event, one of the things we showed off was the next generation build system for Visual Studio Online (VSO). This system enabled building of all sorts of apps. More than just building the apps though, it also enabled running unit tests, fulfilling the needs of continuous integration, and also allowed for additional abilities like packaging up an application, sending the results somewhere, and much more. What was so great, and was really the reason for my involvement, was that this next gen build system worked with so many platforms and programming languages. Of primary importance to me: Android and iOS. You can watch the full annoucement related to the VSO build system here if you like.


Not long after Connect() (in fact only a month later), Microsoft announced it was acquiring HockeyApp. If you haven’t heard of HockeyApp, it enables you to distribute Android, iOS, and Windows Phone apps through a beta distribution channel, gather feedback, as well as crash analytics. If you’re an iOS developer, you’ve probably heard of TestFlight which provided similar functionality prior to being acquired by Apple (and kind of does again). On the Android side, Google eventually added beta distribution to Google Play, but at the time it wasn’t as fully featured as HockeyApp. If you’re using those services and are building apps for both iOS and Android, that’s two completely different processes. HockeyApp provides one streamlined process for all kinds of apps.

The Point

The point of all of this is that if you add these two pieces together, we should be able to make an Android application, set up continuous integration with VSO, then tie into HockeyApp for beta distribution. What we should be able to do is build our app whenever the code is checked into VSO, run the unit tests, and if they pass, deliver a new version of our application to HockeyApp to distribute to our beta testers. How magical would this be? Well today, I’m going to explain how to do it.

Visual Studio Online

The first step is you need to create an account on VSO. You can do that by going to the Visual Studio homepage and clicking the link for Get started for free under Visual Studio Online. That will prompt you to login with a Microsoft account (or a work or school account). Now if you’re not familiar with VSO, in my mind it is first and foremost a version control system. A FREE one that has support for both Git and Team Foundation. Within the free tier of VSO, you can have up to five contributers. So you can have up to 5 people all contributing on the same project for free. Above and beyond the source control, you also get project management: work items, bugs, tasks, etc.

When you first sign up, you’ll create your first project. This is where you can choose between using Git and Team Foundation Server. Once that is done, you’ll need to check your code in. I won’t dive into all of the details of getting your code into VSO but you can read more about it here. Once your code is in, it’s time to get building set up.

Let’s Get Building

Now that your code is checked in, it’s time to set up a build. You first need to navigate to your projects home page and then go to the BULD tab. You can also find it by going to a URL that will look like this Make sure you replace the two placeholders there. For example, my org name is *ChrisRisner* and your project would be named whatever you created in the steps above.

VSO Build Definition

If this is a brand new project, you won’t likely have a Build Defintion already. Click the green addition symbol in the top left to add a new definition. Currently there are only four definitions available (Visual Studio, Xamarin.Android, Xamarin.iOS, and Xcode). None of these will work for us, so choose Empty and click OK. The next step is to begin to add some build steps so click the + Add build step… link.

VSO Build Definition

Here we’re looking for the first (currently) option for Android Build. Click the Add button next to that and then click the Close button at the bottom.

VSO Build Definition

Now we can configure the Android Build steps. For Location of Gradle Wrapper navigate to find your gradlew.bat. For Project Directory choose where your project resides in the repository. For Gradle Arguments depending on when you do this, there may be a default one for build. If nothing is there, put in clean build to ensure APKs are compiled. You then have some options for Android Virtual Device, Emulator Options, and Control Options. We may look at those in more detail another time. For now, Save your changes. Once you’ve done so the Queue build… button should now be available to be clicked. Go for it! If you haven’t done anything different from above (create a Queue, used different branches, etc) you’ll be able to click OK on the next popup and the build will be queued. Since we’re not using our own build agent but a public grouping of them, you may have to wait for the bulid to start, but you should immediately be taken to a window with a text console that will print out as the build proceeds:

VSO Build in Progress

You’ll need to give that some time. On my fairly simple app (a few activities and a few dependencies) the build took 4.4 minutes to complete. If you have a success, you’ll get something like this:

VSO Build Successful

If your build wasn’t succesful, you’ll get a much less fun Build Failed. However, you’ll be able to get all of the details on WHY it failed:

VSO Build Failed

The screenshot above is from an earlier build I’d done on my project. At that point, VSO wasn’t yet including the proper repositories for the appcompat and design libraries within Hopefully if you run into any issues it has to do with something you can fix. If it’s something like the issue above, reach out to the VSO team for help.

Setting up HockeyApp

The next step is to connect our build so when it’s done, it sends something over to HockeyApp. If you don’t already have an account, you can sign up for a free trial at Once that is done, you should create a new app (unless you already have an app setup). After that we’re going to do some work on the command line to add the HockeyApp task to VSO. Go to the Terminal and enter the following:

sudo npm install -g tfx-cli
tfx login

When you log in, the first prompt will be for your Collection URL. You can get this from the URL of your VSO project. Unless you’ve set up custom collections, you’re probably looking at a URL like this: The second prompt is for your *Personal Access Token*. In order to generate an Access Token, you should go to VSO, click on your name in the top right, and click on **My profile**. From there [follow these steps to create an Access Token]( Afterwards, enter your token in the Terminal and proceed and you should recieve a *logged in successfully* message. Next we install another node module and upload it:

sudo npm install -g
cd /usr/local/lib/node_modules/
tfx build tasks upload ./ --overwrite

You should then see a message that the task was uploaded successfully.

Connecting HockeyApp and our build

Return to VSO in the browser. Go back to your Build Definition and click the Edit button. Click the Add build step… button and find HockeyApp (you’ll need to swtich the filter to All or Deploy) and click *Add:

VSO HockeyApp Build Step

Now you can close that window and open the HockeyApp build step you just added. Now we have quite a few config options to look at:

VSO HockeyApp Build Step

I’ll provide some detail on the current options but you can also read about them here.

  • HockeyApp API Token: This is a token which you can generate for all apps or a specific app here
  • App ID: This is the ID which you can find at the homepage for your app within HockeyApp. If you leave it blank, HockeyApp will try to auto figure things out based off the Bundle ID or Identifier of the app.
  • Binary File Path: Based off of creating a new project in Android Studio, the path here should be: {AnythingBeforeTheAppFolder}\app\build\outputs\apk\app-debug.apk. So for example, my path is android\app\build\outputs\apk\app-debug.apk.
  • Symbols File Path: The path to your mappings.txt file if one is being generated. Not required.
  • Release Notes: Any release notes you’d like to be entered to be sent over to HockeyApp for the app release.
  • Publish?: Should HockeyApp users you’ve set up be able to download this version.
  • Mandatory?: Is this a mandatory install for users.
  • Notify Users?: Should users be notified that there is a new version for them to download.
  • Download Restrictions: These allow you to restrict who can download this version based off tags, teams, and users defined in HockeyApp.
  • Control Options: Normal Build Step options for enabling, continuing on error, and if it should always be run.

Once you’re done, click Save and hit Queue build…. After hits the queue and builds, you should see the task for HockeyApp at the bottom:

VSO HockeyApp Task Running

After that, if you go into HockeyApp you should see a new version of your application:

HockeyApp Versions

Since I had added myself as a user of the app and chose to Publish and Notify Users, I received an email shortly afterwards telling me there was a new version of my application and had it installed through the HockeyApp Android app moments later!


With Visual Studio Online, we have the ability to easily create Git repos for source control management, as well as the ability to manage our projects with work items, bugs, tasks, kanban boards etc. By connecting that with the build system, we’re able to easily set up Continuous Integration. Adding HockeyApp to the mix gives us the last piece with Continuous Delivery. Now we can easily enable our application to be built with every checkin and delivered right to our beta testers.