Project: Deploybot

One of the first things I did when I started at Signal Noise was build deploybot; a simple tool that orchestrates CI on all our projects, communicates via Slack and is free to run.

It’s hard to automate CI in a studio because different projects have different needs. So first of all we agreed on a standard Git workflow, which I talked about in my last post.

We decided to use CircleCI for our build pipeline; it allows the project configuration to live inside the project repo (like GitLab and GitHub’s tools, but unlike many other third party tools) — this is a big deal because your devops materials are versioned, copyable, and not spread out all over the place.

Their price point was also really good, but we discovered that the build triggers they had available simply didn’t work for our workflow — which requires a review build on each PR (and every change to the PR), a manual build to staging and a production build triggered by a tag hitting the repo.

For example, pushing a commit to a new branch and then opening a PR would not trigger the PR review build to happen, and creating a tag via GitHub’s Releases page would also not trigger a production build, while a manual trigger just didn’t exist.

Over one Christmas holiday I built deploybot to solve these issues. It uses GitHub’s event stream and internal “deployment” API to trigger CircleCI builds and update GitHub on their status, and it allows manual triggering of builds via Slack.

It’s built in Python on the Serverless Framework, and runs on AWS Lambda and DocumentDB. Once it’s set up, adding it to a project takes a few minutes, and as soon as it’s in place all builds will happen at the right time and place for our workflow.

It’s not currently as flexible as it should be (you need to be using our workflow and tool set) and the Slack commands could do with a bit of cleaning up, but we’ve been using it daily for 18 months and it has saved many houtrs of dev time so far!