Blither, Blather, Web Content Management.
Blog » Alexa on Azure: Part 5 - Staging Environment

Alexa on Azure: Part 5 - Staging Environment

If you’ve got an Alexa Skill running eventually you’ll create an updated version. CowboyYou’ll probably want to test it out before it hits production right? I’m traditionally an enterprise developer, so I try to avoid this guy.

Potentially, in the future, Azure Functions will support deployment slots like web apps. It certainly seems like the direction to go, but for now we’ll need to work around it by creating a second environment.

The second half of my article, Alexa on Azure: Part 1- Creating the Function, explains how to create your Function App on Azure. Run through that portion of the instructions again and create a new instance of all the resources.

If your production resources are:

  • IntranogginAlexaRG
  • IntranogginAlexaApp
  • intranogginalexastorage

You’ll end up with another environment like:

  • IntranogginAlexaDevRG
  • IntranogginAlexaDevApp
  • intranogginalexadevstor *I had to truncate this one to fit in the length limitations.

If you wanted an additional staging environment, you could repeat that with a different (Stg) suffix. Once you’ve gotten the duplicate environment created, continue the instructions in that article for publishing your function code to the new environment from Visual Studio.

Note: If you’ve already setup VS to web deploy to your production environment, you’ll need to jump back to the Profile tab and use the Microsoft Azure App Service button to create the profile for your dev environment.

New Profile

Once you’ve published your function code to the dev environment, we’ll need to register new development Alexa Skills that use the development functions. My blog article, Alexa on Azure: Part 2 – Registering Your Function, covers the detailed instructions. The only alteration here is that you’ll need to give it a name and an invocation name that indicates it is not your production instance. In my case I used name = DevTeenageDaughter and Invocation Name = Dev Daughter.

Skill Name


That’s it. It’s not a perfect solution. Ideally I’d be able to have an Alexa enabled device with a dev skill using the same invocation name as the prod instance, but routing to my dev service. It may even be possible using multiple accounts, but that’s overkill for my needs at this point.

Posted: 3/6/2017 10:18:00 AM by Ryan Miller | with 0 comments