In the past few months we’ve really been fleshing out our cli and surfacing more and more Azure services to your fingertips, literally! In this release there is a lot of goodness, I think you are going to like what you see!

Here’s a quick summary of what you should expect to find when grab the latest bits.

• Custom website deployment “azure site deploymentscript”.
• Mobile Service support “azure mobile”.
• Windows installer.
• Service Bus “azure sb”.
• Storage accounts “azure account storage”.

Custom Website Deployment – Deployment your way

One of the common requests we hear is that folks want to customize how their code is deployed in their Azure Websites. For example, some folks want to run a custom step on the server every time they deploy to a staging environment.

In this release, we’re introducing a new command for doing just that, “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.

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, 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 created 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.

Mobile Services

With this release we’re bringing you commands for Windows Azure Mobile Services so you can create mobile back ends for your Win 8, Windows Phone, IOS and Android applications right from the shell. You can create new services, provision databases, create and query tables, manage scripts and more with just a few commands!

Below you can see that I am creating a new Mobile Service using “azure mobile create”. In the create call I’ve passed my service name, user and password and that’s it.

As you can see it has created a new service, and deployed a new SQL Server and Database. You can also pass parameters in like –sqlServer and –sqlDb to use existing servers and databases.

Next I use “azure mobile table create” to create two new tables and display their details.

Now that I have tables, I can even upload a script using the “azure mobile script upload”, list existing scripts with “azure mobile script list” and download using “azure mobile script download”.

With my scripts in place, I am now ready to build my mobile app to consume my mobile service. To talk to the service I need my application url and key, which I can get thanks to the “azure mobile show” command.

For this example, I built a very simple example that looks a whole lot like our hello world that we create in the portal only morphed to a mini contact manager 🙂

Now that I have data there’s one more bit of icing on the cake, I can query my tables right from the cli!

This is just a preview of the features “azure mobile” offers. Type “azure mobile –help” to see what else is in the box.

CLI Installer for Windows

With this release we’re introducing a one click, no hassle installer for Windows. 

That means if you are not a node developer, you don’t have to worry about installing, node, getting the module from npm, etc. Use the installer and everything is taken care of for you.

Download the installer here.

Storage Accounts and Service Bus

If you are using our SDKs to talk to Windows Azure Storage or Service Bus then you are most likely using the Azure portal to create your storage account or namespace and to manage your keys. No longer is that the case! You can now use the cli for both.

Storage Accounts

Below you can see where I am creating a new storage account using “azure account storage create” and then retrieving the storage keys.

Service Bus

Next I am creating a new Service Bus namespace using “azure sb namespace create”. Notice you get returned the connection string which you can then pass directly to our SDKs when you use them.

You can also retrieve the namespace information (including connection string) at any time by using the “azure sb namespace show” command.

More good stuff on the way

Over the coming months, you are going to see some really useful (at least we think so) features finding their way into our new CLI. For example today you can only work with accounts and subscriptions, but in the future you’ll be able to also work directly with Storage and Service Bus like uploading blobs, querying tables or even sending messages.

And just to whet your appetite, here is a preview of one more very useful feature you’ve been asking for ;-). (Make sure to read what it says by ‘.description’)

@gblock