Running node.js tests when deploying to Azure Websites

By default, Windows Azure Websites does not run your unit tests when you push a new deployment. However, it’s quite straight forward to set this up.

If you haven’t already done so, install Azure Command-Line tools for Mac and Linux (they work just fine on Windows too).

> npm install -g azure-cli

Now navigate to your node app, and run a command which will create a custom deployment script for you:

> azure site deploymentscript --node

This will add the following files to your directory:

deploy.cmd
iisnode.yml
web.config

The deploy.cmd file is executed every time you push your repository up to Azure. You can customise this to include some testing, here is a snippet with NPM TEST added (in bold).

...
IF NOT DEFINED KUDU_SYNC_COMMAND (
 :: Install kudu sync
 echo Installing Kudu Sync
 call npm install kudusync -g --silent
 IF !ERRORLEVEL! NEQ 0 goto error
:: Locally just running "kuduSync" would also work
 SET KUDU_SYNC_COMMAND=node "%appdata%\npm\node_modules\kuduSync\bin\kuduSync"
)
npm test :: THIS LINE HAS BEEN ADDED TO RUN THE TESTS
::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
:: Deployment
:: ----------
...

You’ll need to add these files to your repository (assuming you’re using git) and push the changes up.

> git add .
> git commit -am "adding custom deployment script"
> git push azure master

Your tests will now run, and the deployment will fail if the tests fail! The error message can be viewed by expanding the detail of the deployment.

Advertisement

Comparing Azure Website Scaling Options

I thought it would be interesting to compare the different scaling options of Azure Websites. I did this by scaling a website I had running, and looking and the allowances shown on the monitoring page of the portal.

Scale	CPU hours/day	RAM	Dollars/month
Free + **	1	1GB	$0.00
Shared (1 instance) +	4	0.5GB	$9.36
Shared (6 instances) +	6 * 4 = 24?	6 * 0.5 = 3GB?	$56.16
Reserved (1 instance)	24	1.75GB	$57.60

Did you notice that? You start paying and the available RAM goes down (1 shared instance has 0.5GB)!

When I scale to 6 instances of shared, the quotas don’t go up, but presumably the figures are then balanced across 6 machines – hence the question marks.

I also notice that 6 Shared instances is slightly cheaper than 1 Reserved, and have considerably more RAM (according to my maths). I think it’s probably better to spread your application across more shared instances, giving you better resilience.

It would be really useful is some benchmarking figures as an extra column, does anyone have any numbers?

 

None of these prices include the costs incurred for outbound data or storage.

+ With Free and Shared, there is also a limitation on 2.5 minutes of CPU every 5 minutes.

** With Free, there is a limitation of 165MB data out per day.

Azure Websites, Settings and Connection Strings

(not) Putting settings and connection strings directly in your source code seems to be topical at the moment. There seem to be plenty of GitHub projects where people are publishing these settings for all to see. With Azure Websites it’s quite easy to add settings and connection strings in the portal, and leave them out of your source code:

With a Node.js application they can be accessed as environment variables in this way:

   process.env.setting1 = 'value1'
   process.env.APPSETTING_setting1 = "value1"
   process.env.SQLAZURECONNSTR_connectionstring1 = "connectionstringvalue1"

So long Haskell, and thanks for all the type inference

I set myself the challenge of learning Haskell in 2012.

I failed.

I learnt a lot about Haskell, I read a book, I tried to write some code. I didn’t really get very far past ‘Hello World’.

I put this down to a few things:

1. The concept count is high. It would take me a very long time to get productive, and this was frustrating.
2. Node.js (which I had also been learning during this time) is easy to learn, and seems to do more interesting things right out of the box. I got very productive in Node very quickly. This made Node far more interesting, so I didn’t devote enough time to Haskell.
3. Haskell is very terse, too terse for me. I cut my teeth on on Pascal!
4. I couldn’t find a problem to solve. I didn’t really know what to write.

Anyway, whilst I didn’t get productive (perhaps this was an unrealistic expectation) I did learn a lot about Haskell. I can recommend the ‘Learn You A Haskell‘ book. I had the paper version, but the online edition is probably better as the code samples are syntax highlighted. It helped me appreciate lazy evaluation, pattern matching, and currying. It’s changed the way I write C# (which has some very simple functional programming concepts) and it’s opened my mind to functional programming.

Is Haskell a toy language? I don’t think I know enough to form an opinion. I do think that languages like JavaScript are successful because they are simple. I think Haskell’s concept count has kept it from becoming really mainstream, but if it didn’t have these concepts, it wouldn’t be Haskell, and I don’t think that Haskell cares about fame anyway.

I recommend learning new languages. It’s OK if you don’t become an expert in a year, but simply learning about them will help you to appreciate the wider development world.

So which language to look in 2013? On the shortlist are: Erlang, Python and C++11.

 

Windows 8 App Store

I recently released a couple of apps to the Windows Store. The publishing experience was impressive, after I got to grips with the process it took me an hour to go from idea to app waiting for approval in the store, and one working day for approval. OK, the app is a really simple one page thing, but it shows that the process is efficient, and you can go from idea to released app in a day. That’s impressive.

I learnt a few things along the way:

1. Your app must pass the Windows App Certification Kit, which doesn’t seem to work correctly if Chrome is your default browser.
2. It’s a good idea to start certifying you app using this kit from the start, rather than leaving it to the end. It may change the approach you take, if something you rely on doesn’t work. I found the sample project template in Visual Studio failed during suspension tests.
3. Changing the Package.appxmanifest file during development resets any data that your app has saved to the local disk. My guess is that Windows treats it as a new app, so you’re starting from scratch.
4. Review the capabilities and declarations your app uses. Turn off anything you don’t need.
5. Take time to browse through the existing apps in the store. Come up with a unique angle for your app, make sure the screenshots you use really sell these features.