Build Meister

Inspiration

We wanted to improve team's performance by loading the request regarding the build status and triggering new builds through a self service setup. So we built an Alexa skill Buildmeister.

What it does

The Alexa skill queries build tools through a proxy node service to get information regarding build status and to trigger new builds on the associated project. If the project and plan keys are provided, then the skill would be associated to a particular plan. If not, the skill can query information across multiple build plans within the project. It then returns the top 5 builds requesting the user to choose an option number. You can select an option by saying the number. To end a search just say stop or cancel!

Get Last Build Status

This query retrieves the last build status from the project key provided in the CI Proxy service. If the build plan is not specified in the config file, then Alexa would provide the user with options to choose one of the build Plan

Get Last Successful Build

This query retrieves the last successful build from the project key provided within the CI Proxy service. If the build plan is not specified in the config file, then Alexa would provide user with options to choose one of the build Plan

Last failed Build

Get the last failed build in the plan

Trigger New Build

Trigger a manual build on the Plan

How we built it

This Alexa skill queries a proxy node service which runs on the client server. The node service connects to their internal CI tool like Bamboo or Jenkins, and queries for information regarding build status and to trigger new builds. Since the node service runs internally, users do not have to provide CI tool credentials to the Alexa skill. The Alexa skill and the proxy node service share authorized keys that allows request from Alexa skill and blocks all other request.

Challenges we ran into

One of the main challenges that we ran into was that we decided to use the Serverless Framework to setup our Alexa Skill as well as the API Gateway and Lambda connections. During the setup of the API Gateway we chose to use Lambda as the integration point from API Gateway instead of lambda-proxy. This meant that we had some manual setup to do within API Gateway to allow the requests to work. This caused an issue when trying to move the project from our AWS Dev account to the Production one as we had to repeat the manual steps instead of being able to do it with Serveless's CLI functionality.

Accomplishments that we're proud of

Previously all Lambda functions were created manually by compressing and uploading through the amazon portal. Most deployments for this project are automated using Serverless Framework which saved us a lot time and helped us manage the different environment