Need Alexa to work for multiple developers? Here’s my experience

Just To Preface This:

The views and opinions reflected here are entirely my own and don’t reflect my employers at Accenture The Dock.

Working With 1 Developer vs N Developers

So, Alexa really isn’t built for more than one developer working on a single skill at a time. On one hand, I can somewhat understand why they haven’t built the SDK for this as most skills are quite small in nature. But, as we’ve seen a rise in the uptake of using voice assistants, we’ll also see a rise in the need for more complex skills, meaning a need for more than one developer working on them at a time. Let’s look at the differences in setting up development environments for each.

Important Links:

• https://developer.amazon.com/alexa/console/ask
• This acts as the hub for creating and managing parts of your skill. It contains our interaction model, which is like the frontend of the skill, which is used to define what user requests we send to our handlers.
• https://aws.amazon.com/
• AWS Lambda is used to host & access the handlers of the skill. Handlers are like the backend of the skill, where we can define how Alexa will handle the incoming information and respond to the user.

1 Developer:

This can actually be broken down into two separate sections:

• Alexa-Hosted
• Provision your own.

Alexa-Hosted:

This means that Amazon will automatically create a Lambda function for you, host it on their free tier, and provides a basic in-browser code editor. Here’s the pros and cons of such a set-up:

Pros:

• Easy to set up
• Easy to deploy
• Great for small skills
• Great start for learning how the Alexa SDK works

Cons:

• Can only code in the browser code editor
• Can’t git-version your code, it’s managed entirely by them
• Limited to deploying to a single skill (this means your development, testing, and production environments are the one thing)

Provision Your Own:

This means that the user will provide an AWS Lambda function for the skill to connect into. The Lambda function controls all the handlers in your skill (think of them as the logic, and intents act as a method invoker that can pass in parameters). I’ll go into how to set-up an AWS Lambda function for Alexa soon.

Pros:

• Allows you to host your code on your own git repositories,
• Allows editing in your preferred code editor with all of its plugins,
• It can be integrated with automation services (e.g. Jenkins or Azure DevOps) to be deployed to multiple environments, i.e. having separate skills for development, testing, and production.

Cons:

• Increase in the complexity of setting it up

N Developers:

This is where the real issues with how Amazon expects developers to use Alexa come into play. With more than two developers working on a skill, it can really be difficult to figure out how it can be done. I’ll go through some approaches we took and the advantages and disadvantages each provides.

Alexa-Hosted & ASK

https://developer.amazon.com/en-US/docs/alexa/smapi/quick-start-alexa-skills-kit-command-line-interface.html

ASK is an Alexa Command Line Interface for your computer, allowing you to clone your skills to your local machine, code from your favorite code editor, and deploy them from the command line. The basic file structure looks like this:

/.ask #contains config file
/hooks
/lambda #contains handlers
/models #contains interaction models in their various languages
skill.json

This seems great, doesn’t it? We can have our interaction models (/models) hosted locally too, we can have the entire Skill hosted locally and deploy from it. You thought wrong (and I did too). Here’s why:

• One Environment: When you deploy through the CLI, it can only deploy to one skill with the associated Lambda function. This means that you can kiss goodbye to the dreams of development, testing, and production environments.
• Merge Conflicts: the .ask file constantly changes as you work on it, so when you try to merge while multiple people are working on features, the config file is constantly going to have issues.

“But wait, can’t we just host it on our own repositories and use an automation service to push to our own Lambda functions and skills and therefore have multiple environments” I hear you say. Nope:

• Interaction Models: Alexa doesn’t host these via a Lambda function, so your automated deployment means you won’t be able to send your newly updated interaction model up to Alexa. Putting it inside the Lambda function will just make your function more bloated, meaning that it’ll be slower than if it just contained all your handlers. The only way to push the interaction model up is to deploy via ASK, which means your lambda will get pushed to the single environment too. Which isn’t ideal.

The not-ideal, but the best solution:

• Interaction Model: Hosted on Amazon Developer Console (it has basic in-built version control, allowing you to revert to previous versions).
• Handlers: This is hosted on AWS Lambda.
• Multiple Environments: These are two separate skills we have on the developer dashboard, a developer playground & a production environment.

How was this achieved?

• Azure DevOps: This is acting as our code repository, so all of our Lambda code is hosted there. This allows us to use git to work on separate branches and work on features without affecting each other’s work. Azure DevOps also allows automation, so each time a branch was merged with master it triggered a build and release to the Lambda for the developer environment. If the master was merged with a production branch we created, it would trigger a build and release to a separate Lambda for the production environment.
• The Drawback: So, not everything can be neatly managed by automation. While the interaction model has version control, it also can’t be set up in such a way to deploy to various environments. Each time our team deploys to the production branch, we have to go into the interaction model on the development environment and paste the JSON into the production environment. It’s infuriating that there isn’t a neater way of doing it (and I have some ideas on how to automate it but I haven’t been able to test it out yet).