If I remember right, ChatOps as a phenomenon originated from the Github in 2012-2013 and at once became a source of discussions lots of which are not stopped till now. There are a few ChatOps books already, as well as the myriads of bots – everything is in the awesome ChatOps.

However, the ChatOps discussions at the meetings I attended usually were concluded with the idea that this thing is actually good, but the overhead cost on the maintenance is too high: “It’s nice to have ChatOps, but it’s not bad do without it”.

I would usually stick to the idea that ChatOps bot is similar to an interactive utility which can be launched from the shell: it should be built in such a way that the use is uncontroversial and clear. Moreover, it would allow to convey the experience and the best practices with the help of automatization as any other tool and would be stable. To make it simpler, ChatOps do behind-the-scene work, automate, belabour and so on, displaying only the UI of its solutions which are used by the rest. The appearance of this UI -either as console tools or as a bot in a slack – is not so important as the principles of the UI build. Actually, a lot of developers stick to this approach. And though deploy 0.19 version of frontend to qa looks all right, anyway it is a usual text-based UI in which the succession of arguments, key words etc should be remembered. It is unprofitable, especially in the cases of rare use.

On the whole, it is an eternal problem of the administrators not to be able to understand that something that is seldom needed can be forgotten. This results in “the stupid maids”, unlimited number of keys on the shell apps and a failure to built a normal UI.

Since it is impossible to remember everything, so often the ChatOps like this looks as follows:

> me: @bot who is oncall ops?
> bot: I don't understand you
> me: @bot help
> bot: ....blbalba on the tenth line
> me: @bot  who is oncall in ops team today

Or vice versa. Regardless, try as I might, I didn’t manage to build a normal UI, in which you just could write a piece of text without remembering some commands.

In the result, Slack turns into a usual terminal with chat pros and cons: one-stop solution, but if we already have a ready terminal with all the “buns”, why shall we create another one? The users` authentication is good, but speaking about the difficulty of automatization and deployment, this plus not always outweighs the minuses.

What could be the plus? Why do people use chats instead of interacting with the help of simpler commands? This is a huge question, the question to a language and its manifestation, but to make the story shorter, the possibility to express the same thought by means of diverse words smoothes the problems of communication. The only complexity in this is to parse the text: there are special segments in human brains, which deal with it. It is not easy to do the same by means of tough parsing and regexps, and on the whole NLP is difficult, though on the spot it can seem to people who are out of the topic that there is nothing special in it.

That’s why I decided to look for NLP parsers which already existed, and realised with surprise that while the industry was moving ahead, many DevOps, including myself, stuck in the past: quick googling gave me a few SaaS on this topic: free wit.ai and recently become free on the base plan api.ai. At the beginning I tested the things exactly on wit.ai, the members of UkrOps community can remember my experiments made half a year ago, but now I fancy api.ai much more. I won’t dwell upon the UI of this solution: everything is relatively easy there, and it’s possible to create a separate post, but if to make the story shorter, the text-based requests in any format will back the json with settings to us.

me: upload 0.19 on prod
    to bot: ...
        "parameters": {
          "deploy": "deploy",
          "env": "prod",
          "number": "0.19"
        },
   ...
    me: deploy it in the test version 0.20
    to bot: ...
        "parameters": {
          "deploy": "deploy",
          "env": "test",
          "number": "0.20"
        },

And so on. So this service let us quite easy click some contexts that it analyses, saves users’ requests which it hasn’t managed to parse and even can ask again in case something is not understandable or not specified, but you in your turn work with json in your application – everything is easy and understandable. On the whole, the future is for these things and I am interested in building ChatOps with the NLP parse. I will try to make up one PoC in UkrOps, but if you or your company need ChatOps with a usual surface than that would be interesting for me.