Automating Our Development Flow With Atomist

We use GitHub, Travis CI, and Slack (among many other things) to build and run Atomist. Naturally, we configured the GitHub and Travis integrations to Slack to get notifications in channels about commits, issue comments, and builds. In the ChatOps spirit of bringing the tools into the conversation, it’s a win. Everyone sees the same information and knows what is going on. Or do they?

We found some fundamental problems that undermined achieving shared context in chat. Here’s an example:

I have Slack open, but am working on something else and I miss a GitHub commit notification in one of my project channels. Later, I’m in that channel and see a Travis CI build failure notification.

There is not enough information in the build failure notification to understand, for example, the context (e.g. description) of the commit that drove this build; it’s not immediately useful without clicking through to look at the build on Travis or associated commit on GitHub. I have to leave the chat flow to get context.

We wanted something more like an “assistant” but what we got was an RSS feed in Slack.

Why does this happen?

1. Disparate notifications interspersed with other commentary make it hard to follow if you miss part of the stream.
2. Notifications from different systems don’t know anything about each other (disjoint notifications that lack any broader context).
3. Most integrations treat notifications like a firehose of events that lack awareness of a topic or scope (like a project).

We’re developers building things to make developers’ lives better, and this was an opportunity to scratch an itch. So, we used Atomist to make it better.

Notifications With Atomist

Here is what our notification flow looks like now:

Commit and Build Notifications Correlated

Atomist notifies us in Slack about the commit with the essential information cleanly formatted and linked appropriately. When a Travis CI build event comes in, Atomist correlates it with the GitHub commit and updates the message in the Slack channel. We find this particular user experience really helpful.

Note that the message above shows that the Travis CI build was started, and the blinking yellow dot is a nice visual cue that the build is running. When the build completes, Atomist receives that event, and updates the message again in the Slack channel.

The build was successful, which we see with a clear visual and text message. Note: we also see the user whose commit triggered the build, and in case of build failure, we have the @atomist bot DM the person in Slack so they can respond respond right away if needed.

Oh, and you see the “Create Release” button there? Clicking on it will create a new GitHub release of this project. This is an example of what we call actions that can be passed back with messages from the Atomist bot in Slack. We’ll have much more to share about actions in future posts.

By updating the message with new, correlated information, we keep all of the relevant context together. No more scrolling back to find the rest of the context.

Behind The Scenes

Atomist, the product we build, enables the scenario above. Atomist is a service that you can build your own automation on top of, taking advantage of features like data correlated in the model (see below), and sending actions in Slack messages.

The key components that make it possible:

• Events & Model — Atomist gets events from GitHub and Travis CI, and uses the events it receives (like new commit, build started) to create a model of how the dev flow actually works. When adding new information from events into the model, Atomist correlates the information. That correlation enables us to do smarter things like understand that a commit and a build are related and do something with that knowledge.
• Handlers — this is a new core concept. Handlers are pieces of code that get executed in response to a trigger (like a commit or build event). You can think of it a bit like an IFTTT recipe for automating development tasks, in that a handler is triggered by an event and takes an action like sending a message to Slack.
• Integrations—Atomist integrations with GitHub and Travis CI enable us to receive and comprehend events, and store them in our model for correlation. The integrations also provide a way to call APIs on those systems, like ‘Create Release’ on GitHub, or ‘Retry Build’ on Travis CI. Integrations are extensible, so you can also build your own. We’re also adding new ones all the time.
• Slack API — we’re making use of some nice features of Slack that enable our bot to 1) update a message thread based on an event like ‘build started’, 2) visually show the status of (started/passed/failed) and relationship between steps in the flow like commit and build, 3) provide actions (as Slack buttons) that can trigger other tasks.

Where To From Here?

In future posts, we’ll dive into how to build handlers to automate tasks across your development flow. This example really just scratches the surface of what is possible with Atomist.

You can see the bot in action in the atomist-community slack team.

If you’d like to try out better notifications with Atomist in your own Slack team, please get in touch.