2

I am finally jumping into the Azure development party, and I have a question in regards to the preferred practice in creating my development and deployed environments.

To start with, I am learning Azure Key Vault and it has presented the perfect example scenario of my core question.

In my development (and ALM) process, I usually have:

  • Local development environment
  • Deployed development environment (CI/CD)
  • Testing Environment
  • Staging
  • Production

For each environment, I usually have an App.config or Web.config with XDT environment transforms that run for each environment and place in environment settings for each of the environments for the external resources that my application uses.

Now, I did see this question, but it is a few years old, so I wanted to revisit it as there seems to have been a lot of work done in particular with the new Azure Resource Manager and the Azure Management API that seems to have replaced Azure Service Management model.

In the case of Azure Key Vault, I am thinking of creating 4 Resource Groups (Development, Testing, Staging, Production) and create an Azure Key Vault instance within each of those groups.

My questions are:

  1. Is this a correct way of looking at Azure Resource Groups?
  2. From my local development environment, should I connect to resources stored in the Development Azure Resource Group that I create, or is there another preferred mechanism for developing locally? (For instance, are there other emulators like the Azure Storage Emulator that I should consider using?)
  3. Is there a more preferred approach to handling my environments than what I have presented?

Thank you in advance for any assistance and clarification!

Community
  • 1
  • 1
Mike-E
  • 2,477
  • 3
  • 22
  • 34

1 Answers1

0

IMHO (..and I can't pretend I'm an expert),

  1. Yes, a resource group per environment sounds reasonable. However, you might want to consider separate subscriptions too (or a separate one just for production) because there are things like AAD (which I assume you're using for Key Vault) that are outside the scope of a resource group. You probably don't want your dev app to accidentally access the production key vault..
  2. That really depends on what you're building but if there is no real need to separate between local and cloud dev environments, then I'd say just have 1 environment.
  3. See above :)
charisk
  • 3,190
  • 2
  • 24
  • 18
  • 1
    Thank you for your answer, @charisk. In reference to #2, I was actually thinking about the [Azure Storage Emulator](https://azure.microsoft.com/en-us/documentation/articles/storage-use-emulator/) and if there are other resources like this to consider. I have updated my question with this. To me it seems inefficient/counterproductive/inconsistent to provide local development resources like this for some features, but not others, so I want to make sure here. – Mike-E Feb 23 '16 at 12:14
  • Ah, sorry mean to say something around that - I think there are some solutions out there for certain technologies but you'll struggle to find something that can do everything you want. It would be like emulating all possible Azure solutions on your local box :) you'd have to look at it on a case by case basis. – charisk Feb 23 '16 at 12:32
  • Alright, it looks like you are the expert by default here @charisk. :) Thank you for your help! – Mike-E Feb 24 '16 at 23:43