So, What is ChatOps? And How do I Get Started?

So, What is ChatOps? And How do I Get Started?

Help your teams communicate and collaborate better

You’re probably hearing the word ChatOps more and more – at conferences, on Reddit and Hacker News, around the water cooler (or keg) – but what does it actually mean? And why and how would you implement it at your organization?

ChatOps, a term widely credited to GitHub, is all about conversation-driven development. By bringing your tools into your conversations and using a chat bot modified to work with key plugins and scripts, teams can automate tasks and collaborate, working better, cheaper and faster.

Here’s the 30,000-foot view: While in a chat room, team members type commands that the chat bot is configured to execute through custom scripts and plugins. These can range from code deployments to security event responses to team member notifications. The entire team collaborates in real-time as commands are executed.

Let’s break this down a little more. You probably use a chat client at work – HipChat, Slack, Flowdock, and Campfire are some commonly used tools, and if you already haveone in place, you’re on the right path. Then there are the chat bots – and they’re all open source.

  • Hubot: GitHub’s bot written in CoffeeScript and Node.js (docs)
  • Lita: Written in Ruby
  • Err: Written in Python

Screen Shot 2014-12-02 at 9.47.12 AM

While chat bots do the commanding, sometimes you also have deployment servers listening for these commands, doing the heavy lifting of executing deployments tasks as background jobs. With Github’s Hubot, the deployment server is called Heaven. Check out how Flowdock recently implemented ChatOps with those tools in their workflow. Similar to how Hubot tells Heaven what to do, PagerDuty’s bot Officer URL tells Igor, our deployment server, what to do. I’ll share some more detailed information about ChatOps at PagerDuty in the next blog post.

The results?

Visibility Across The Board

Everyone has experienced the pain of figuring out if a particular command was run by a coworker. ChatOps helps bring that work into the foreground, by putting all of it in one place – everyone’s actions, notifications and diagnoses happen in full view. This encourages teams to be transparent.  Different plugins can help expose more information to everyone (replacing opaque IP addresses with DNS names and other metadata, for example).  Beyond operating more efficiently right from the get-go, it helps new hires jump right in and learn by doing. And it flattens the typical workflows teams use to deploy and diagnose. (Not to mention, it makes remote work a whole lot easier.)

It’s also how PagerDuty better onboards talent, improves our infrastructure through automation, and, as Jesse Newland at GitHub says, puts tools at the center of the conversation.

Screen Shot 2014-12-02 at 2.11.12 PM

Employing ChatOps even benefits non-technical teams. By having a central location for chat-based tools, teams like sales, marketing, and finance can understand what’s going on in your infrastructure – when you’re deploying code, who’s responsible for which systems and what they do – without having to walk over and interrupt. They can learn right from the bot itself.

Automate Manual Tasks

Tasks that used to be done manually, and often involved human error, are now automated through the chat bot. You can reduce tedious and error-prone hand-typed SQL statements, or put in place proper tests around often-repeated commands. Once a task is in chat, it’s a fast and easy way for other teams to make requests (no more ticket volleyball!) ChatOps can also improve your continuous delivery process. By easily understanding where a deployment started – and who started it – you’re able to cut out extra tasks and manual follow up, and deploy code continuously throughout the day.

Want to employ ChatOps at your company? Here are some tips on how to get started.

Pick Your Bot

The three chat bots we listed above – Lita, Hubot, and Err – provide teams with options to best suit their workflow. Different bots have different plugins and development languages ranging from Ruby to Node to Python, so pick the ecosystem that best fits your shop.

Plug It In

Hubot, Lita, and Err offer tons of scripts and plugins each – and your team can easily use any of them today. Check some examples below:

Start Small & Iterate

There are a lot of powerful ChatOps tools, plugins, and extras available, so it’s probably a good idea to start simple and get experience to find out what works best for your team. Try various bot integrations and scripts in your team chat room, and then stick with the ones you like best. There may be some trial and error – but that’s ok, it’s a part of the process.

