Make your Azure preproduction environment a useful reality

azure, webdev, devops, deployment, test, vsts

By Cyprien ,

A few months ago, Adrien wrote about a good way to deploy your web apps to Azure. If you haven't already, this is definitely worth reading. The thing is, he did hide a part of the truth from you ! Naughty monkey !

In our standard process we have various environments where we deploy versions of the software we build depending on their maturity. We have integration (bleeding edge), validation (releases and hotfixes), preproduction (stable software) and production. We will write more in depth about that next month so stay tuned !

We deploy our environment using the process we described earlier on this blog except for the preproduction where we are doing a bit more stuff. In this article we will explain why and how we do that.

What is a pre-production environment

A pre-roduction environment is supposed to be as identical to the production environment as possible. These are the main reasons to do so :

  • test migration scripts (mostly database schema update and data migration)
  • identify configuration issues
  • run tests on real data.

Why do you need that ?

Because fixing a bug in production is always painful, costly and can make you loose a lot of money or worse...

Fix a bug in production

Ok now I'm scared how I do that ?

In this article, we will propose an approach which should work conveniently for project with reasonable amount of production data. If you have to deal with larger amounts of data, you'll probably need to adapt this a little to implement data sampling or leverage read-only access to large data stores.

I our usual azure LOB web apps we often have the following things :

  • An SQL Azure Db
  • A blob storage account
  • An Azure web app

In order to get an identical preproduction environment we need to achieve the following.

  • Copy blob storage data (we will prefer incremental copy there)
  • Restore a recent production backup to a preproduction database.
  • Create a user login to give an existing user with appropriate rights to the restored database
  • Deploy our web Application.

With Team Services Relase Management and our Azure extension this can be achieved with just a few tasks.

Preproduction Build Steps screenshot

Step 1 : Copy Blob Storage Data

For that matter we will use an extremely convenient tool : AzCopy.
Copy Azure storage container screenshot

  • Tool : Path to azcopy. If you installed Azure Storage Tools azcopy it will be located at C:\ProgramFiles(x86)\Microsoft SDKs\Azure\AzCopy\azcopy.exe but if you have installed the latest build agent, it will bundled on windows in $(Agent.HomeDirectory)\externals\azcopy\azcopy.exe

  • Arguments : Azcopy operation argument. We will copy a container from storage account A to storage account B using the following arguments : /source:$(ProdStorage) /sourceKey:$(ProdStorageKey) /dest:$(PreStorage) /destKey:$(PreStorageKey) /XO /S /Y where /source will be set to the source container url, /sourceKey to the storage account key (you can use a SAS token with /sourceSAS), /S makes the copy operation recursiv, /XO avoids copying files previously copied and /Y removes all confirmation prompts.

We are also working on a AzCopy Build Task to make this even more easier. We will update this post as soon as this becomes available !

Step 2 : Restore SQL Database

For that matter we will leverage SQL Azure point in time restore and the Restore Database task provided by our extension :

Restore Database Task screenshot

  • Azure Rm Subscription : Select an previously configured Azure RM endpoint.
  • Azure SQL Server Name : Set this to the value of your SQL Server instance instance
  • Source Database Name : Set this to the name of the database to be restored
  • Target Database Name : Set this to the name of the target database

Step 3 : Create the user

For that matter we will use Execute SQL Query task provided by our extension :

  • Azure Rm Subscription : Select an previously configured Azure RM endpoint.
  • Type : Selected Predefined script
  • Predefined Script : pick Create Database Owner
  • Variables : Use Login=NameOfThePreexistingUser to create a login for user NameOfThePreexistingUser
  • Azure SQL Server Name : Set this to the value of your SQL Server instance instance
  • Database Name : Set this to the name of the restore database
  • Server Admin Login : Provide the SQL Server Admin login name
  • Password : Provide the admin SQL Server Admin password
  • Firewall : Default settings should work just fine

Final Step : Use you usual Deployment logic

Once done, you should use the same deployment logic as you would with the production environment. For that matter, the brand new Team Services Tasks Group are extremely handy to avoid duplicated work.

Final thoughts

Now you have an preproduction environment deployed with the same logic as the production you should test it :

  • Verify that it has been successfully deployed
  • Perform manual testing
  • And we strongly recommand to write few automated tests around key features with tools like selenium.

Thanks for reading and don't forget we would be very happy to hear your feedback or suggestions.