Menu

I’ve committed myself to learning as much Azure Mobile Apps as possible. Internally, this project is called Zumo (Azure Mobile glued together) and several sites have shown this name with reference to Azure Mobile Services. Azure Mobile Apps is Zumo v2. It’s a server SDK that runs on top of a web site. This has some really interesting things about it – like you can use all the features of Azure Web Apps (staging slots, scaling, backup and restore, authentication) and use the same API within the Web App and Mobile App. Each one of the 30 days of code will cover a topic and cover it in an hour.

To get started, you’ve got to have an Azure subscription. Sure, you could use TryAppService to create a backend, but that only lasts for an hour and it’s very restrictive – you don’t get to alter the backend code. If you haven’t already, there is a free trial that lasts 30 days. Once you get beyond the 30 days, you can run a development site for free.

Day 1: Setup

Day 1 is all about setup. I am going to do all my development on a Mac. Why not a PC with Visual Studio? Visual Studio is a very specific environment and doesn’t lend itself to iOS development. I want the experience to be as raw as possible and entirely free. Developing on the mac tends to be a little more painful when you are used to an integrated environment like Visual Studio. Visual Studio, however, hides a lot of details from you. When things “just happen”, you tend to not learn what’s behind them and debugging capabilities get lost. I want to avoid that, so I’ll be using the command line, the Azure Portal and a simple text editor.

What else do I need?

A Text Editor

What’s your favorite code editor? On a mac, mine is Atom. There are a bunch of decent plugins for Atom and I’ve covered some of them in the past. I’ll probably do another post at some point about my favorite Atom plug-ins for JavaScript development. I also like Visual Studio Code, which also has some great plug-ins. I’ve heard good things about Sublime Text as well. All three of these editors are available on Mac and Windows.

I’m not advocating for a specific text editor here. There are things you definitely want: a monospace font and syntax highlighting would be enough. Just pick your favorite.

One thing to avoid is something “heavy”. Eclipse, for example, falls into this “heavy” camp. It’s marginal on the functionality improvements, yet it’s startup cost and memory utilization make it distinctly second-rate for what I want to do – edit files.

Google Chrome

Yes, I’m being specific here. Google Chrome gets its developer tools right. In addition, you will want a few plugins. The most notable is Postman – a mechanism for executing REST calls and viewing the output.

Git

Again, I’m being specific here. There are several git tools, but they all implement git. Don’t try and get something else. I am going to be putting things on GitHub, which uses git underneath. There is Git for Mac and Git for Windows. I’ll use these tools for storing my code in a source code repository on GitHub and for querying Azure App Service.

A Command Line

If you are on a mac, there is a command line under Application-Utilities. If you are on a PC, then you have the PowerShell prompt, although I prefer ConEmu a little better. Since I’m not going to be using Visual Studio, I want somewhere to execute commands.

XCode (Mac Only)

If you are developing iOS applications, then the compilation step must use Xcode and must run on a Mac. Android applications don’t care. Windows applications don’t require a specific compiler, but you have to compile on Windows – when I get to that, I’ll switch over to Windows and use Visual Studio. There will be some points at which you will be asked to start Xcode and accept the license – at which point, you might as well download it. You can do this from the Apple App Store. Note, however, it’s a 1+Gb download, so it takes some time.

An FTP Client

I like a graphical ftp client for this. It allows me to browse the App Service behind the scenes. You can find a good list on LifeHacker. Personally, I use Cyberduck for this.

After the software, you will also need a GitHub Id – I’m going to store my code on GitHub, so there will be a repository on GitHub.

Let’s get started

The Azure Documentation already adequately covers creating an Azure Mobile App. I recommend following that tutorial to get your Azure Mobile App created and then hooked up to a SQL Azure instance. You can follow any of the tutorials – you will end up with a mobile site and a client that implements a simple TodoItem hooked up to the mobile backend.

One word on pricing and what sort of app pricing plan you should choose. There are several types of site sizing and they offer some interesting choices. Here is the breakdown:

Note that Basic does not offer all the features of Standard and Premium. In fact, Standard offers many features that you should be interested in:

Auto-scaling – while not an issue in development, will be an issue in production applications. You want your application to grow as demand grows, automatically. Basic only scales manually and only has a limited scaling

Staging Slots – this is an awesome feature that I’ll discuss in a later blog post. One of the things this allows you to do is to upload a new site, test it out and then swap out the production version, all with zero down time.

Backups – we like backups. They are important. Standard adds a daily backup.

Premium adds more disk space, Biztalk services, more staging slots and more backups. Most developers can get away with Basic edition since developers only need limited scalability (to test what happens when the service does scale) and don’t need staging slots. There are two other tiers – Free and Shared:

Note the lack of features. Free and Shared are great if you are just learning but you will find them painful to use. Spend some of your Azure free trial credits on a minimum of Basic.

Note that I’m not saying anything about the options available on SQL Azure here. The pricing when you create an App Service has nothing to do with SQL Azure. To get your effective pricing, you need to add your App Service plan to your SQL Azure plan:

For most normal learning activities, you can use a B-Basic plan for your SQL Azure. If you want to try out Georeplication or you have bigger data needs, you can use an S0-Standard. The pricing goes up from there. As with App Service, there is a Premium offering that adds Active Georeplication – good for those mission critical revenue-on-the-line type of apps.

