November 18, 2016

Parallel development for Alexa (ASK) developers – Part 2

Written by

In part 1 of this blog, Pim Amponpun looked at the challenges encountered when using Amazon’s Alexa within large development projects and presented a possible solution for teams using local testing tools. Here she looks at some further options for larger teams.

 

Option 2 – Rapid testing in development for large projects

This option is suitable for multiple developers within larger teams for whom local testing tools are NOT sufficient. Option 1 allows the developers to deploy their code to Lambda through Bamboo whenever they push code to their branch. However, when local testing is not sufficient, this approach seems to slow down software development.

So, Option 2 is introduced to allow developers to push their code directly to Lambda in the development branch, and push their code to the Git repository when they are ready for code review or backup. The code will be later merged into Integration after peer review approval.

Figure 6 shows the overview of option 2, which is similar to option 1 except without Bamboo feature branching and Lambda versioning from development branches. In order to allow developers to deploy directly to Lambda while maintaining parallel development, individual Lambda functions will be required for each branch.

Figure 6: Option 2 - big picture

Figure 6: Option 2 – big picture

 

aFeature branching with a Bamboo plan has been removed. So, there will be no Lambda versioning in development or the feature branch. For Integration and Production, versioning and quick rollback remain the same.

bDevelopers can deploy their code to Lambda directly via AWS CLI, SDK or any tools of choice to speed up their testing. They also have an option to push their code to Git repository as often as they want to make sure the code has been backed up.; however, the Bamboo plan will be kicked off only when they merge their branch with Integration. To ensure the isolation of branch workflow, IAM policy will be set up so the developer can only push their code to the Lambda function associated with their branch.

cEach branch will require its own Lambda function. Aliases of feature/development branches will always point to the LATEST version, allowing developers to test their code through Alexa-enabled devices straight away after deploying them.

NB: the increased number of Lambda functions doesn’t increase the cost as Lambda’s charge only applies to the compute time for running the function.

Figure 7 below shows Option 2 in more detail:

Figure 7: Option 2 - deep dive

Figure 7: Option 2 – deep dive

 
d shows Lambda function per branch.

e & f are similar to Option 1, except there is no Lambda versioning in development/feature branches.

Figure 8 presents Option 2 from environment perspective.

NB: The Bamboo branch is not required for this option.

fig8

Figure 8: Option 2 – environment view

 

Figure 9 shows the workflow for creating a new branch in Option 2:

  1. Create a new branch by cloning from the Integration Branch.
  2. Create a new Alexa skill from the Amazon developer portal. Make sure the skill name and invocation name is associated with the branch (see example in Option 1).
  3. Create a new Lambda function and Lambda alias.
Figure 9: Option 2 - environment view

Figure 9: Option 2 – environment view

 
Figure 10 shows the end-to-end workflow for developing custom skills using ASK:

  1. From the development/feature branch, push a code to Lambda for testing using AWS CLI or SDK.
  2. After testing is completed, push the code to Git for code review.
  3. After peer review approval, merge the code into Integration.
  4. The Bamboo plan is kicked off automatically, performing the tasks as shown below.
  5. A new Lambda version is created in the Integration branch.
  6. Perform integration Testing.
  7. After the testing is completed, merge the code into the Master branch.
  8. After approval, the Bamboo plan is kicked off, peforming the tasks as shown below.
  9. A Lambda version of Production is created as a new release.

Roll back step

  1. Modify PROD alias to point to a previous working version.
Figure 10 : Option 2 - workflow for development

Figure 10 : Option 2 – workflow for development

 

Option 3: Hybrid of Option 1 & 2

Option 3 brings together the benefits of Options 1 and 2, providing continuous integration and continuous deployment with full Lambda versioning on all branches and rapid testing in development. The drawback would be the overhead of managing multiple Lambda functions and the complexity of adding more Lambda aliases. As shown in Figure 12 below:

awe re-introduce feature branching of the Bamboo plan to allow Lambda versioning on all branches.

bThe developer can deploy their code through the automated pipeline or push the code directly to Lambda.

cWe configure two aliases for each developer/feature branch. The first alias is for rapid testing and the second alias is for versioning.

For example in dev1 branch, the Alexa skill will point to dev1test alias, which refers to LATEST version of Lambda. So, when developers push their code directly to Lambda, they can test their code straight away. The other alias dev1 is for versioning. When the developers push their code through automated pipeline, the Bamboo kicks off to deploy the code to Lambda, publish a new version and move dev1 alias to that new version. When the developers want to roll back to their previous version, they can simply update their Alexa skill configuration to point to dev1.

Figure 12 : Option 2 - big picture

Figure 11: Option 3 – big picture

 

Summary

Each of the three options presented have their advantages and disadvantages; the right option for you will depend on what works for your team.

Option 1 is suitable for multiple developers or larger teams for whom local testing tools are sufficient. It 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.

Option 2 is for multiple developers within larger teams for whom local testing tools are not sufficient. It is similar to Option 1, with capability for rapid testing and deployment in the development branch. However, there is no Lambda versioning in the development branch, and the need to manage multiple Lambda functions introduces some overhead.

Option 3 allows for rapid testing, while maintaining Lambda versioning and quick rollback for all branches. This option introduces the added complexity of managing multiple aliases per Lambda function.

 

Tags: , , , , , , , ,

Categorised in: Innovation, Technology

This post was written by Pim Amponpun