Continuous deployment to Amazon Lambda using Bitbucket Pipeline

I’m not a developer (more of a hack) so I’m always looking for way to figure out efficiencies in my process when playing around with code as I’m a very slow coder. One of those efficiencies found is around deploying my code to Amazon Lambda.

First, let’s talk about your options when deploying code to Lambda. The easiest way is to just do your development using Amazon’s IDE. The benefit here is that you can manually run some tests to validate what you’re writing, however if you’re using any dependencies the IDE has a size restriction and at some point it’s no longer available to you.

image

The next method is doing local development and creating a zip file of all your code and dependencies. Then manually upload your code. You can then run the same manual tests as before on your code, but the process of zipping and uploading the file is tedious specially when working on large code bases.

image

Next process involves the very good Amazon CLI. Using the CLI you’ll be able to save the manual process of uploading the zip file. Below you’ll find the Windows scripts I use one for small code bases (without dependencies) and one for larger ones.

echo on

del index.zip

echo Deleted index.zip

"c:\Program Files\7-Zip\7z.exe" a index.zip index.js

aws lambda update-function-code –function-name mySmallLambdaFunction –zip-file fileb://index.zip

echo done

echo on

del myZip.zip

echo Deleted myZip.zip

"c:\Program Files\7-Zip\7z.exe" a myZip.zip index.js node_modules

echo Zipped myZip.zip

aws lambda update-function-code –function-name myLargeLambdaFunction –zip-file fileb://myZip.zip

echo done

Finally, the process I’ve come to enjoy the most is deploying from git. The main reason being that it forces you have a bit of a process around using git which is pretty much the standard when collaborating with multiple developers. So if you’re dragging your feet around using git take the plunge it’s worth the learning. My favorite, mainly because they have a very generous free offering is Bitbucket. Besides having private repositories they also give you 50 free build minutes which is where our deployment to Lambda from Bitbucket comes in. To get started you first need to setup a few environmental variables. Go to your repository > settings > environment variables. You’ll need these named exactly this way.

image

The next step can be done in two ways. You can commit a bitbucket-pipelines.yml file to your repository or you can go to your repository > pipelines to have Bitbucket commit one for you. What the original yml file looks like doesn’t matter we’re going to change it specifically for Lambda deployment. Here’s what my file looks like with inline comments.

#I like to use the same version of Node as the Lambda function I’m using.

image: node:6.10

pipelines:

default:

– step:

script: # Modify the commands below to build your repository.

– apt-get update

– apt-get install -y zip

– python –version #From here to there is all to enable the AWS CLI installation

– apt-get install -y python-dev

– apt-get install -y python-pip

– pip install awscli #there

– zip index.zip index.js #this is for a Lambda with a small code base. For something large you can use “zip myZip.zip index.js privatekey.json -r node_modules” notice the –r parameter to zip up folders.

– aws lambda update-function-code –function-name botValidationScheduleMeeting –zip-file fileb://index.zip

Assuming you’ve done everything right you should see something like this under Pipelines.

imageThe last 3 commits were successfully built (sent to Lambda). You can click on the commit and see detailed information on the results of every command in your yml file. You’re done, you’ve developed some code locally, committed to git, and pushed it to Lambda all with a few clicks.

~david

Right way to block ANIs using Amazon Connect

In this blog I’ll cover a potential financial issue you might face if you try to ANI block customers and they are calling you through a SIP trunk.

As I continue my journey of getting familiar with Amazon Connect I ran into an interesting and a bit worrisome issue. The use case I was working on was to create a table which blocks or allows specific ANIs to call in. Ultimately, when a blocked caller came in I wanted to just hang up on the call. My original flow looked like this:

image

Pretty straight forward, invoke Lambda, check attribute and if blocked = true, disconnect the call. When calling from my cellphone this worked great. However, when calling from my home phone (using a Flowroute SIP trunk) I got a nice surprise in the logs:

image

What you’re seeing is a partial log of my home phone constantly retrying to connect to Amazon Connect and generating a new call each time. Since there was no prompt play and no ring back heard I assume the network believes there as a connection issue and continues to try and connect. Which means that you could easily incur a huge expense both on your phone provider and on your Amazon AWS bill.

The way to fix this was to play a 1 second of silence prompt before disconnecting the call.

image

~david

Amazon Connect and Sticky Queue

In this blog I’ll discuss how to achieve a sticky queue using Amazon Connect.

When a customer calls back within a short amount of time, it’s fairly safe to assume they are calling back for the same reason as before. This is often referred as sticky agent or sticky queue. Because you’re trying to “stick” a queue or agent to a specific customer. As a best practice avoid using anything sticky as it could force your customer down the wrong path or create long hold times when too many callers are stuck to a single agent or queue, but for my use case it’s safe to use because I want to use it. :)

I assume you already have a Lambda function or two working with your flow, if you don’t then you might want to skip this functionality until you get that working. The first thing you need to do is find the ARN for your queues. I’m going to be honest, this is not intuitive at all and I wish the Connect team would allow you to retrieve this information via the flow without having to do the following steps.

To get your Queue ARN go to your queues via https://<your instance>.awsapps.com/connect/queues, select a single queue, and notice the bold section of the url https://<your instance>.awsapps.com/connect/queues/edit?id=arn:aws:connect:us-east-1:64:instance/4d92ab25-8XXX-4bXX-aXXX-XXXXXXX/queue/XXXXXX-2022-XXXX-a275-xxXXXXxxxXXX That’s your queue’s ARN.

– Set an attribute (e.g. Queue) with your ARN.
– Set your queue name to the attribute you just set.

image

– Save your attribute to your DB.

Next time your customer calls, you can retrieve the last queue they went through and give them the option to go to that queue again, hopefully saving your customer some frustration.

image

~david