Friday, March 11, 2016

Development Workflows for Azure Mobile Apps

Azure Mobile Apps offers a great development experience for all levels of development expertise and application complexity. The online editing experience works exceptionally well with a responsive UI, immediate updates, comprehensive intellisense and great git integration.

For more experienced developers, a (mostly) comprehensive local development experience is provided, with a simple transition between online and local development.

This article assumes a basic familiarity with creating Mobile Apps in the Azure management portal ( and with git repositories.

The Online Experience

The online development experience is centered around VS Online and is enabled for you when you access Easy Tables in the settings section of a Mobile App. If you're playing with Mobile Apps for the first time, we recommend that you complete the Quickstart section and create a Node.js backend for the Mobile App.

VS Online can be accessed by clicking the "Edit Script" button in Easy Tables or by navigating to VS Online provides a complete IDE with full intellisense for Azure Mobile Apps. Changes made to the application code are effective immediately without requiring a save or rebuild. The IDE is effective for small to medium complexity apps, even with multiple developers.

Using a Github Repository

It's important to note that these workflows do not involve using a local git repository on the mobile app server (as set up in continuous deployment in the portal). Changes are made directly to the wwwroot on the app server. For this reason, it's important to have separate development instances of your mobile app - we don't want to be making changes directly to production!

Here, we'll set up a remote git repository to push your changes to, allowing multiple developers to work on the same code, enabling a simple production deployment scenario and keeping your code safe, secure and versioned.

Configuring VS Online

  1. Create your github repository. Copy the git URL to the clipboard.
  2. Return to VS Online and open the console by pressing ctrl-shift-c.
  3. Type the following commands into the console:
    git init
    git remote add origin 
    git config --global 
    git config --global 
    git add -A
    git commit -m "Initial commit"
    git push -u origin master
You are now set up to use the git user interface built in to VS online, or standard git commands like add, commit and push in the console.

Adding Other Developers

Each developer will have their own mobile app instance and will sync changes using the git repository we created.

For this step, we recommend enabling the VS Online extension separately. Open the new mobile app in the portal, click the Tools icon and open the Extensions section. Follow the prompts to install VS Online.

Open VS Online for the app and type the following commands into the console:
git clone  .
git config --global 
git config --global 
npm install
The . at the end of the first command is important - it tells git to clone into the current directory. Note that the directory must be empty.

Configure your data connection, and you are ready to go. Again, the VS Online git user interface works great, or standard git commands can be used in the console. git pull can be used to sync changes that other developers have pushed to the repository.

Transitioning to Local Development

Transitioning to editing and running your project locally is much the same as the "Adding Other Developers" section above, except running the commands in a console on your local computer.
Ensure Node.js is installed on your computer and run the following commands:
git clone 
npm install
Starting the mobile app backend can then be done by running
node --debug ./server.js
The server by default runs on port 3000 - you must configure the mobile app URL in clients to be http://:3000/

For full intellisense and integrated debugging, we recommend using VS Code to edit your project.

Configuring a Production Environment

In this part, we are going to create our production mobile app server and set it up to automatically pick up changes that we want to publish from our development environment.

Setting Up Publishing (Continuous Deployment)

To set up automatic publishing, we will use a great feature of Azure Web Apps, continuous deployment. This monitors a git repository for changes and syncs automatically.

First, we want to create a new branch in our git repository - we don't want to publish every change to production, only when we pull the trigger. Open a VS Online console on a developer instance and enter the following commands:
git checkout -b publish
git push origin publish
git checkout master
Don't forget to enter the last line! It switches you back to working on your development branch.

Next, create your production mobile app server and configure the data connection. Once created, open the continuous deployment section in publish settings, select GitHub as the source and follow instructions to point at the new publish branch of your github project.

After clicking OK, watch your project sync and be ready for use!


Deploying to production is now a simple matter of merging the master branch into the publish branch. For small changes, you can do this by opening the console of a developer instance and entering the following commands:
git checkout publish
git merge master
git push
git checkout master
However, for most changes, we highly recommend taking advantage of github's pull request functionality, allowing you to see your changes line by line and discuss them with other developers before you publish to production.

Reviewing Changes Before Publishing

After you have pushed your changes to the master branch, open your github repository in a browser and click the "New pull request" button. In the base branch dropdown, select our publish branch and then click "Create pull request".

Once the review is complete, click the "Merge pull request" button and the changes will be deployed to production. You can watch the deployment take place in the continuous deployment section of the production instance in the portal.

Final Thoughts

It's important to note that this guidance is intended to serve as a basic framework for a development workflow. It is by no means comprehensive - it does not include testing (more on this later) and does not take advantage of other great Azure features like staging slots.

Comments? Questions? Join the conversation on gitter!

Labels: , , , , , , ,


Post a Comment

Note: Only a member of this blog may post a comment.

<< Home