Introducing ChatOps to my Workplace: Hubot

Hubot? You may not have heard of it, but its pretty much the workhorse of ChatOps. Hubot is a scriptable chatroom robot. It can integrate with many chat services and comes with a huge community of plugins and extensions.

In the previous post I talk about ChatOps, Slack, and how I plan on introducing it to my workplace.

Hubot is an IRC/campfire bot designed to give some character to your team’s channel. It has various commands for inserting photos in your chat, fetching stuff, and, indeed, running pre-configured commands.

There exists many other chatbots, but Hubot is the most popular. You can get scripts for anything: showing images, interacting with Jenkins, ship it squirrel, pager-duty, and hubot-plusplus, where the points don’t matter.

All of the plugins are written in coffeescript and follow a simple input/output design using regular expressions. Persistence is included as well, using Redis as the datastore.

Writing Hubot scripts can automate tasks while presenting a simple interface to interact with. Writing custom scripts adds useful insights and actions into your business and software.

So far I’ve written a custom Docker image that contains everything needed to run Hubot, bundled with a bunch of scripts. Everything is kept in a Git repository on our SCM server.

In the future, I plan on making the Docker images more extensible by separating the configuration from the code, then publishing it to my GitHub.

I also want to use Docker Compose to define a Redis container as a dependency of the Hubot container. This primarily allows for the Hubot container to be destroyed and rebuilt while the data stays safe in its own container.

Introducing ChatOps to my Workplace: Intro

slack_colour_rgbWhat is a ChatOps?

Last week my roommate talked about how he was building custom integrations for his Company’s Slack service. He was adding commands that would easily allow their client service team to extend the trial periods of their customers and other useful features. He was also in the process of working on being able to deploy their app to amazon via a single command.

All of these spells one thing: Productivity.

Trying to keep up with drinking as much of the new enterprise technology kool-aid, an excellent talk (slides) by Jesse Newland that I keep going back to every once in a while shows the power and benefit behind ChatOps.

Dissecting this buzzword, the true benefit behind this technology and culture is giving:

Visibility – Seeing what other people are doing and show what you’re doing to others to provide visibility and accountability into the operations that are performed. Sure, someone can say that they’re fixing the unresponsive server, but it’s not clear how they’re doing it and if its fixed yet without asking them. With all the operations used to fix such an issue available in a common chat room, its straightforward for others to read what was done in real time.

Learnability – Sure, you can have documentation and training to bring people on board, but nothing compares to seeing things done every day, most importantly their first day. In no time, a new employee can get up to speed faster than having to read through a lot of boring documentation.

Pairing – Allowing two or more people to solve a problem together. Much like pair programming, it is the practice of having more than one brain working on a problem or even passively observing. Pairing allows for more scenarios to be explored and better reasoning.

Automation – Simplifying tasks to the extreme. No need to log into a server, find and run a script. Just have a command in the chat room that does it. The command acts as a facade, presenting a clean api into your business activities. Being able to automate to the level of not having to switch out of the chat room is an amazing improvement in productivity.

Sneaky Implementation

On my self assigned task to improve productivity and culture at my workplace, many other developers and I are pinned in a rut of completing support tasks and fixing bugs for our software. Between tasks I’ve set up Slack and have been integrating our services into it. My goal is to ultimately reveal it slowly to other developers, gaining momentum until critical mass is reached, where the majority of my colleagues praise Slack and the power of its usefulness until it becomes the de facto messaging and team communication tool.

So far I have integrated our build server, Jenkins, and the source code repository, Gitlab, into Slack. Both of those are only dumb endpoints which dump data into Slack, but its already super interesting to have the visibility of just these services together. Nagios checks, and maybe even Hubot, a chat room robot, will come next.

The stream of messages created when someone pushes code, the code being built, and then the test results reported back. Its taking Continuous Integration and reporting all of the activities to a central location!

See the next post following the theme of ChatOps, this time about Hubot, the chatroom robot.