November 2, 2016

Parallel development for Alexa (ASK) developers – Part 1

Written by

Odecee expert Pim Amponpun shares some learnings for developers working with Amazon’s Alexa Skills Kit …

avs_med_3-22

Recently, the team at Odecee used Alexa as a voice interface for customers in an application developed as part of an internal project. During the development, we experienced some challenges integrating codes from multiple developers and implementing rapid deployment.

This post aims to provide some guidelines for Alexa developers or DevOps engineers in planning and developing their Alexa skills using Alexa Skills Kit (ASK) based on our recent learnings. It focuses on a larger scale development, which requires continuous integration and deployment.

Background

Alexa is a cloud-based voice service (powered by Amazon), that provides capabilities or skills that enable customers to interact with devices such as Amazon Echo using voice. The user can ask Alexa to provide information, play the music or set the alarm and so on. Apart from those capabilities or skills that built-in with Alexa, Amazon also provides us the ability to create our own voice–driven skills using ASK.

For the application the Odecee team built using Alexa, we used the following tools:

  • AWS to host our application infrastructure.
  • DynamoDB for the persistent data and Lambda for computation.
  • Due to our large data sets, Cloudsearch was deployed to speed up our search function.
  • AWS pipeline and EMR were also used for facilitate importing large data across to DynamoDB.
  • S3 was used for logs and temporary data store.
  • The pipeline was setup to automate those functions using Bamboo and BitBucket.

This post focuses on Section A in Figure 1 below, which is the pipeline for Alexa developers. As shown in the diagram, we used Lambda for hosting our Alexa skill Node.js code calling by Alexa service. Developers can push their code directly to Lambda or via automated pipeline with Git and Bamboo (details in the next section). Developers can use Amazon Echo or simulator to perform their testing with Lambda code.

figure-1-copy

Fig 1: Pipeline for Alexa developers

 

Problems we encountered

During the ASK development, we experienced multiple issues:

  • The current Alexa (ASK) pipeline does not support multiple developers or parallel development. The existing pipeline for developing Alexa skills mainly focuses on individual developers using their own Amazon developer account to create a skill set and upload their code to Lambda. This pipeline is efficient with a small project that has one or two developers, however with larger projects that have multiple developers, the current pipeline is problematic for integrating and testing multiple features including code versioning.
  • The continuous integration (CI) pipeline adds a significant overhead in testing in the development environment. While the CI pipeline helps with integration, it hinders rapid development especially when it comes to situations for which the local testing platform is not sufficient. Generally, developers test their code locally prior to committing to the Git repository to build, test and deploy through the CI server (i.e. Bamboo). However, when local testing tools are not sufficient (subject to application type and characteristic), their code is required to be uploaded to Lambda and must be accessible by Alexa-enabled devices (or simulators) for testing. As developers use Bamboo to deploy their code, waiting for Bamboo tasks to complete each time they want to test code add a massive overhead in development.
  • Management of multiple Amazon developer accounts is problematic. Alexa skills need to be published for the developers or customers to access those skills from their Alexa-enabled device (such as Amazon Echo). To test Alexa skills with the device without publishing skills to public, the device must be registered to the same e-mail address used to sign up for a developer account on the Amazon Developer Portal. Using multiple Amazon developer accounts increases an overhead in management and adds difficulty in integration testing.

 

Our solutions

The Odecee team developed solutions to enable parallel development in Alexa ASK pipeline. The solutions detailed below have the potential to provide significant value to businesses by facilitating rapid and large scale Alexa custom skill development.

Single developers or small projects

For small projects, developers can configure new skills through Amazon Developer Portal (see Figure 2). They can upload or deploy their code directly to Lambda via AWS CLI, SDK or any tools of choice. Developers also can push their code through Git repositories and use a Bamboo plan to deploy their code in Lambda. They can set up their testing locally or through an Alexa-enabled device or simulator.

Figure 2: Pipeline for small projects

Fig 2: Pipeline for small projects

 

