Azure developers often stumble and find it difficult and cumbersome to test their applications. They consider Azure staging environment the equivalent of a test environment, which it is not. A staging area is just a temporary application holding area, ideally an exact replica of production, before it is deployed in the production environment. Staging helps you view how the application will look like and save substantial time, caused from deploying to production directly. But it’s not a QA / Testing environment.
Testing and tuning of an application is ideally done in a separate test environment. The best way to do this is to open up a new service for Testing environment with its own Production and Staging. In this case, you will want to maintain multiple configuration file sets, one set per deployment environment (Production, Testing, etc.)
There are many ways to manage configuration complexities that occurs, especially with Azure that has on top of .config files, its own *.cscfg files. The best way to do it with Azure project is as follows:
- Setup a small Config project, create folders there that match Deployment types.
- Inside each folder setup sets of *.config & *.cscfg files that match to particular deployment environment: Debug, Test, Release… these are setup in Visual Studio as well , as build target types.
- Use a xcopy command that occurs during every compile of the Config project that copies all the files from Build Target folder of Config project into root folder of the Config project.
- Now every other project in the solution links to the .config or .cscfg file from the root folder of the Config project.
This configuration will adapt to every build configuration automatically. Also use .config transformations to manage debugging information for Release vs. non-Release build targets.
Find Out how Netreo delivers value and automates common and frequent Azure Monitoring and Automation tasks. Request a Demo Today!