How to use versioning with AWS Lambda and Alexa Skills Kit (ASK), a step by step guide

Submitted by dannix on Fri, 04/05/2019 - 14:15

I learned a valuable lesson on the morning after submitting my latest Alexa skill for certification. I had an email from the Alexa certification team letting me know that their tests had failed. I thought that was odd because everything was working perfectly fine when I left work the previous day. I was using AWS Lambda to host the back-end code (within a Node.js environment) and hadn't set up the versioning system because I didn't know about it. [update: I'm now using the AWS CLI to locally host my code and push it to Lambda, which is what I recommend. It also makes it possible to add custom Node modules to your project].

This was my screen:

AWS lambda could not find index.js missing from file system

It said "Error opening file: could not open file: /index.js, The file could not be found on the file system."

That's just great because I had no recent local backups, no cloud backups, had not used the built-in versioning system in Lambda, and had done nothing else that could have saved my bacon. Apparently there was a problem with Lambda's built-in code editor and the Chrome browser. But no one really knows why or what happened. My code simply got "lost" in the cloud.

I really had no excuse for not using a versioning system. Being lazy wasn't even a good excuse because it's so easy to set up. With free private Github repos these days there is no excuse not to spin one up quick, and even for projects that might be throwaway. The effort is trivial and the payout is invaluable, as I now know all too well.

Here's the steps I took to setup the versioning system with Lambda and how it works with the Alexa Skills Kit. 

  1. I had an old backup, thankfully, that had most of my code, but not all. I created a new file, index.js, to replace the lost one and copied the code in there.
  2. Next I published a new version, version 1. The link to do this is found under the "Actions" drop down menu in the top right corner of the Lambda console. Version 1 will now be a stable release that will be used for production. The $LATEST version is a special version in Lambda and the only one you can edit, so it will be the development version.
  3. Now I needed to make some Aliases that point to these version. I made an alias called "LIVE" and pointed it at version 1. I also added an Alexa Skills Kit trigger and entered in the ID for my Alexa Skill. 
  4. Then I made another alias, named it "DEV" and pointed it at the $LATEST version, and again I added a trigger for my Alexa skill.
  5. Next, I switched to the Alexa Skills Kit console to change the endpoints to go to those specific aliases for my Lambda function. Here's where things get a little funny:
    1.  Amazon doesn't allow me to edit the live version of the skill in the ASK, including changing the endpoint for the Lambda function. It still points to the correct Lambda function but without any alias or version number appended to the end. I can only assume that it uses the $LATEST version as the default, which is not great but nothing I can do about that at the moment.
    2. For the development version of the skill, I was able to change the endpoint to be arn:aws:lambda:us-east-1:******:function:playAudioReader:DEV
    3. I'll have to develop the new intents on this DEV version, which is actually the production version for the time being because I cannot change the skill that is in production to use the LIVE version as the endpoint. This isn't any different than doing development on a production server, but my hands are tied and I have no other choice.
    4. [Update: There is an obvious solution to this problem! Just start a new function in lambda!]
  6. Once I've finished implementing the new skill's intents and before I submit it for certification, I'll save a new version (version 2), and tell the LIVE alias to point to that version. Then within ASK, tell the development version of the skill to point from the DEV alias to the LIVE alias, which will be identical to the $LATEST version. I need to do this before certification of the skill because after that happens I won't be able to edit the lambda function endpoint.  
  7. In the future, I'll be able to have the dev version of the skill point to the DEV alias of the Lambda function, while the production version of the skill still points to the LIVE alias. But I'll still need to remember to do step 6 if I ever need to submit the dev skill for certification again!

You got all that? Not quite as easy as spinning up a new Github repo but it certainly beats having all your code get "lost" in the cloud. However, after all I've been through today, I think I'll save more local backups. 

To make changes to the Lambda code, i.e. simple bug fixes or changes to JSON data, but not adding new Alexa intents or anything that would require submitting to Amazon for certification:

  1. Make the changes to the $LATEST version and save.
  2. Test the changes by using the testing feature in Lambda. 
  3. Test the changes on your Echo device that is owned by the same Amazon account and your developer account. It *should* play the development skill and not the live skill.
  4. Publish a new version from the Actions dropdown
  5. Navigate to the LIVE alias
  6. Edit the Alias configuration to use the new version you just created. 
  7. Test again on another Echo device that is not owned by your Amazon developer account. I use my wife's Echo. 

Hope this helps!

[Update on 12/11/2020: All of this info is still relevant and correct, and the Alexa developer console and Lambda haven't changed such that the info in this article is outdated or wrong.]