Want a completely free version of this? Make sure you pick an F1-Free App Service plan and an F-Free SQL Azure plan. Want to learn everything that there is to learn about the platform without altering? Pick an S1-Standard App Service plan and an S0-Standard SQL Azure plan. However, you can upgrade your plan at any point, so this allows you to start small and move up in cost as you need to.

If you are learning or developing and do pick a standard plan, make sure you shut down the App Service at the end of your activity. This will save you some cash at night when you aren’t using the service.

Setting up for Development

So, I’ve got my site all set up. I also have a nice iOS Todo app that allows me to add TodoItems (I used the Swift version, since I’m mildly interested in learning the language), but I have not been shown any of the server code as yet. I want to set up something else here – Continuous Deployment. To configure continuous deployment, I’m going to do the following:

Create a GitHub repository

Clone the GitHub repository onto your local machine

Download the source code for the site I created

Check in the source code for the site into GitHub

Create a branch on GitHub for Azure deployment

Link the site to deploy directly from GitHub

This is a cool feature. Once I’m set up, deployment happens automatically. When I push changes to GitHub, the Azure Mobile App will automatically pick them up and deploy them for me. Here is how to do it:

1. Create a GitHub Repository.

Log onto GitHub

Click on the + in the top right corner of the web browser and select New Repository

Fill in the form – I called my repository 30-days-of-zumo-v2

Click on Create Repository

2. Clone the repository

Open up your command prompt

Pick a place to hold your GitHub repositories. Mine is ~/github – if you need to make the directory, then do so.

Change directory to that place: cd ~/github, for example

Type in:

git clone https://github.com/adrianhall/30-days-of-zumo-v2

You will replace the URL with the URL of your repository – this was displayed when you created the repository.

3. Download the Azure Website

First step is to set your deployment credentials. Log onto the Azure Portal, select your site then select All Settings. Find the Deployment Credentials option, then fill in the form and click on Save. I like to use my email address with special characters replaced by underscores for my username – this ensures it is unique. Make your password very hard to guess. Use a password manager if you need to.

Let’s get the requisite information for an ftp download:

The server is listed on the starting blade of your site, but will be something like ftp://waws-prod-bay-043.ftp.azurewebsites.windows.net

Your username is SITENAME\USERNAME. The SITENAME is the name of your site. The USERNAME is what you set in the deployment credentials. This is listed on the starting blade as well, right above the FTP Hostname.

Your password is whatever you set in the deployment credentials.

Open up Cyberduck, enter the information (uncheck the anonymous checkbox) and click on Connect. You can use ftp or ftps protocol – I prefer ftps since it’s designated secure – information is transmitted with SSL encryption, including your deployment credentials.

You will now be able to see the site. Expand the site node then the wwwroot node. Highlight everything in the wwwroot node, right-click and select Download to…. Put the files in the directory you cloned from GitHub.

4. Check in the code for your site

Before you go all “git add” on this stuff, there is some cleanup to do. Right now, the site is set up to use Easy Tables and Easy APIs – there are some extra files that you don’t really need. That’s because we are going to act like developers and keep our files checked into source code control. That really means we can’t use Easy Tables and Easy APIs. Those facilities are great for simple sites and I highly recommend you check them out. But you will leave them behind once you get serious about developing a backend – you will write code and check it into a source code repository.

Let’s start by removing the files we don’t need because we aren’t going to be using Easy Tables or Easy APIs:

sentinel

tables/TodoItem.json

We’ll also remove the files that are handled by the server or restored during deployment

node_modules

iisnode.yml

webconfig.xml

You can do this within your GUI or on the command line with the rm command. On Windows, use rimraf:

npm install rimraf -g
rimraf node_modules

Finally, add a .gitignore file – go to https://gitignore.io, enter Node in the box and click on Generate. This will generate a suitable .gitignore file that you can cut and paste into an editor.

You are now ready to check in the initial version. Make sure you are in the project directory, then type:

git add .
git commit -m "Initial Checkin"
git push -u origin master

This will push everything up to the master branch on GitHub.

5. Create an Azure deployment branch

You can do this from the command line as well. Make sure you are still in the project directory, then type:

git checkout -b azure
git push -u origin azure

This will create an azure branch for you to merge into (more on that later), then push it up to GitHub.

6. Link the azure branch to continuous deployment

Log back on to the Azure portal and select your site. Click on All Settings, then click on Deployment Source. Select GitHub as your deployment source. You will probably have to enter your GitHub credentials in order to proceed. Eventually, you will see something like this:

Pick your project (it’s the GitHub repository you created) and the azure branch. Once done, click on OK. Finally, click on Sync.

Something completely magical will happen now. Well, not so magical really – that comes later. The Azure system will go off and fetch the project. It will install all the dependencies of the project (listed in the package.json) file and then deploy the results. The magical piece happens later – whenever you push a new version to the azure branch, it will automatically be deployed. You’ll be able to see it happen.

This post went a little longer than I planned, but I’m not all set up for continuous development on Azure. In the next post, I’ll look at upgrading the Node.js version and handle the checkin and merge mechanism. In addition, I’ll look at a local development cycle (rather than deploying) using the SQL Azure instance I’ve set up.