Teach your Azure Website new deployment tricks with azure-cli 1 of XXX: Running Mocha ...


: 3

Disclaimer: This post is based on content I previously posted here and which should really be its own series.

Every time you deploy your Website, the server runs a bunch of steps which vary depending on the application. If it is a node.js application for example it will run npm if it sees a package.json present to install node modules.

Wouldn’t it be cool (and useful) if you could customize that step to do whatever you want, like run mocha unit tests? If you said yes, then you don’t have to wish any longer, it’s here.

To customize deployment you use a new command on the azure-cli, “azure site deploymentscript”. This will generate for you a script either in .bash or .cmd format which contains all the server logic that will execute when your site is deployed. You can then easily customize that script to your heart’s content.

For more details on how this command works and further examples including with an MVC app, check out Amit Apple’s nice series.

When you use this feature, you really are too cool for school!.

To see it in action, I am going to show you how to enable a common scenario (and timely based on my last Mocha debugging post), that is make my mocha scripts run for my node app every time I push via git. Assume I created a simple express hello world by running the “express” cli.

I then create a dummy test.js which will always fail.

Now in my app folder, I run the deploymentscript command specifying a node app and to create a bash script.


You can see the generated script here in this gist: https://gist.github.com/4331260/revisions by looking at the last file.

If you look at the script you’ll see several different sections.

  • #Prerequisites – This section defines code that should run before anything else. For a node app here is where it detects if node is installed.*
  • #Setup – This handles setting up script variables or installing other necessary modules. For example you’ll see it installs the node “kudusync” module which is used for moving files from where the files are pushed to the target website.
  • #Deployment – This handles actually deploying the code (calling kudusync) and other steps like calling npm for node modules.

*Note: There is a bug currently in the bash version of this, which uses the “where” command to find node which does not work on bash. The fix is in the gist above at line 24.

One great thing about this script, is it is designed to actually allow you to run it locally. It detects whether you are in the local folder and will just create an artifacts folder for the files that are copied over. This is really useful when developing.

For my unit test scenario I want to do things a little differently than the generated script does by default.

  • I want it to install mocha, the same way it installs kudusync
  • I want it to run npm before it copies the files to the website, not after.
  • I then want it to run mocha and if the tests fail I want the deployment to abort.

Doing that means moving a few things around and adding some new steps. In order to make it also work locally there’s some light mental gymnastics, but nothing rocket science.

The final script is the top file in the gist revisions (https://gist.github.com/4331260/revisions)

I’ve annotated the parts I changed with “# gb:” and thanks to github’s awesome diff feature you can easily see the comments and what was changed.

Now when I deploy the site, it runs my tests and I get the output right when I git commit.


Notice above that my tests failed and my website was not updated.

This is just one of many scenarios that are now opened up to you through the new custom deployment feature.

In my next post in the series, I’m going to attempt to show you how to use this to download any custom node version you like the first time you deploy. I don’t know if this is really going to work, but it does in the blackboard of my mine, we’ll just have to wait and see what happens!