Don’t forget to download your free copy of the O’Reilly book, ChatOps, by Jason Hand, to learn more about automation and managing group operations through chat.
From firing off an API call to resetting a server, chatbots are a way to trigger a set of automations using chat functionality. ChatOps tools allow you to communicate and run automated commands from one centralized place.
So, let’s dive in to learn more about chatbot options and how you can leverage them to create more efficient workflows!
It’s time for a chatbot when third-party integrations are:
Not flexible enough to work with your unique situation
Not feature rich or missing core functionality your team needs
There are several well-known chatbots available–with more and more popping up all the time. However, much of the attention toward chatbots is focused on the business-to-consumer (B2C) type of chatbot.
These are not the chatbots we’re talking about. For our purposes, we are primarily focused on chatbots that help people and teams manage their day-to-day work lives rather than facilitating interactions with consumers.
Later, GitHub rebuilt Hubot from the ground up and open-sourced the project, making it available to the public and allowing others to contribute to its ongoing development. Because it has been around the longest, Hubot has the largest number of contributors to its core application. Also, Hubot has a larger list of scripts that manage the interactions with third-party services, the infrastructure, and the codebase than any other chatbot available today.
As ChatOps has gained popularity, a chatbot written in Ruby named Lita has caught the attention of teams around the world. Definition files and instructions are written in Ruby in the form of modules that allow much of the same functionality that Hubot provides. With a strong and growing community consistently contributing to the source code and modules, this chatbot is easily implemented and has become one of the more popular ChatOps tools.
Errbot is an open source project written in Python. It has a number of advantages over both Lita and Hubot, the most notable one being that the application doesn’t need to be restarted each time a new script is added to the library. Errbot is able to recognize new Python scripts and begin running them on behalf of users as soon as they’ve been placed in the correct directory. Following its nearly complete redesign a year ago, Errbot has a gentle learning curve and offers a number of intriguing features to consider. These include:
Ability to “pipe” commands, automation, and conversations
Ability to manage and use the bot through chat
Built in ACLs for security
Cog is another new player in the ChatOps space, but it’s much more than a simple bot. Cog is engineered as more of a framework to address a number of concerns many teams have, such as security. With built-in access control and audit logging functionality, Cog allows teams to collaborate on sensitive tasks with higher confidence. Taking inspiration from other command-line ChatOps interfaces, Cog has a “pipe” operator that allows users to run a command and use that output as the input for another command in a process.
Recently, a new chatbot named Yetibot has gained traction. A self-proclaimed “communal command line,” Yetibot is written in Clojure. This chatbot has a few features that may pique the interest of technical teams looking to piece together strings of commands. Similar to Cog’s piping functionality, Yetibot allows users to chain together complex and flexible commands as well as letting you embed the output of one command into an outer command. Commands can be nested as many levels deep as you’d like.
When it comes to instructing your bot to take action on your behalf, the scripts, modules, or files that contain instructions will vary depending on your choice of bot.
Ruby is the language of Lita.
Python is the language of Errbot.
Cog is extensible in any language.
Yetibot is instructed using Clojure files.
It can be tough coming to a consensus on which bot, framework, and (as a result) programming language to use–especially for larger organizations with many teams. But there’s another approach.
Some people make the strong argument that it’s much better to build a library of automation scripts, written in any language, that people can access via not only a group chat tool, but also an API, command-line interface, or graphical user interface.
Because there are multiple ways to interact with a library of scripts, teams can focus more on building small, decoupled automation scripts that can be peer reviewed, version controlled, and made available across the organization.
In fact, you can put fine-grained access control in place to ensure those who should have the ability to execute commands can, and those that shouldn’t can’t. This adds a level of abstraction from the complex inner workings of the automation scripts.
What are the benefits to building these automation scripts?
If you build these scripts, then you can expose teams to actions with complete disregard for the programming language or chatbot in use. Teams are less likely to become dependent on any particular bot or programming language and thus can focus more on building small yet powerful scripts in their languages of choice. Any chatbot mentioned here or any other that may surface and evolve will be able to execute these scripts, regardless of the language it’s developed in.
At present, all the chatbots described here require a very specific syntax in order to execute commands. Much like when inputting commands with variables, triggers, and flags from the command line, the bots will only execute your commands if they are typed or pasted into the chat client in a very specific way. Typing errors, missing variables, or an errant space will prevent the bot from executing anything. The bottom line is that a basic layer of security is built into your interactions with the chatbots.
With that said, some teams are experimenting with ways to create a more “human-like” interaction with their preferred chatbots. Natural language processing (NLP) and the development of associated APIs to allow more natural interactions with applications (such as chatbots) is an area of technology that is gaining more and more attention. In fact, many teams are now exploring interacting with chatbots and services through the use of Voice-Recognition bots such as Amazon’s Alexa. NLP makes it so humans can interact and run chatbot commands more dynamically.
As ChatOps continues to evolve, the ability to use natural language processing (NLP) with chatbots will make for more seamless, “human-like” interactions and will continue to improve over time. Operators will be able to interact with bots as though they are real-life members of the team. Hello, Artificial Intelligence! Being able to immediately interact with a chatbot, not knowing anything about the correct syntax, will open the door for more people to use chatbots in their ChatOps endeavors. Exciting possibilities are on the horizon.
Learn more about ChatOps and chatbot automation. Download the free O’Reilly book, ChatOps - Managing Operations in Group Chat today.