Using the Alexa Skills Kit Command Line Interface with Alexa-Hosted Skills
Lately I’ve been using the Alexa-hosted option for many of the Alexa skills I’ve created. It’s a convenient skill-building option since I don’t have to switch between the Alexa developer console and the AWS Lambda Console. Prior to that, my favorite option was to use the Alexa Skills Kit (ASK) Command Line Interface (CLI) with Visual Studio Code. I was thrilled to learn that I can now use the ASK CLI with skills that are Alexa-hosted skills. You can even create new Alexa-hosted skills from the ASK CLI using the “ask create-hosted-skill” command.
Evolution of the ASK Toolset
When the Alexa Skills Kit was first introduced, developers used the developer console to manage their skill and the AWS console to manage code running in AWS Lambda. This was the toolset I used to build my first skill, and like so many others, I was hooked on building skills.
We created the ASK CLI to enable developers to manage both the skill and the code from the same tool. The CLI didn’t require interacting with a web interface. I really liked this because it was easy to keep all the parts of my skill together, and it didn’t require copy/paste to deploy my skill configuration and interaction model. It was also easy to deploy my Lambda function code.
In addition to using the ASK CLI on your local development machine, you could also now use the ASK CLI on AWS Cloud9. This means you could set up different environments for each skill. Or if you were doing work with multiple companies or with multiple accounts, you could keep the environments separate. I also liked that I could spin up a new environment in less than five minutes, complete with the ASK CLI. This allowed me access to all the features of Cloud9, including sharing the environment with my team, and integration with Lambda.
Fast-forward to late last year when we announced Alexa-hosted skills. While this option still used AWS Lambda as the compute platform, now you didn’t have to create an AWS account to host your skill. In addition, you didn’t have to switch between the Alexa developer console and AWS Console to copy/paste the ARN into the endpoint field and copy/paste the Skill ID into the skill verification trigger. That was handled automatically! Couple this with ability to create and manage your in-skill products from the developer console, and you have a powerful skill-building package.
This convenience wasn’t the only difference. Behind the scenes, your skill code was being stored not in a simple database, but in AWS CodeCommit. This difference doesn’t require developers to use a new tool – you manage your code from within the developer console, including saving, deploying, and pushing to your live skill.
How Alexa-Hosted Skill Code Flows Through AWS CodeCommit to AWS Lambda
AWS CodeCommit is a fully managed source control service that hosts secure Git-based repositories. If you’re familiar with Git, you know your code is organized into branches. Typically, you’ll have a working branch and a branch that reflects the code you have running in your live service.
With Alexa-hosted skills, the code is organized into three branches in each skill repository: dev, master, and prod. The dev branch is where your code is stored when you click the Save button in the console. When you click the Deploy button, the code stored on the dev branch is merged into the master branch. This code is combined with the dependencies noted in your package.json, and then deployed to your Lambda function. This version deployed from the master branch is used for your skill’s development endpoint and is the code which is run when you test your skill in the simulator.
When you promote your code to Live, the code from the master branch is merged into the prod branch. From there it is deployed to your Lambda function. To keep the development and prod versions of the code running separately, each is deployed to as separate versions of the same function, with Lambda aliases pointing to the correct version.
Although I liked the convenience of the one-stop approach offered by the developer console, I still also liked doing things from a command line since it allowed me to use my preferred code editor. Now that you can interact with your Alexa-hosted skills using the ASK CLI, I’m excited to start using the ASK CLI more.
At a high level, using the ASK CLI is the same with an Alexa-hosted skill as with one where you host the Lambda function in your own account. To get a local copy of your skill, you use the “ask clone” command, and to deploy your skill, you use the “ask deploy” command. (Remember to create an Alexa-hosted skill using the ASK CLI, use the “ask create-hosted-skill” command instead of “ask new”.)
When you get into the details, there are a few differences that you should be aware of. First, when you setup the CLI, you don’t need to provide AWS account credentials. All of the deployment actions are taken using your developer account credentials. The second difference is that the local copy of the code is cloned using Git from CodeCommit, and all three branches (dev, master and prod) are cloned.
Your normal working branch is the dev branch, just like if you were using the console. You also will work with the branch like any standard git branch, using “git add” to add new files and “git commit” to commit your changes. If you want to make your changes just visible in the developer console, you can do a “git push” of the dev branch.
When it comes time to deploy the changes you made, you can use the same ‘ask deploy’ command (or ‘ask deploy –target lambda’ to just update the skill code). When you do this, your local dev branch is merged to master, and local changes are pushed to the origin (or remote repo). That push triggers the deployment to the Lambda function.
If you want to use standard git commands to deploy your changes to your development endpoint, you can merge and push your changes to the master branch. Similarly, you can merge and push your changes to the prod branch to deploy your changes to your live skill. Keep in mind that making changes like this will only impact your skill’s code, not your skill’s interaction model, in-skill products, or skill configuration. The non-code changes need to be deployed normally using the “ask deploy” command in order to change your development version of your skill. In order to change the live version of your skill, you will submit it for certification just like normal.
I find that I no longer have a favorite skill-building approach and will bounce between hosted and non-hosted, CLI and GUI depending on the task at hand. Regardless of which type of tool you prefer, you’ll find a hosting method and both GUI and CLI options for building your skill. Tweet me at @FranklinLobb to let me know which is your favorite!