The more you get used to coding, executing commands, etc. with your chat bot, the more efficient you’ll become. As your team reaps the benefits of employing ChatOps, other teams – like Front-end, Mobile, and more – will also catch on and implement it on their side. With the technical and non-technical folks participating, you’re developing not only efficient processes, but also a more development-focused culture in your company.

Additional Resources



Share on FacebookShare on Google+Tweet about this on TwitterShare on LinkedIn

  • Nathan Neulinger
    Posted at 6:01 pm, December 18, 2014

    Interesting idea… I particularly like the “goes back to command line, without using a shell” aspect of it. How do you suggest reconciling security concerns that will inevitably be raised by ISOs?

    • Eric Sigler
      Posted at 10:10 pm, December 22, 2014

      Good question! A few points to address:

      1) Within the different bot frameworks, there are multiple mechanisms for authorization. Users and groups are pretty standard, and allow for simple RBAC. Beyond that, there are some that support OTP and two-factor auth. Finally, more sensitive plugins (deployments/modifications, for example) can allow for confirmation of commands by other users – so even if someone’s phone is lost and the attacker has access to all of their secrets & tokens, sensitive commands can still be guarded by a “two person” rule.

      2) Additional control is also possible if you want to self-host the chat infrastructure itself (such as running your own IRC daemon, or using one of the enterprise products from HipChat, Microsoft, or elsewhere), including restricting what networks have access to your internal communications, or ensuring all conversations happen over TLS.

      3) Even with proper authentication & transport security, you should always design for multiple layers of defense. My perspective is that bots should run in a restricted area, and not have direct access to most of one’s infrastructure but instead make requests to 3rd party services that in turn have their own layers of security. This prevents easy lateral moves from a compromised host, as well as “the one superpowered host in your infrastructure” anti-pattern.

    • John DaCosta
      Posted at 9:21 pm, November 14, 2015

      you have multiple options:
      1. secure access to the chatroom / slack / hipchat
      2. program validation that can check if the caller / user has rights to execute script
      3. hubot can also respond to web service calls, so you could have a web page or custom app that talks to the robot with custom security

      your robot can literally do anything you are able to program.
      so sky is the limit, be as creative as you want to secure access. but remember to keep it simple… chatops is here to automate and simplify…

      Example if using slack you have the option to choose who can access the chat room for the deploy bot vs a HR bot vs a statusBot, etc… assuming for different things you can run different bots. in addition since the tool can do anything you can program, you could program your script to validate the user names before running the script….

  • bob thomas
    Posted at 11:20 am, June 9, 2015

    More interesting article post, I really enjoy your post.

  • Posted at 3:46 pm, January 27, 2016

    I believe there are two separate ideas behind this, and as a Unix philosophy person myself I would love it more if the two would be more separate.

    The main idea I see is the desire to collect every little tool used by the DevOps team under the control of a single instance (let’s call it Bot). There are tons of daily routine tasks carried out by these staff like “create me a new repository”, “deploy this stuff”, “clear the cache”, “restart the webserver”, etc. Lots of people write little scripts for these things nowadays, but then these are lying around on various servers unbeknownst. Once they get collected together into a single Bot, they will be much more reusable. If the Bot itself gives some nice scripting features even better.

    Then the bot accepts commands and carries out the tasks defined earlier.

    The other idea is to give these commands over a chat interface. Some people like this idea, some won’t. Chat also has drawbacks: learning the commands is exactly as difficult as learning these over the unix shell. On the other side parsing human language always sucks.

    I believe there are lots of people around there who would like more to control their bot over a web interface. Or through their ticketing system. Or through email (bet there are lots of youngsters out there who has no idea how to interact with a listbot)

    Being as much open on the command interface as on the backend interface makes the system more interoperable. There’s nothing new in it: just take a look at the project OpenHab, which basically does the same thing in the field of home automation.