The HelloSign Ops team loves our chatbot and the ChatOps concept. As automation becomes more and more prominent in our industry, and with the benefit of enhanced communication tools, a ChatOps movement seemed almost inevitable.

‍

To my knowledge, the term itself originated within the GitHub Ops team and their @jnewland has spoken about ChatOps (and GitHub's chatbot: hubot).

‍

Some key takeaways from Jesse Newland's presentation on ChatOps at GitHub:

‍

Results in an almost constant 'pairing' in the context of any chatbot functionality. Everyone sees what's happening, and any questions are simply answered in context for everyone to see.

Automated/repeatable functions. By scripting/automating and creating chatbot functionality, a task is both automated AND as accessible to others as you care to make it.

Communication for important tasks becomes a mandate; you need not inquire about an event or state, because it's available in your communication platform.

Ease in incident response: alerts can be resolved by logging in to your communication platform and issuing a command, which should be possible from a mobile device.

‍

ChatOps at GitHub started as a way to promote teaching by doing, and teaching in a public setting (the chatroom). ChatOps has continued to mature and today I think ChatOps is almost as difficult to define as the elusive 'DevOps' term. At HelloSign, ChatOps is about automation, communication, learning, access control, and helping our team grow (whether that growth involves code deployment, meal plans, or memes).

‍

1. Code Deployment

‍

You should already have something in place that manages code deployment (fabric, capistrano, rex, some shell scripts, or whatever); if you don't, stop reading and automate your deployment process.

‍

It's easy to have a chatbot running somewhere that can trigger a deployment with as much control as your deployment technique offers. Some of the options HelloSign supports allow deploy commands like:

push stage01 www develop

push stage02 docs mybranch@abcd1234

push environment0001 master clear-sessions

‍

Ours follow the format: "deploy ENVIRONMENT TARGET_NODE_TYPE GIT_BRANCH[:COMMIT][ OPTION]" Some of our other 'deploy' targets that are conceptually similar are puppetmaster, packer config files, and external testing suites. Anywhere that code gets pushed/pulled/cloned/installed is a prime target for a chatbot command.

‍

2. Environment status

‍

What is currently deployed to the staging servers? How many production web instances are we running? Is there a test environment provisioned? What are the oldest logs currently available? At HelloSign many of these questions are tightly linked to AWS state, and as a result we use a combination of custom scripts and AWS API wrappers to pull environment details like:

‍

ec2 instance tag:Name instance-name

ec2 instance group-name elasticsearch

ec2 instance private-dns-name 1.2.3.4

as group stage01 www

‍

These pull information about ec2 instances directly from ec2-describe-instances with an applied filter (based on the request), or display auto scaling group data by a particular group name using as-describe-auto-scaling-groups.

‍

3. Environment Updates

‍

Our environments are modeled around auto scaling groups in AWS, so the environment updates are often a matter of an update to the auto scaling group in question. If someone is testing a feature in an environment called "someEnvironment," and they need to confirm that it works properly in a larger cluster, they can easily:

‍

as update someEnvironment docs 4 4

as update someEnvironment www 2 4

‍

These bring up 4 docs nodes and configure default auto scaling rules with a minimum of 2 and maximum of 4 instances for www nodes. This is very consistent across our various services and makes it easy to increase/decrease our cluster sizes.

‍

4. Provisioning/Bootstrapping/Baking

‍

Puppet configures our servers at HelloSign, but from an Ops-perspective we follow the Netflix OSS team's proposal that an AMI is the smallest unit of deployment, and in most cases the desired unit is actually an auto scaling group. This means that a 'provisioning' activity for us generally consists of packer generating an AMI with the help of our puppetmaster. Some of the chatbot commands we use to support this are:

‍

puppetmaster branch@abcd1234

packer aws stage01 www

packer vbox dev elasticsearch

‍

These commands update our puppetmaster the desired commit, then generate a stage-web ami and a virtual box image with a dev's elasticsearch cluster.

‍

5. Server Deployment

‍

Depending on your flow, Provisioning and Server Deployment may be the same action. If you 'pre-bake' images like we do at Hellosign, then you need to actually push those images into a cluster before you've made any real progress. In some clusters, we consider this a specific deployment type, in others it is simply an auto scaling group update.

‍

ami-push stage01 www develop@abcd1234

as update-lc stage01 docs

‍

The first command updates the ami used for www nodes in the stage01 environment and ensures that they use the desired code upon deploy. The second is a more generic auto scaling group change that generates a new launch configuration to launch instances based on the latest ami to an auto scaling group.

‍

6. File retrieval (s3/cloud)

‍

We sometimes require access to particular content for debugging. This is one of the more cloud-specific implementations, but rather than writing access in an administrative interface we simply use our chatbot to interface with s3 and make particular files accessible. This helps when multiple people are investigating something and also acts as an auditing tool for who was accessing what.

‍

s3 BUCKET FILE

‍

These requests can push a file directly to your communication platform (where supported), create a temporary link, copy a file to a known location, etc. You can easily decorate requests like this too, if the Marketing team requires access to particular data, maybe a request like "acct_so_2001" in a marketing room or from a marketing team member automatically performs the right s3 command. These types of beautification scripts can often make a big impression on your team.

‍

7. Cat pics

‍

If you're going to have a chatbot around, your co-workers should probably be able to use it to retrieve memes, gifs, images, or whatever from the internet. It's only fair, and it often sparks interesting discussion.

‍

mustache me MY_BOSS

image me ALL THE THINGS

youtube me Rick Astley

‍

Every once in a while, try only communicating via images; you'll see.

‍

8. Office/Admin services

‍

Your chatbot can fetch all sorts of data for you. I tell co-workers that any time they find themselves doing something repeatedly to get new data, they should ask about having the chatbot do it.

‍

Some data that our chatbot retrieves:

‍

schedules and events (calendars, pagerduty, etc)

food information (zerocater or yelp)

twitter (recent tweets about HelloSign)

weather by zip code

‍

These are easy to implement and save small amounts of hassle for lots of people. They always feel like a big win to me.

9. Self management

‍

Your chatbot should be able to update/kill itself. When we push new chatbot code, it would be terrible to not let the chatbot push that code to itself.

‍

self update master@abcd1234

self seppuku

‍

Automate All The Things

‍

Anything that happens 3 or more times fits my requirements for a thing the chatbot should do (scheduling these as a priority is more complicated, of course). These are a few to get your implementation running, but there are so many more. Check out some other common chatops features (hubot specific):

‍

‍

And learn to write your own!