We wanted to improve the performance and efficiencies for Development Teams. We were looking to increase development performance by loading build status requests and trigger new builds, using a self-service setup. This led us to build a new Alexa Skill; We call it Build Meister.
What it does
The Alexa Skill queries build tools through a proxy node service and retrieves build status information. It then triggers new builds on an associated project. If the project and plan keys are provided, the Alexa Skill would be associated with a particular plan. If not, the Alexa Skill would query information across multiple build plans within a project and provides the results of the top 5 most recent builds. From there, the Alexa Skill requests that the user chooses an option number. The user can then select an option by saying the associated number. To end a search, the user would use the commands, "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 plans.
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 the user with options to choose one of the build plans.
Last failed Build Retrieves the last failed build in the plan.
Trigger New Build Triggers a manual build in the plan.
How We built it
This Alexa Skill queries a proxy node service that runs on the client server. The node service connects to their internal CI tool (such as Bamboo or Jenkins), and queries build status information and has the ability to trigger new builds. Since the node service runs internally, users do not have to provide CI tool credentials to the Alexa Skill. This is because the Alexa Skill and the proxy node service share authorized keys that allow requests from the Alexa Skill and blocks all other requests.
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 were required to setup some items manually within the API Gateway to allow the requests to work. This caused an issue when we tried to move the project from our AWS Dev account to our Production account. We had to duplicate the manual steps instead of being able to do it with Serveless' CLI functionality.
Previously, all of the Lambda functions were created manually by compressing and uploading through the Amazon portal. Most deployments for this project were automated using a Serverless Framework, which saved us a tremendous amount of time, and helped us manage all of our different environments.
What We learned
We learned to manage our infrastructure in Amazon (as code), using Serverless Framework technology.
What's next for Build Meister
The future of Build Meister is endless. To start off, we want to extend support to more CI tools (other than Bamboo and Jenkins), and add deployment functionalities.