Blog

Using the Amazon Echo to Support Continuous Integration Builds – Part 1

Austin Parker

By Austin Parker

Since I joined the Apprenda team, the ritual of daily R&D team standups have been a constant companion.

Being able to to get a ten-thousand foot view of our progress helps keep everyone on the same page, especially valuable as our team has grown over the years.

One of the rituals of our morning standups has been the deployment report, where we’re updated on how nightly tests and deployments of the Apprenda Cloud Platform, Kubernetes development, and Kismatic Enterprise Toolkit have fared.

As a member of our tools and infrastructure team, I’m always on the lookout for ways to improve developer efficiency; I’m also a big gadget fan. The latter has lead me to develop quite the collection of Amazon Echo devices, the former lead me down the road of trying to invite Alexa into our daily standups.

In this post, I’d like to show you one of the results of that, along with some sample code and thoughts on how to bring Alexa into your daily standups.

The Problem

Let’s say hello to our friendly test environment, we’ll call it ‘Bourbon’. Bourbon is a test environment and, for us, is just a group of various new platform features.

Every day, we take the most recent version of our platforms and install it to Bourbon, which results in a successful deployment in our TeamCity instance.

However, sometimes disaster strikes! Bourbon might not get deployed correctly or it might have encountered a problem when performing a deployment step.

Previously, we would have an engineer look through the TeamCity results page every morning before standup and prepare a report of what succeeded, what failed, and what versions/branches were deployed.

So, let’s figure out how to get Alexa to tell us what’s going on, instead.

Talkin’ To TeamCity

We use an internal tool known as Gauntlet to store information about our test environments. Gauntlet is a .NET service, so the first part of our new Alexa service will leverage it.

First, we’ll want to define a quick model –

screen-shot-2017-01-11-at-3-50-37-pm

Nothing too fancy so far, just the information we care about. Since TeamCity returns success or failure as a string, we’ll preserve the information as a string in order to support more detailed information at a later time.

We grab the current environment list from Gauntlet, and then use FluentTc to query our TeamCity instance for all builds within the past 24 hours.

screen-shot-2017-01-11-at-3-50-49-pm

We’re not done yet, though. TeamCity’s REST API does not inflate the resources returned from a call to GetBuilds, so we need to go back to the well to get more information (such as the name of the build configuration).

screen-shot-2017-01-11-at-3-51-01-pm

Finally, we filter builds to active environments and create our list of deployments.

screen-shot-2017-01-11-at-3-51-14-pm

Next- create a new controller and route for the endpoint, and we can GET {server}/api/reports/deployments to receive a response that includes items such as this –

screen-shot-2017-01-11-at-3-51-31-pm

Great! So, now what?

Next Time: To The Cloud!

In part 2 of this series, I’ll talk about how we use microservices and AWS to get our little blob of JSON out of our datacenter, and into an Echo.

Finally, I’ll wrap up with a look at how to create a new Alexa skill and some examples of how we’re using it, along with thoughts on how you can apply these lessons to building Alexa skills of your own.

To see it live in action, check out the demo, below

Austin Parker
Austin Parker

Austin Parker is a Software Engineer at Apprenda who is primarily concerned with developer productivity, automation, and the cloud. Outside of that, he’s mostly concerned with cat videos. You can find him on Twitter @austinlparker.

0
View Comments

Leave a Reply

Your email address will not be published. Required fields are marked *