Azure Mobile Services: Creating Development and Production Environments

Scope

The purpose of this article is to show how to create development and production environments for a .Net Backend from Azure Mobile Services.

Introduction

According the MSDN Documentation,

Microsoft Azure Mobile Services is an Azure service offering designed to make it easy to create highly-functional mobile apps using Azure. Mobile Services brings together a set of Azure services that enable backend capabilities for your apps. Mobile Services provides the following backend capabilities in Azure to support your apps:

• Client libraries support mobile app development on various devices, including Windows 8, Windows Phone 8, iPhone and iPad.
  
  
• Simple provisioning and management of tables for storing app data.
  
  
• Integration with notification services to deliver push notifications to your app.
  
  
• Integration with well-known identity providers for authentication.
  
  
• Precise control for authorizing access to tables.
  
  
• Supports scripts to inject business logic into data access operations.
  
  
• Integration with other cloud services.
  
  
• Supports the ability to scale a mobile service instance.
  
  
• Service monitoring and logging.

This way Azure Mobile Services will increase the mobile application development and the fact it is available for the main mobile platform is an additional advantage. In some scenarios, more specifically when new features are provided to the mobile applications that are published to the store and used by users, a different environment from the Azure Mobile Service can be required, because each version can change or even break the last backend version from Azure Mobile Service and is important to test and keep the production. Azure Mobile Services allow to test the services in localhost, but does not provide a way to have multiple environments and to create multiple environments required to have one Azure Mobile Service for each environment and then create a configuration for each one.

Description

To create a development and production environment for a .Net Backend, Azure Mobile Services is required to create a Development and Production Backend and then it is possible to create the Development and Production profiles based in transform files.

Let's see it in more detail.

Creating the Azure Mobile Services

In Azure Portal, create two .Net Backend Azure Mobile Services, let's call it as follows:

- For the development environment:


• MyAMSDev: the Azure Mobile Service name
• MyAMSDev_db: the database name

- For the production environment:


• MyAMSProd: the Azure Mobile Service name
• MyAMSProd_db: the database name

In Azure Portal, the result will be:



And:



It is possible to use the same database, but for that it is necessary to use various schemas and if various databases are provided it is easier to manage each environment (update or even delete). A Backend that uses Entity Framework migrations will recreate the service from the scrats and with it any time it can be delete, deployed and recreated.

To read more about the procedure required to create an Azure Mobile Service, read the following article: How to create the MyMenuApp Azure Mobile Service.

Creating Transform File

In Visual Studio, select the solution and open the context menu as in the following:



Then click in Configuration Manager as in the following:



And then create a new configuration as in the following:





In this case, a Development configuration is defined based in the Debug configuration and to the Production configuration should be used the Release configuration as in the following:



At this moment, it is possible to define Debug, Development, Production and Release configurations as in the following:



Or



For each configuration it is possible to define the conditional compilation. For example, in Development it is possible to have:



And in Production it is possible to have:



In reality it means we can do:

#if Dev
                  // for example can fill the database with fake data
#else
                  // in other environment different from Dev
#endif

To have the advantages of this configuration using the Web.Config, let's add the config transform as in the following:



Which the result will be:



Now it is possible:

• To set in the Web.Config, the connection string to the local database, used by the localhost.
  

  <connectionStrings>
     <add name="MS_TableConnectionString1" connectionString="Data Source=LT114925;Initial Catalog=MyAMSLocal;Integrated Security=True;MultipleActiveResultSets=true" providerName="System.Data.SqlClient" />
    </connectionStrings>

• To set in the Web.Dev.Config, the connection string to the MyAMSDev_db database, used by the Development environment (or even the local host!).
  

  <connectionStrings>
        <add name="MS_TableConnectionString1"
          connectionString="<connection string from MyAMSDev_db>"
          xdt:Transform="SetAttributes" xdt:Locator="Match(name)"/>
      </connectionStrings>

• To set in the Web.Prod.Config, the connection string to the MyAMSProd_db database, used by the Production environment.
  

  <connectionStrings>
        <add name="MS_TableConnectionString1"
          connectionString="<connection string from MyAMSProd_db>"
          xdt:Transform="SetAttributes" xdt:Locator="Match(name)"/>
      </connectionStrings>

  And in each deploy the respective Web.Config will be used.

Let's publish the service to Azure.

Select the project and using the context menu click in Publish, as in the following:



Then connect to Azure Mobile Service, using the Azure Account and select the MyAMSDev as in the following:



In Settings, set the configuration and the file publish options (only!).



And then publish it!

Do the same process to Production, as in the following:



And then publish it!



At this moment, both environments are deployed and running and it is not necessary to define or change each environment in the future, it is only necessary to pay attention to each one to be set before deployment.

Notes

1. In this case the MS_TableConnectionString1 name was used to define the connection string and the default value MS_TableConnectionString, defined in Azure Portal, will be ignored.
   
   A developer can set a different connection string or even change the name, but it needs to be defined with the same name in all environments.
   
   
2. With the Visual Studio 2013 Update 4 it is possible to change the database in the Settings separator but in this case it will be ignored!

For more information about the transform file, read the following article: How to Transform Web.config When Deploying a Web Application Project.

Conclusion

In conclusion, creating multiple environments for a .Net Backend Azure Mobile Service is an easy task that is a plus in the development that allows testing new features before going into production and it allows being sure the tests done in the localhost will continue to work in the Azure Mobile Service without affecting the production environment.