Azure Mobile Services: How to Create a Dev and Prod Environment
This article has the goal to show how to create a development and production environment for a .Net Backend from Azure Mobile Services.
IntroductionFrom 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.
Azure Mobile Services is great for mobile application development with client libraries for both Apple and Microsoft mobile platforms.
There are various scenarios where one requires multiple environments for an Azure Mobile Service.
These include:
- Breaking changes between published versions of an app.
- Different configurations for test and production.
Different environments are necessary in order to have different configurations for a given Azure Mobile Service. Azure Mobile Services allows testing in localhost, but do not provide a way to have different environments.
DescriptionTo create a development and production environment for a .Net Backend – Azure Mobile Services is required to create a Dev and Prod Backend and then is possible to create the Dev and Prod profiles based on transform files.
Let’s see it in more detail.
Creating the Azure Mobile ServicesIn Azure Portal, create two .Net Backend – Azure Mobile Service, let’s call it as following
- 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

Is possible to use the same database, but it is necessary to use different schemas and if different databases are provided is easier to manage each environment (update or even delete). A Backend that uses Entity Framework migrations will recreate the service from the scraps and with it any time it can be deleted, deployed and recreated.
To read more about the steps required to create an Azure Mobile Service, read the following article
How to create the MyMenuApp Azure Mobile Service .
Creating a Transform FileIn Visual Studio, select the solution and open the context menu as following

After it, click in Configuration Manager as following

And then create a new configuration as following


In this case, a Dev configuration is defined based on Debug configuration and to the Prod configuration should be used the Release configuration as following

At this moment, is possible to define Debug, Dev, Prod and Release configuration

For each configuration is possible to define the conditional compilation. For example, in Dev is possible to have

In reality, it means, we can do
#if Dev
// for example can fill the database with fake data
#else
// in another environment different from Dev
#endif
To have advantages of this configuration using the Web.Config, let’s add the config transform as following

Which the result will be

Now 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 Dev environment (or even the localhost!)
<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 Prod 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 configs will be used.
Let’s publish the service to the Azure.
Select the project and using the context menu click in Publish, as following

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

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

And then publish it!
Do the same process to Prod, as following

And then publish it!
Is possible to see the Web Publish Activity that shows the publish process


At this moment, both environments are deployed and running and are not required to define or change each environment in the future, only is needed to have attended each one is set before deploy.
Notes
- In this case, was using the MS_TableConnectionString1 name for defining the connection string and the default value MS_TableConnectionString, defined in Azure Portal, will be ignored.
- With the Visual Studio 2013 – update 4 is possible to change the database in 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
ConclusionIn conclusion, creating different environments for a .Net Backend – Azure Mobile Service is an easy task that is a plus in the development, which allow testing new features before it goes to production and it allows to make sure the tests done in localhost will keep working in the Azure Mobile Service without to affect the production environment.