Option 1 – Multiple developers for larger projects

To implement continuous integration and continuous deployment for Alexa developers, we introduce Git repositories, Bamboo’s branching feature, multiple skills per Amazon account, Lambda versioning and alias to the pipeline.

This option is suitable for multiple developers or larger teams for whom local testing tools are sufficient.

Fig 3: Pipeline for larger projects in Option 1

 

a Git repositories and feature branching with Bamboo allow developers to have their own development branch and Bamboo plan. Developers can continue working on their branch after merging their code into the main branch, while other developers perform code reviews, integration testing and releases. Building feature branches with Bamboo fo for more details.

b Lambda versioning and aliases. A combination of versioning and aliases provide us the ability to create different workflow for each environment (i.e. production, integration, development etc). The alias also enables a quick rollback in the production environment. See AWS Lambda for more details.

c Multiple skills per Amazon developer account resolves the issue with managing multiple accounts with different credentials and enables integration testing. With an Amazon developer account per developer, when a developer wants to test another developer’s code, they have to login using the developer’s Amazon credentials to perform the test, which is inconvenient and time-consuming. Sharing the same Amazon developer account helps resolving the issue. The developers’ codes can be differentiated by using different invocation names for skills.

Each Alexa skill is mapped to a Lambda aliases. As shown below, we can map multiple skills to one Lambda function using multiple aliases, i.e. integration, dev1 and dev2 aliases. This enables end-to-end workflow from Git branch to Alexa skills for an individual branch.

Figure 4 below presents the solution in more detail. We use two main branches, master and integration. Feature or development branches off from integration. Those branches are mapped to Lambda functions, and those Lambda functions and aliases are mapped from Alexa skills.

As you can see in diagram d below, the first Lambda function is shared between integration, dev1 and dev2 by using Lambda aliases and versioning. The second Lambda is dedicated for production.

Sharing the same Lambda function for multiple branches reduces the overhead of managing multiple Lambda functions.

fig4

Fig 4: Pipeline for Option 1 in detail

 

Diagrams  eand f show how those Git branches are mapped to Lambda aliases and how we use Bamboo for continuous Integration. As shown above, Integration is branching off Master. Development such as dev1 and dev2 are branching off Integration. When the developers push their code in, the Bamboo job kicks off, uploads their code to Lambda and publishes a new version of Lambda. The Lambda alias repoints to a newer version. When another developer pushes their code in, the same process occurs, however only their branch alias is moved to a newer version. This allows developers to work in parallel. As shown above, dev1 is on version 11, while dev2 is on version 9 of the same Lambda function. Their code will be completely isolated until they merge their branch into integration.

The integration branch will be merged into the master branch after the integration testing. The Bamboo tasks will upload the code from the integration branch to production and create a new Lambda version or release. The prod alias will be repointed to a newer version. Rollback in production is done simply by changing the alias back to the previous version.

Figure 5 below shows the data flow when creating a new branch.

fig5

Fig 5: General workflow for Option 1

 

The general workflow for developers when creating a new branch:

  1. Create a new branch by cloning from Integration.
  2. Create a new Alexa skill on the Amazon developer portal. Make sure the skill name and invocation name is associated with the branch name (see example as below).
  3. Create a new Lambda alias.
  4. Create a Bamboo branch from the Integration Bamboo plan.
table

As above, integration, dev1 and dev2 are using the same Lambda function “AlexaTest” with the aliases associated with their branches. The same applies for invocation name and skill name.

Pros and cons of Option 1

Option 1 allows for code versioning and backup, automated integration and production release, and Lambda versioning and quick rollback for all branches. It means reduced overheads in account management and in managing Lambda functions.

At the same time, this approach may result in increased overheads in development when local testing tools are not sufficient.

Check out the second installment of this post detailing Options 2 and 3 for large-scale development…

Tags: , , , , , , , ,

Categorised in: Innovation, Technology

This post was written by Pim Amponpun