So what is actually behind the notion of ChatOps?
Just over two years ago, Jesse Newland presented “ChatOps at Github” at RubyConf 2013 about using Hubot for automation and deployment at Github. Actually, that was a beginning of ChatOps history. During those two years, there were lots of topics discussing ChatOps — at different conferences, Reddit, Hacker News and other technology related platforms. Since then, it has become more useful. So what’s the reason for this, and what actually is ChatOps?
Just remember that every bot command should be represented with an alias stored in the packs folder. So if you want your bot to work with a hundred commands be ready to create hundred of yaml files. I’ve already created some basic linux/aws yaml files, feel free to use them.
Summary
Twenty minutes ago, when you’ve started reading this article, you had a default DevOps environment you used to. Now, you have a basic ChatOps system up and running. Despite it’s only the beginning of the journey, and we still have lots of things to improve, we are operating on the next level, and it is ChatOps. Later on, you may configure
- additional aliases
- install more packs that you need to
- create more complex triggers and sensors
- improve security with role-based access control
and I hope you will like it. StackStorm as part of ChatOps opens a great way to operate in your environment communicating with developers, engineers, testers, managers being on the same channel with you. It defines a security policy that only a bot have access to the environment while L1/L2 support just operates the bot. It solves lots of problems including “console sharing” and those situations like: “John, come here and look at my screen…”
I want to end this article w ith the words of Evan Powell — founding CEO of StackStorm:
ChatOps is a huge movement in DevOps — and crossing into the enterprise. An analyst recently told me that 2016 is a the year of ChatOps and I tend to believe him.